.gif)
I've been working in a fairly big BizTalk project since early this year, and wanted to share my experience working with Team Foundation together with BizTalk projects. The solution became more complex than originally anticipated. So hopefully you can learn from this, and maybe reuse some of the code and scripts I'll share in this series of articles.
But before we get into the details, let me fill you in on the requirements and challenges…
Easy and automated Deployment
- We have five types of environments: Development (several), Build, Test, Acceptance and Production. We have about 30 BizTalk applications with a total of just about 300 ports on each environment.
- We have normalized our BizTalk projects as much as possible, to reduce impact on redeployment, which left us with just over 200 Visual Studio projects. The amount of projects, together with its dependencies, would make deployment quite challenging.
- Each developer must be able to build and deploy there solutions, independently from other developers.
- Due to the complexity of the environments, the deployment process has to be rigid or preferably automated.
Looking at Microsoft Team Foundation (from a far distance), it seems to be the solution to our problems. However, on a closer look there where many obstacles to overcome, before we'd get it to work.
Team Foundation Server
Team Foundation is a server product that integrates with products like MS Excel, MS Project and of course Visual Studio. This is accomplished through Team Explorer which adds functionality such as WorkItem Tracking and Source Control to these products.
Team Foundation also provide the functionality for Team Build, through which Build Managers can compile the projects, run associated unit tests, perform code analysis, release builds on a file server, and publish build reports.
.gif)
The basic practice is this:
- Create a Visual Studio Solution with your projects, and check them in to the source control.
- Create a Build, and select your solution, along with the Build server to use.
- You may optionally choose triggers for when you want the Build to start. Useful for nightly builds etc.(only for Team Explorer 2008)
- Run the Build.
When running the Build, a Team Build Service on the selected Build server will get the latest code, label it, and build it. This is all done according the tfsbuild script that was created for you when you created the Build.
However…
Everything works fine unless, of course, you're trying to build BizTalk projects… As it turns out, Team Build is very similar to MS Build, and normal Visual Studio projects like C# projects, are just MS Build scripts. BizTalk projects, however, are not, and are therefor ignored by the build engine.
We didn't want to invest in Team Foundation 2005, but since we can only use Visual Studio 2005(VS 2008 does not support BizTalk projects yet), we had to use Team Explorer 2005, which gives less functionality. This left the Build Manager to have both Team Explorer 2005 and 2006.
Furthermore, there are no built-in support to deploy BizTalk projects.
Solution
To meet our requirements and utilize the functionality of Team Foundation, we had to start out by setting some design rules.
Since each developer must be able to build and deploy there solutions, independently from other developers, we had to group our projects in groups without dependencies to other groups. This was implemented by grouping the BizTalk projects in to ILS solutions. ILS is a term sometimes used in earlier BizTalk version and stands for Integration Service Layer. But in this case, it's better read as Isolated Service Layer, since there can be no references to projects in other ILS solutions.
Each ILS solution also included binding files for each BizTalk Application and environment.
A BizTalk project has by default two build configurations, Development and Deployment. We used these configurations to set the Target Environment (Development == (local), Deployment == Build server). Later on, when deploying the project through Team Build, we used the Deployment configuration. The accrual compiling of each BizTalk project was done by DevEnv.bat rather than MSBuild. By using the /Deploy flag, we where actually able to build, deploy and create the BizTalk Application in one line of code.
"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv" "MySolution.sln" /Deploy "Deployment"
We ended up creating a handful custom build tasks, which we could use in our build script to:
- Undeploy ILS projects, ports and artifacts
- Build and deploy all ILS projects
- Import Binding files to Build environment
- Generate MSI packages for deployment in other environments with only the deployed artifacts and binding files.
This all led us to be able to be able to, through Team Build, build all ILS projects, deploy them to the build environment, label all sources and open up for an easy deployment for the other environments.
In the next article I promise to get into more details, of the solution.