TeamCity is a very user friendly and easy to set up continuous integration server that we use to build and deploy to our development site to preview and test our progress during the development process.
Why did we choose TeamCity over CruiseControl.NET?
For a couple of months we used CruiseControl.NET but we found it to be slow to set up and hard to get feedback when a build failed. CruiseControl.NET has a very good community to help with all your issues but TeamCity has very good official documentation and best of all, provides an extensive build log on every successful and failed build! This means if a file was not deployed with a successful build, you can check the build log and review it; it could be down to the file not being included in the project. TeamCity also includes a very nice RESTful API which will soon allow us to extend our set up to start automating things.
Our source control and TeamCity set up
Our developers each have their own working version of the website containing the features they are currently working on and any committed work the other developers have committed to the GIT repository. This means they can finish any functionality before other developers can see it; this is especially important when our developers are working on major changes that can temporarily break the build.
When our Umbraco developers commit work, which can be anything from simple CSS changes to very complex management systems, our Continuous Integration (CI) Server (TeamCity) will know that a new commit has become available. We currently have TeamCity configured so that any of our developers can log on to TeamCity and commence the build, however, you can have TeamCity automatically rebuild when the a commit is pushed. TeamCity pulls the new changes to its own clone of the repository and builds the configured project. If this build is successful, it then publishes the built files to the Development Website Server using IIS Web Deploy 3.0.
Our set up uses parameters that are configured on the 'Edit Project' page that are passed in to the build configurations. This allows us to create copies of project setups and change the parameters to suit the new project. This can be automated but for now this allows us to have a new build set up in a matter of minutes.
Why is our set up like this?
This set up currently suits our needs, obviously there will always others who approach this different depending on their own needs.
We think the benefits of our set up are:
- Developers can commit and push their changes between each other until they are happy that the current commits are stable and a new version can be released. This is the point where they activate a build on the CI Server.
- Project Managers and Testers can test the current deployed development build to find bugs and preview progress to clients.
- TeamCity allows us to see its very extensive and descriptive build logs.
- Very fast and easy to set up with the help of parameters!