One of the things that made working with the early betas and CTPs of VSTS great was the transparency of the Microsoft team working on the product. Although not perfect, the group as a whole did a good job letting us know what was going on and the direction they were heading. In fact at that time, almost the only detailed documentation on TFS and Visual Studio Team System was in the form of blogs.
Although starting a blog and keeping one active are two different things, I am always glad to see people with interesting things to say blogging. Hence, I am thrilled to welcome Aaron Hallberg, a Microsoft developer on the Team Build team, into the wonderful world of blogging. His first post on extending build steps through a custom task is indeed a great first step.
Welcome to the Blogosphere Aaron - and keep those posts coming...
Notion Solutions has released TeamCI, their answer to continuous integration for Team Foundation Server. For those of you who aren't familiar with CI, it effectively causes a build every time someone checks something into version control. Don't be confused; this isn't implying that a new build is pushed into production on check-in. Rather, the build is completed against the latest complete version of source code to verify that it builds and passes other basic build tests (e.g., Build Verification unit tests, static code analysis, ...). By compiling immediately after a check-in, developers can receive immediate feedback if they break something - as opposed to trying to troubleshoot the cause of a build break long after the offending check-in has occured. In agressive shops it is possible to actually deploy to an integration environment as part of the CI build process, but seems to be the exception and not the rule.
If you're already a CI follower and have been researching or have installed TFS, you're aware that there are other CI options. The most prevalent are the starter kits that can be downloaded. These samples were provided as examples of how to extend Team Foundation Server and Team Build. The samples are relatively easy to get up and running but are also very limited. They support only a single build type out of the box and require you to manually modify code and/or configuration to get them running against even a single build type.
I've had the opportunity to use pre-release versions of TeamCI with a couple of clients; in both cases, the experience has been positive. The install and (should you choose) uninstall is clean and easy. The solution seems to be very stable and well tested. One big different from the starter kits it that it is highly configurable and allows users to specify version control check-ins trigger which build types through an easy-to-use web interface.
If you're already using or investigating TFS and have any interest in Team Build and continuous integration, you owe it to yourself to "check out" TeamCI:
We finally received the license for our primary TFS server at Notion and performed the 'upgrade'. The process was quick and painless; this is a good thing as that is what I had understood and had been telling clients. Simply Add/Remove programs and Change the installation of TFS. Once of the options is to enter the license key... And that is that!
Well - there is one other small things. The registration process resets IIS (at least that is what it appeared to be). So you might want to do it when you aren't in the peak of your normal development or build activities. Enjoy!
Just a couple days after I posted how to work around some problems with MSFWinBuild, the team has posted a new release. It is now delivered in an MSI so that alone renders portions of my original post obsolete. It's quite possible that they've also fixed the other pieces that I mentioned in that post but I haven' confirmed it yet. If you're interested in updating your process guidance, check out the new release!
I'm not going to walk through the details of modifying process guidance. Microsoft has some documentation that goes through a better general overview that you should consider for this purpose. What I want to give you is some tips on getting MSFWinBuild (the tool that is used to compile the Process Guidance source XML) up and running.
Here are some things that worked for me...
- Download your Process Guidance XML source from Microsoft:
- Download the Mvp.Xml binaries from SourceForge. This is required to support the next step.
- Download the MSFWinBuild utility from GotDotNet. I had to so some minor manual work to get the project to compile but these should be fairly obvious for you.
- In the Process Guidance, verify the parameters file (MSFAgileParams.xml for Agile) as the paths are hard coded and you'll need to update them for your directory structure. The CMMI source that I downloaded didn't include the params file; I used the agile version as a template to create a version for CMMI.
- Edit and debug the source XML to meet your requirements. This is most typically done with InfoPath as the included templates make it much simpler than brute-force XML. The files in question are under ...\Windows SharePoint Services\Process Guidance\Source\XML from your downloaded source.
- There is mismatch in the Mvp.Xml library with InfoPath. InfoPath strips a CRLF between <?XML...> tag and the following processing instruction tag; this causes an exception in the Mvp.Xml code and will cause the MSFWinBuild to fail. I've manually fix it by using notepad to clean-up the file after using InfoPath. Believe it or not, this is still easier than trying to manually modify the XML, even with a good XML editor.
- Finally, run MSFWinBuild from the command line and pass in the path to your parameters XML file.
This was a bear to get running the first time but hopefully these little hints will get you closer. Happy documenting!