Continuous Integration/Team Builds with Team Foundation Server

Topics: General Discussion Forum, Service Factory Modeling Edition Forum
May 21, 2008 at 12:54 AM
I'm about to start customizing WSSF, and I have a concern about how this will work. I understand that when WSSF builds, it registers itself in the Experimental Hive. Yet, if I build my customized version in a nightly build, and want to use WSSF in builds of my web services that are modeled using WSSF, then don't I need to get WSSF into the regular hive? I could run the installer after the WSSF build, but we're warned against that.

What's the story here? Is anyone else doing Continuous Integration or using Team Foundation Server Team Build? A search turned up nothing.

We're using VS2008, if that matters.

Thanks,
John
Jun 9, 2008 at 8:16 PM
Are we really going to be the first to use WSSF with Team Build? Has anyone else used WSSF in a continuous integration environment?

johnwsaundersiii wrote:
I'm about to start customizing WSSF, and I have a concern about how this will work. I understand that when WSSF builds, it registers itself in the Experimental Hive. Yet, if I build my customized version in a nightly build, and want to use WSSF in builds of my web services that are modeled using WSSF, then don't I need to get WSSF into the regular hive? I could run the installer after the WSSF build, but we're warned against that.

What's the story here? Is anyone else doing Continuous Integration or using Team Foundation Server Team Build? A search turned up nothing.

We're using VS2008, if that matters.

Thanks,
John



Jun 9, 2008 at 9:38 PM

John,

What is it exactly you are trying to accomplish here, is it using team build to build you customized version of WSSF of are you referring to using team build to build the products you produced with WSSF?

We are using team build for our (heavily) customized version of WSSF. A few months ago we published a paper on MSDN that describes the issues with team build in combination with Guidance Packages and Domain Specific Languages. Although this paper is written against VS2005 a lot of the content is still valid for VS2008. Not all issues described in this paper apply to the latest version of WSSF but hopefully this paper helps you solve the issues you will find.

Both of the scenarios mentioned above are possible but do require some effort J

Edward

Jun 9, 2008 at 10:07 PM


EdwardBakker wrote:

John,

What is it exactly you are trying to accomplish here, is it using team build to build you customized version of WSSF of are you referring to using team build to build the products you produced with WSSF?

We are using team build for our (heavily) customized version of WSSF. A few months ago we published a paper on MSDN that describes the issues with team build in combination with Guidance Packages and Domain Specific Languages. Although this paper is written against VS2005 a lot of the content is still valid for VS2008. Not all issues described in this paper apply to the latest version of WSSF but hopefully this paper helps you solve the issues you will find.

Both of the scenarios mentioned above are possible but do require some effort J

Edward



Edward, thanks for the link to the paper. I hadn't seen it before. I've now got a stack of papers printed out from that same area on MSDN.

Yes, we're working to customize the WSSF for ourselves, and need the customized version to build in nightly, and even in CI builds.

Of course, we then need the customized version to be available:

  1. To developers who will build their applications using the customized version
  2. To the nightly and CI builds being used by those developers
  3. Any "framework" components of WSSF would then need to be deployed as part of the applications built in #2. I don't know that there are any such components at present, but we may add some.

I will read your paper and reply with any comments. Hopefully, it simply solves all of my problems. ;-)

Thanks,
John

Jun 18, 2008 at 5:54 PM

Part two of the paper says:

The site http://www.codeplex.com/sfteambuild has an implementation of a check-in policy for this verification step, as well as other useful tasks and policies to be used in similar approaches.

Unfortunately, I can't locate that.

I'm getting my WSSF to build now in a "desktop build" using the Team Build project file, except for the setup project. I think the issue there is that I need to regenerate the templates in the setup project to contain the correct paths to the binaries.

Do you know if anyone ever got a Team Build to work with WSSF? I found a number of paths that were simply not going to work, and had to change them. I also had to ensure that the DevEnvDir property / environment variable always ended with a "\", since most of the paths assumed it did.

Jun 18, 2008 at 6:56 PM
Unfortunately we had some issues getting the stuff ready for publishing on the site mentioned, so you are right about that.
I don't know if anybody has the Team Build working for the latest version of WSSF but I do know we have implemented it sucessfully for the previous version of WSSF and a couple of other factories and DSL's. They issues are the same. Did you try the workarounds we described in the paper to solve the issues with the incorrect paths? We also described a way to regenerate the templates during a Team Build, did you try that? If so, what are the exact issues you are facing?

Edward




johnwsaundersiii wrote:

Part two of the paper says:

The site http://www.codeplex.com/sfteambuild has an implementation of a check-in policy for this verification step, as well as other useful tasks and policies to be used in similar approaches.

Unfortunately, I can't locate that.

I'm getting my WSSF to build now in a "desktop build" using the Team Build project file, except for the setup project. I think the issue there is that I need to regenerate the templates in the setup project to contain the correct paths to the binaries.

Do you know if anyone ever got a Team Build to work with WSSF? I found a number of paths that were simply not going to work, and had to change them. I also had to ensure that the DevEnvDir property / environment variable always ended with a "\", since most of the paths assumed it did.




