0 comments
.NET 
*Moved to: http://fluentbytes.com/deep-dive-event-at-the-microsoft-north-carolina-office/
I Just got back from my holiday in Tuscany Italy, and am already on the road again. We had a great opportunity to visit the Microsoft Team System development team in Raleigh NC. The team over there is responsible for the Team Foundation Server, Team Web Access, Team Test, Setup & Ops and Team Build. The last one is of particular interest to us, since we rely on Team System and Team build in particular for our software factory Endeavour.
With the 2008 Product we integrate very tightly with and we want to have the same or even a better experience with the 2010 version coming down the pipe. As you all might now by now when you have looked at the B1 bits, is that there are significantly changes between 2008 en 2010. The biggest part is that team build is now using windows Workflow Foundation as the engine behind the build process instead of the MSBuild scripts we had in 2008. Now that adds some pro’s and con’s in terms of building our custom experience on top of that. E.g one thing we will going to miss is the option to only extend the process on specific predefined build targets and adding in our own steps to the process. With 2010 there is no notion of an extensible build script anymore and you will get an workflow instead that you need to copy and tweak according to your needs. On the other hand, it is really great that you can see a visual representation on what the process will look like in terms of phases and steps that compose the build.
One area where we extended the Visual Studio 2008 IDE is in the build configuration wizard. We extended the default dialog to work with our factory concept of Configuration Items (CI’s) instead of crafting up a workspace and selecting solution from there. See screenshot below to give you an idea on how we extended the build definition dialog.
For us a CI is defined as the unit of design, development, test and deployment. A CI can consist out of multiple modules and a module contains a solution or a MSBuild script that does some funky stuff needed for a certain folder in Version control to be build. We knew upfront that build would change drastically in 2010, but we took the decision to create the 2008 experience first and based on what we learn from that build the same or improved version in 2010.
As part of our elaboration work on 2010, we flew over to the NC office and had our first two days of meetings with the team build team. We had the opportunity to look at the current status of the product and work with the team to discuss how we can integrate our notion of a build with the out of box experience of Team Build.
I must say I am pretty pleased in terms of what I see coming in the B2 timeframe which I cannot discuss in public yet, but I can say we have seen significant improvements to the B1 that is out there at this moment.
Our goal is to have a good design crafted up by the end of the week in terms of how we are going to integrate with team build 2010 and even have some early proof of concepts that will work once we get B2. Once I am able to speak public about the B2 build, you can see a couple of post up here on how we use the 2010 engine and how you can create and manage your own build processes, just the way we are doing that as well.
Cheers,
Marcel
Follow my new blog on http://fluentbytes.com