So you thought that I would give away the secrets this time huh? I’m just kidding it will all be revealed soon in the last part of these series.
Anyway, how come I make this artistic pause? Anyone? Let’s begin with some basics:
- Automated builds or continuous integration is useless if the team using it isn’t committed to solving problems with the builds and/or maintaining the builds.
- Visualize the status of your builds on digital boards, flat screens or with emergency lights/sounds and make sure everyone in the project knows the status of the builds.
- When all builds are green and all tests are green in your project you are in what I call a normal stage. In a normal stage you should make time for small improvements throughout your team i.e. refactoring, code reviews etc.
- If any builds are red or any tests are red in your project you are in what I would call a deviate stage. In a deviate stage you should really work as a team to solve the deviations and most importantly learn from it and finally make improvements in how your team works.
Is your team committed to these basics? If not take a good look at the benefits of automated builds:
- Always the same automated way of compiling, building and deploying your codebase.
- No more manual releases.
- One single location for the compiled binaries i.e. the drop folder. Make sure that all deployment flows from the drop folder i.e. establish one deployment method that uses the contents of the drop folder and use it on every environment starting with your own every morning.
- Automated regression tests.
- Intact source tree
- <Enter a clever reason here>
Still not convinced? Well then you should really visit a dev shop where they’re committed to this and compare their speed, quality, agility and team spirit to your own; and I’m sure you will get inspired.
Ok, you finally got your build environment installed and tested with a simple Hello World build and you’re ready for the next phase.
Before I show you the good stuff J there is some tools that you need to succeed with this quest:
- You’ll need basic knowledge of MSBuild and TFSBuild or you could copy and paste my build pattern if you like J
- I mainly use the OOB tools that come with .Net framework and BizTalk i.e. BTSTask, BTSWCFServicePublishing and GacUtil with my builds because I find them to be stable, supported and generally well documented.
These tools should already be installed in your environment but you’ll have to make sure that you have the correct permissions on your TFSBuild service account to use them.
- I use BizTalk MsBuild Generator to start and stop BizTalk applications so you will need to download the tool and extract BizTalk.BuildGenerator.Tasks.dll and BizTalk.BuildGenerator.tasks. These two files are then placed under source control with the teambuildtype.
- If you need automatic generation of the BizTalk binding-files from a template (for different target environment for instance) I have found the XMLPreprocess tool very helpful.
- In the early years I used the SDC tasks but it’s no longer supported but there is still a lot of good stuff in that package if you want to learn MSBuild in more depth. The replacement is called MSBuild Extension Pack if you want to check it out. While you’re at it you should really checkout MSBuild Explorer.
Try to install the tools in a common directory i.e. C:\BuildTools or something similar and keep these tools under source control at all time.
Until next time have a good one!
If you read my earlier blog post about a mysterious error from BTSTask you already know that I’m currently helping a customer with automated TFS 2008 builds for BizTalk 2009, if you haven’t read my earlier post here’s your chance.
Firstly you’ll have to setup some sort of build server and there’s at least 3 ways you can do this:
- Have the build server installed separate from the “build BizTalk server”
- Have the build server start a virtual snapshot of a “build BizTalk server”
- Have the build server installed on the “build BizTalk server”
I typically skip the first option because it usually end up in me having to write some kind of remote execution scripts (PSExec) or starting the scripts with timer jobs. Either way the overall build pattern turns out more complex than it needs to be or managing the build (yes you will be managing your builds) will be harder.
The second option would be the top choice for me if the customer has TFS 2010 and Lab Management in place. I know there are virtualization options for TFS 2008 but I’ve never user them myself.
So this leaves my with the option to have the “build BizTalk server” and the build server on the same box which makes it a lot easier.
Remember that you’ll need to install and configure the BizTalk server and remember to install/configure these options during the installation of the BizTalk server:
- Developer Tools and SDK
- Additional Software / Project Build Component, build component used by TFSBuild.
When the BizTalk server is installed and configured you’ll need to make/configure these options:
- The service account for TFSBuild need to be added to the local Administrators group, required to install/uninstall assemblies to the GAC.
- The service account for TFSBuild need to be added to the BizTalk Administrators group, required to use BTSTask operations.
As a common practice I always create a Hello World build type to test that my build server is working correctly before moving on with any advanced build patterns with automatic deploy for instance.
Hope you’ll enjoy this first part of the series!