Jun 22, 2008 at 11:30 PM
Edited Jun 22, 2008 at 11:39 PM


EdwardBakker wrote:
Unfortunately we had some issues getting the stuff ready for publishing on the site mentioned, so you are right about that.
I don't know if anybody has the Team Build working for the latest version of WSSF but I do know we have implemented it sucessfully for the previous version of WSSF and a couple of other factories and DSL's. They issues are the same. Did you try the workarounds we described in the paper to solve the issues with the incorrect paths? We also described a way to regenerate the templates during a Team Build, did you try that? If so, what are the exact issues you are facing?

Edward



Edward, I'm doing much better now.

I started by simplifying the steps in your document, at least to start with. The greatest simplification is to assume that all SDKs are installed on the build machine, which is true in our environment. That simplifies things greatly.

Rather than depend on the SDC tasks, I've written my own XML editor task, and I've used this to edit the .wxs files. I output the edited files to obj\$(Configuration) and set the Compile itemlist to the set of edited files, so that the Wix targets compile the files that I've edited (I use a different item list as input to my new task, so there's nothing in Compile until I put it there).

I now have only 14 errors left (down from 206). The next question is about the purpose of the Guidance Package\bin\Release\Lib folder and the other folders under bin\Release? Are they meant simply as a place to consolidate build outputs as opposed to forcing Wix to pick up the outputs in their original scattered locations? If so, then in a Team Build, these should probably live under $(Outdir)\Lib etc.


By the way, I'm very glad for any help you are able to provide, and the MSDN article has been helpful. However, I have to tell you (and others involved in this area) that it really doesn't look good that I have to do this stuff on my own. If software factories are going to be useful in the Enterprise, then they need to work, out of the box, with "Enterprise"-level tools like Team Build.

I recommended WSSF, in part, due to my false assumption that any serious software coming from any part of Microsoft, even Patterns and Practices, would naturally work in a current Microsoft environment. Yet we had to wait until February for versions of WSSF, GAT and GAX that worked properly with Visual Studio 2008 (released in November), and it now looks like no effort was made to make WSSF work in a Team Build. The MSDN articles were written in October 2007, yet here in June 2008, I'm spending time making WSSF simply build as opposed to spending time customizing it to meet our needs.

It's my mistake to have assumed this would "just work", but the fact is, it would benefit Microsoft and others interested in the success of Software Factories, if future versions of this and all other Software Factories from Microsoft did "just work".
Jun 23, 2008 at 6:55 AM

You are right, things get easier if the SDK is installed on the buildserver. In our case we were not allowed to install it so therfore we started our article from that scenario. You are right about the folders ('Release') and they live under $(Outdir) as you mentioned.

And yes, I totally agree with comment about the "painfull" experience of making all of this work in a TeamBuild environment. Now we have done it a few times, things get easiers but of course this scenario should be much more easier to implement! So let's hope "they" listen...

 


johnwsaundersiii wrote:


EdwardBakker wrote:
Unfortunately we had some issues getting the stuff ready for publishing on the site mentioned, so you are right about that.
I don't know if anybody has the Team Build working for the latest version of WSSF but I do know we have implemented it sucessfully for the previous version of WSSF and a couple of other factories and DSL's. They issues are the same. Did you try the workarounds we described in the paper to solve the issues with the incorrect paths? We also described a way to regenerate the templates during a Team Build, did you try that? If so, what are the exact issues you are facing?

Edward



Edward, I'm doing much better now.

I started by simplifying the steps in your document, at least to start with. The greatest simplification is to assume that all SDKs are installed on the build machine, which is true in our environment. That simplifies things greatly.

Rather than depend on the SDC tasks, I've written my own XML editor task, and I've used this to edit the .wxs files. I output the edited files to obj\$(Configuration) and set the Compile itemlist to the set of edited files, so that the Wix targets compile the files that I've edited (I use a different item list as input to my new task, so there's nothing in Compile until I put it there).

I now have only 14 errors left (down from 206). The next question is about the purpose of the Guidance Package\bin\Release\Lib folder and the other folders under bin\Release? Are they meant simply as a place to consolidate build outputs as opposed to forcing Wix to pick up the outputs in their original scattered locations? If so, then in a Team Build, these should probably live under $(Outdir)\Lib etc.


By the way, I'm very glad for any help you are able to provide, and the MSDN article has been helpful. However, I have to tell you (and others involved in this area) that it really doesn't look good that I have to do this stuff on my own. If software factories are going to be useful in the Enterprise, then they need to work, out of the box, with "Enterprise"-level tools like Team Build.

I recommended WSSF, in part, due to my false assumption that any serious software coming from any part of Microsoft, even Patterns and Practices, would naturally work in a current Microsoft environment. Yet we had to wait until February for versions of WSSF, GAT and GAX that worked properly with Visual Studio 2008 (released in November), and it now looks like no effort was made to make WSSF work in a Team Build. The MSDN articles were written in October 2007, yet here in June 2008, I'm spending time making WSSF simply build as opposed to spending time customizing it to meet our needs.

It's my mistake to have assumed this would "just work", but the fact is, it would benefit Microsoft and others interested in the success of Software Factories, if future versions of this and all other Software Factories from Microsoft did "just work".