January 2005 - Posts
I got a little bit of clarification on scaling out Team Foundation Server on the chat this morning. Basically, it sounds like they just aren't planning for it or testing it. This seems odd to me for what amounts to an ASP.NET application being written to support hundreds of users. How does scaling out get pushed to a later release??? :-/
Obviously customers will end up testing this scenario for them, and as long as they didn't do anything violating MS's own best practices for web development, it should work. If it doesn't, I would expect MS to get verbally abused pretty bad for whatever design decisions prevent it.
I taught a VSTS class recently and the following questions came up that I was able to get answered during the online chat that was held by the Team Foundation group. Some of these are generally interesting, so I'll post them here:
Q: When creating a new team project and branching, can you move over work items?
A: Not automatic - this has to be done by copying them from one project to another manually
Q: Can you categorize projects? If I have a large enterprise, I might want one huge scaled TFS with all projects. If so, how would I organize them?
A: Not in V1. All your team projects will show up in alphabetical order in the team explorer.
Q: Does TF source control store each version of the file, or only differences?
A: Version control store the differences in the database for each version getting checked in for that file.
Q: Can you limit the resource list in MS Project when working with work items. It seems to pull from AD?
A: Yes. The list of users is not pulled directly from AD even though that may appear to be the case in the current tech preview releases. The list is actually drawn indirectly from TFS Groups. The set of all users in all TFS Groups is the default list of users available in MS Proj. This list can be constrained by adding additional rules to the Work Item definition to further scope the set of users that are available.
Q: Can TFS be load balanced (Scale-out)? It's just ASP.NET, right?
A: There is both application tier and data tier components to TFS. On the AT it is primarily web services. We will not be supporting NLB clusters for the AT as we store session state in memory. For the data tier we'll be 100% SQL backed by the time we ship. We looking at what if anything additional we would need to do to support failover scenarios.
The answer above worries me, I'm going to try and get on the chat this morning and clarify this.
The following wasn't my question, but I found it worthy of note:
Q: When merging from a branch, will history be retained in a tree like manner as (CVS/Perforce/BitKeeper/...) , and will new files, renames, and deletes be handled properly (VSS does not handle any of those cases cleanly)
A: Yes, Team Foundation Version Control keeps track of merge history. New files, rename, deletes etc are handled properly during branch/merge etc;
I've been having converstations with one of my coworkers about Team System training. We have done a couple Whidbey-focused classes (that include some Team System) already, but VSTS is not very applicable to people's jobs just yet. I figure that there will be some VSTS adoption when Beta 2 comes out, though I don't know how much. I'd like to get some thoughts from those of you looking at VSTS, to see what your thoughts are from two perspectives. The first is what training should be available (I'll get to that in a moment), and the second is timing.
So first, the content - Team System is different than most MS products in that not only will developers and architects need training, so will project managers, business analysts, testers and development managers. There could even be some basic overview training for IT executives and business users. Project managers need to know how to manage using the work item database and MS Project. Testers will need to be trained on work items as well as test case creation and management. Business analysts will need to know about work items as well, and potentially the whole team should have some clue on the MSF flavors. Lastly, there is that cool project portal with reporting that could probably be covered in 1-2 hours with those people that aren't part of the development effort, but care about it (users and executives). I think this last one could be a recorded training session that they just watch as a group at their offices. Alternately an instructor led webcast when the trainer isn't onsite.
My thoughts are to section the content with a 1-2 training class on process and work item tracking. Then have a half to full day for PMs, a half to full day for BAs, and 1-2 days for testers. Obviously there will be dev/arch training as well. Add all this up and I end up cycling a lot of people in/out and have about 2 weeks of training to get all the parties involved. Obviously, the customer could pick and choose whether or not to even traing their people in the variety of ways. That's option 1, and probably the easiest to pull off.
I've also thought (I really would like some comments on this idea) about teaching it with the full flow of the process. Start the class with an overview, get into BA stuff, then give the BAs a lab. While the BAs are working on their lab, cover PM stuff, then give them a lab, then start into architecture/design, etc. The nice thing is that the lab the BAs do will be to create the requirements docs that will be used for the architecture/design labs. The PMs will be creating tasks and making work items, etc. While this idea sounds really neat to me, I don't know if it will work from a timing perspective to keep the class moving. In this scenario, the entire class would share one Team Foundation Server and all be TFS clients, as they would in the "real world".
The other item we've been discussing is public training. While I anticipate a lot of private training classes - where we go to the client and teach an entire team (maybe combined with consulting to help them install and configure TFS), I'm curious if there will be demand for public training. At some point there will be, to deal with new hires, etc. I'm just not sure when. I don't want to be one of those companies that throw out dates for public classes just to see if it "sticks", and then cancel it when only one person signs up. Anyone have any ideas?
I participated in an online chat with some members of the Visual Studio team this morning - http://msdn.microsoft.com/chats/
A couple people asked about release schedules. Microsoft has been cautious in recent years about giving release dates - opting for the line "we'll ship when it's ready". I personally agree with this idea, but it is handy from a planning perspective to have some information. So, the summary of the response was Beta 2 would be in late March or April, with RTM in the fall (about 4-6 months later).
That's it, I just wanted to get that out there since it was said in an open forum and a lot of people might be interested.
I actually posted this to the VSTS Newsgroups and realized that not everyone reads those, so I am putting it here as well.
This was in response to someone that had been to the Visual Studio 2005 Training in Dallas as part of the Ascend program. He was trying to reconcile the VSTS labs done there (I was the instructor) to the new build.
Currituck is Work Item Tracking, drill down in there and you will see the ability to create queries, etc.
Hatteras is source control, and the featureset there is richer than what was in Beta 1R. I haven't played with branching/merging yet though.
The Public Build stuff is going to be part of the new build process that was discussed in the Ascend training, it's still not in the Dec. CTP though, that's more of a place holder, similar to reports. On that note, reports still aren't included.
The work item tracking features seem to be working well, as do the basic source control features. I can create project plans in MS Project if I initiate them from Project, not from Team Explorer. In all, most of the features from the Ascend training should work, but you'll have to change the workflow a bit. The profiling doesn't seem to work at all now (even though I posted otherwise to one of the forums). In Beta 1R, instrumentation worked, sampling did not, in the CTP, it detects that you are in a VPC and just aborts.
You should notice a lot more information about MSF Agile, one thing to be sure and do is to go into your services and start the WebClient service. I'm not sure what that is, but it's required to get the process guidance going. I set that to Autostart in my VPC. Once you do that, you can navigate to Documents > Process Guidance for your project in Team Explorer and double-click ProcessGuidance.html - very cool stuff.
First - who made the decision that people don't write applications in ASP.NET? Everything is now a "web site". Maybe it's just me, but I absolutely hate not having a project file. While I don't condone it, I've seen code that has one Web application in ASP 1.1 have a project reference in a solution to another ASP.NET application - that doesn't even seem possible in 2.0 (which might be a good thing - but it will upset some people).
I just spent the last 2 hours trying to create a CLASS and use it in my applciation. I am moving an application from B1R to Dec. CTP and simply renamed my "code" (I hate this too btw) to Application_Code. Well, apparently that didn't work. I could create classes, but I could not use them, as it wouldn't find them in that directory. I even deleted the directory and re-added it with the class files - that didn't help. I was finally able to get things going by removing the directory, then did Add->New Item->Class and it prompted me to create the directory. Apparently there is some magic going on behind the scenes, and that upsets me.