In this chapter, we will learn about Continuous Integration (CI) and its basic practices. The idea is to be on the same page when we talk about CI in the rest of the book and implement various solutions using TeamCity as a CI server. This chapter will also provide a high-level introduction to TeamCity, its features, and how effective it is when compared to competitive products such as Jenkins and ThoughtWorks' Go.
Continuous Integration is the name given to processes and practices that are involved in regularly integrating the work of several developers into a shared mainline/repository.
My colleague Martin Fowler has written a popular article (http://martinfowler.com/articles/continuousIntegration.html) in which he defines CI as follows:
"A software development practice where members of a team integrate their work frequently, usually each person integrates at least daily, leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."
There are some key practices that must be followed to have an effective CI:
Developers check in code to a common version-control repository. This happens regularly, at least once a day. Everything—source code, tests, database migrations scripts, build and release scripts, and so on—that is needed to get the application running is checked in to this common repository.
Automated builds run off the checked-in code. This is where CI servers such as TeamCity come into the picture. CI servers run automated builds whenever there are changes in the version-control repository. Every commit has to go through this process of automated builds.
The builds include the process of testing the checked-in code. This includes running unit tests, code coverage, functional tests, and code inspection among others. All the tests must be cleared for the build to be certified as a fully integrated build.
The automated builds should result in well-tested artifacts/binaries/executables, depending on the type of the project. The artifacts must be easily available for anyone to download, and generally it is the CI server that provides the artifacts. In many setups, an external artifact repository such as Nexus or NuGet is utilized as well.
The automated build process should be as quick as possible. The compilation, testing, and all the other steps to get the artifacts must be short to provide quick feedback.
The automated process involved in getting the application running on a developer's box must be the same as the one used to run the CI.
CI is about visibility. It must be clear what is happening to the builds and at what stage a particular commit is. Broken builds should be clearly highlighted and quickly acted upon. The CI server serves as a dashboard to this kind of activity. In TeamCity, users can quickly see the broken builds; the status of running builds and test failures, if any; communicate to the rest of the team that they are working on fixing a build; and pause the builds when needed.
CI is also about team discipline. The team should ensure that broken builds are fixed as soon as possible and they never check in to a broken build. Developers must make sure that they run the build locally before checking in. Many of these can be attacked by technical solutions. For example, many VCSes allow the setting up of pre-commit hooks, which can be used to see whether the build is broken, and if so, prevent check ins. However, primarily, these are people's issues and have to be fixed appropriately.
Automated deployments to a test environment against which we can run our automated functional tests is a key requirement in CI. The idea is to reuse the artifacts generated previously and deploy it into the environment without having to rebuild them again. The artifacts have to be agnostic of the environment they will be deployed into.
CI brings a lot of value and benefits to the teams practicing it. Some of these include the following:
Integrating code continuously leads to a more predictable and less tense integration process.
Issues and bugs are identified and fixed earlier in the process. The presence of automated tests means that more bugs are caught as soon as a developer checks in the code. Also, it is inevitable that bugs escape the testing net. In such cases, the automated testing process that has been put in place encourages us to add tests so that similar bugs don't escape as well.
One of the main benefits of CI is that you get reliable artifacts available to deploy at any point in time. The artifact has gone through lots of quality checks and can be deployed with more trust and less risk. This means that software can be delivered to the client/users frequently.
CI encourages automation and helps in removing manual processes. As you build the foundation for automated tests and automated deployments as part of your CI, you are enabled to work further on this foundation and improve upon it over time.
Continuous Delivery (CD) is the name given to the processes and practices through which applications are made available to be deployed into production at any time. CD is the natural extension to CI, which is more a developer team activity. CD is about making the built application ready to be deployed into production at any time. CD brings in the development team, the operations (ops) team, and the business together to ensure the application is released to production in a timely and appropriate way.
Continuous deployment is different from Continuous Delivery. The former is about deploying every build into production, while the latter is about making every build available to be deployed into production. The actual deployment depends on various business and ops factors, and hence not every build might end up being deployed into production. When we refer to CD in this book, we are talking about Continuous Delivery.
Note
CI can be seen as a subset of CD. The point where CI ends and where the parts that were introduced from the following CD begin is not clearly defined, and they can vary from one setup to another. It can be generally defined that CI ends with getting out the artifacts needed to deploy the application, and CD adds in the ability to deploy them into production in a reliable manner.
A key part of CD is what's called the build pipeline, which is what we will discuss in the next section.
The idea of a build pipeline is to have your build process separated into various stages so that multiple builds can run at the same time. Each build can be in a different stage of the pipeline, thereby leading to a better throughput of builds.
A build pipeline helps to get fast feedback for the team. The first stage of the pipeline generally does the compilation to produce the binaries and runs the unit tests. The artifacts from this stage are passed on to the later stages. The first stage is expected to be very fast in order to provide quick feedback to the team.
The later stages perform various kinds of testing such as acceptance/functional testing and performance testing. These stages are generally slower due to their nature (for example, functional tests that hit the UI of the application are expected to be slower than the unit tests) and may be sequential or parallel depending on the requirements and/or resources available. The later stages also involve deployments to various environments such as the testing environment, against which we run the aforementioned tests, and User Acceptance Testing (UAT) environments that might be used for manual testing.
The pipeline will culminate in the deployment of the artifacts to production-like environments such as staging and eventually production itself. Not every stage of a build pipeline is automatically triggered. Deployments to most of the environments outside the environments used for automated testing are probably done manually as and when required. The following diagram shows a high-level view of a build pipeline for a project:
The build stage does the compilation, runs the unit tests, and produces the binaries. The binaries are then deployed into a testing environment for CI purposes. Quick smoke tests are then run to verify that the build is stable. Then, longer acceptance/functional tests are run. All the stages so far were automatic. The pipeline branches into a set of stages performing deployments to various environments such as UAT, staging, and production on one side, and, on the other side, a couple of stages performing performance tests after the pipeline is deployed into a performance environment. Deployment to various environments such as UAT is generally manual and is done as needed. The exact implementation of a build pipeline will vary from project to project and team to team. Typically, there are other dependencies such as libraries that come into the picture, but the overall structure should be similar to this.
The build pipeline, apart from aiding in fast builds and quick feedback, also enables you to ensure that only the builds that have gone through the rigorous testing process are finally deployed into production.
The build pipeline is also called the deployment pipeline.
TeamCity is a CI server from JetBrains and comes with a lot of features out of the box to get you started quickly with CI for your projects.
As a CI server, TeamCity can detect changes in version-control repositories and trigger builds whenever new code is checked in. TeamCity can be configured to perform the build activities, which includes the compilation of source code, running unit tests and integration tests, deploying the built executables into a testing environment to perform functional tests, and exposing artifacts for downloads.
TeamCity is designed to help you follow the best practices of CI. With its ability to download artifacts from another build configuration, for example, TeamCity enables you to follow the approach of build once and deploy everywhere. TeamCity is feature-rich and flexible enough to allow you to follow the practices that suit your team and your needs the best.
This book will be using TeamCity 8.0.x, but we will also be looking at some of the newer features of the 8.1.x release.
Before we get all excited about the amazing features that TeamCity brings to the table, it is worthwhile to explore the licensing options available. TeamCity is a commercial product from JetBrains, but the licensing options are designed so that small teams can get started with TeamCity for free.
TeamCity comes with the Professional Server License for free. It allows you to run a TeamCity server, which can have up to 20 build configurations, and use three build agents. In my experience, this is pretty sufficient for small projects. Teams can easily start their CI setup with TeamCity, and if they find a need for more configurations/agents later, they can do so at that point in time. Additional agents can be bought separately, which also bumps up the maximum number of build configurations allowed by 10 each.
For bigger teams and projects, there is Enterprise Server License. This license enables you to have unlimited build configurations and agents with your TeamCity server. This also includes upgrades to the latest version of TeamCity for a year.
JetBrains also provides Open Source License, which is given for free to noncommercial open-source projects that qualify. This license is similar in features to the Enterprise Server License mentioned previously.
You can read up about the latest TeamCity licensing options at http://www.jetbrains.com/teamcity/buy/.
With the licensing options discussed, it's time to talk about the goodies that TeamCity comes with. As previously mentioned, TeamCity is feature rich. This section will focus on highlighting the most important features of TeamCity, especially with respect to the overall aim of setting up an effective CI.
TeamCity comes with great support for various technologies such as Java, .NET, Ruby, Android, iOS, and much more.
For example, if you have a .NET project that uses the Powershell-based PSake framework for its build, you can use the Powershell runner to run your build off a PSake build script.
The ability to support most platforms/technologies with very well thought out and first-class features make TeamCity a valuable tool to help you quickly get started with your CI setup.
This first-class and extensive support doesn't imply that TeamCity doesn't have or can't have plugins. It has quite a lot of them and for various purposes. Both JetBrains, and the community at large write plugins for TeamCity. Many of these plugins come bundled with TeamCity itself.
Many of these plugins are very useful and some of them are downright cool. A more recent plugin adds torrent abilities to TeamCity so that agents can download artifacts using the BitTorrent protocol, when appropriate.
A comprehensive list of available plugins can be found at http://confluence.jetbrains.com/display/TW/TeamCity+Plugins.
TeamCity comes with a REST API, which itself is a bundled plugin, that you can use to perform remote actions such as triggering builds, getting the status of running builds, and downloading artifacts among others. Depending on the particular requirements of your CI setup, the REST API can prove to be very valuable.
As mentioned in the section where CI was introduced, version control system (VCS) plays an important part in CI. CI servers must support a wide range of VCSes, and must provide for flexible configurations that cater to the team's needs.
Note
We will be looking at VCSes in detail, and the role that they play in CI, in Chapter 3, Getting Your CI Up and Running
TeamCity supports almost every major VCSes such as Git, Mercurial, Subversion, CVS, Microsoft Team Foundation Server, and Perforce. TeamCity enables you to view the changes from the VCS for each of your builds and also provides high-fidelity diff views right in the browser. Triggering builds by looking at the changes in VCS can be fine-tuned to any extent. For example, you can avoid builds being triggered if changes happen within a particular directory in your repository, with other directories triggering builds as normal.
Another important CI practice that TeamCity enables centers on the visibility and tracking of what is happening and what has happened. TeamCity provides a nice dashboard view of the projects and the build configurations in which builds are running, failing, and so on. The following screenshot of a TeamCity demo server gives a good view of the typical state of TeamCity's overview page:
With user management features such as authentication and audit, it becomes easy to track who did what. A user can communicate, for example, if they are working on fixing broken builds. Other users can also assign people who are/have to investigate the broken builds.
TeamCity provides lots of features to track historical data of builds. With the help of statistical reports and graphs, you can quickly learn about the various characteristics of a build, such as build time and number of tests.
We can also set up and fine-tune how historical data is cleared up or preserved through the Build History Clean-up features. Builds that are promoted, to say production, can be pinned for eternity. Builds that ran a few days or even a few months ago (called history build) can be replicated, if needed.
All the features that TeamCity offers would be for naught if TeamCity makes it very difficult for you to make use of them. Thankfully, this is not the case. Getting started with your CI setup is a breeze with TeamCity. The configuration interface to set up projects and build configurations is straightforward. The main configuration items are clearly highlighted, and more advanced ones are available under the right levels of nesting.
TeamCity also provides features such as templates, a set of common settings from which build configurations can be quickly spawned that make it extremely easy for you to set up more and more build configurations.
The simplicity and power of TeamCity can be explained with one of my most favorite features. When you enable NuGet support in TeamCity, you can double up TeamCity as a NuGet repository feed by simply publishing the NuGet packages as artifacts; simple and intuitive!
TeamCity is also well documented and has a huge community of users around it. This makes it very easy for teams starting with TeamCity to make the right decisions when setting up their CI.
As mentioned previously, build pipelines are the ideal way to set up CI (and CD) for your projects. TeamCity has built-in support for such pipelining/chaining of build configurations.
Using the Snapshot dependency feature in TeamCity, we can easily configure build chains / build pipelines. TeamCity also comes with a nice visualization for build chains. The following screenshot shows one such build chain:
TeamCity comes with all the bells and whistles to manage a build farm or grid of agents. TeamCity makes it a breeze to manage tens, hundreds, or even more agents that may exist in the build grid. TeamCity can provide workload statistics, distribute load across agents, enable you to run builds on all the agents or only specific agents, and more. The following screenshot shows the Load Statistics Matrix of a demo TeamCity server:
Also, with its Amazon EC2 integration, TeamCity can spin up VMs on EC2 and run the builds and bring them down as and when needed.
TeamCity doesn't even mandate all the agents to have the version control tool configured, as the server can do the checkout and send the files over. The server can also upgrade agents automatically.
TeamCity has very well thought out integrations with various IDEs such as IntelliJ IDEA (another JetBrains product) and Visual Studio. Through the TeamCity plugins for these IDEs, it is possible to look at the status of the builds, the reason for the failures, and even trigger and pause builds without having to leave the comfort of the IDE.
Additional features such as precommit and personal builds are available through such IDE plugins.
The preceding set of features only scratches the surface of TeamCity. TeamCity has a lot more to offer. We will be exploring these and many other features of TeamCity in the coming chapters.
TeamCity is a very popular and feature-rich CI tool. There are many other worthy CI tools as well, and it is prudent to compare TeamCity with these other tools. Here, we will be comparing TeamCity with Jenkins and ThoughtWorks' Go. The idea is to look at the biggest features of these two tools and compare them with those of TeamCity.
Jenkins (http://jenkins-ci.org/) is a very popular open source CI tool. It has a huge community around it and is used by many organizations and teams. The biggest advantage of Jenkins is its open source nature and the huge collection of plugins. There is a plugin in Jenkins for almost anything that you would want to do. With an active community around it, more and more plugins are added to tackle newer requirements.
What is probably the biggest strength of Jenkins is also its biggest weakness. To get any sort of work done with Jenkins, one has to install a multitude of plugins that interact in weird ways with each other just because they are written by different authors. To set up and visualize the build pipeline as described earlier, Jenkins will require the use of many plugins such as the Build Pipeline plugin, Build Name Setter plugin, Parameterized Trigger plugin, Copy Artifact plugin, Throttle Concurrent Builds plugin, and Promoted Builds plugin. That are a lot of plugins that you need to learn about and configure appropriately. It also doesn't help that there are many plugins to achieve the same thing, thereby adding to the confusion. With various plugins that need to work together, which were probably not tested together or even intended to work together, it becomes a pain to set up complicated pipelines with Jenkins. Not to say that complex setups aren't possible, but they could have been easier.
The following screenshot shows a sample build pipeline as visualized by the Build Pipeline plugin:
Jenkins is also not an ideal CI server for some platforms/technologies such as .NET. While there are some plugins available, there is not a whole lot of support for such platforms.
TeamCity comes with the right amount of bundled features to give you the feel that the platform of your choice is a first class citizen in your CI server. You also get the features needed to set up and maintain complicated pipelines, and just like Jenkins, TeamCity can be extended with plugins through its plugin API. As mentioned previously, there are a lot of plugins available for TeamCity as well, and many of these are open source too.
Go (http://www.go.cd/) is an open source CD/CI tool from ThoughtWorks Studios. It is a descendent of CruiseControl, one of the earliest CI servers. Go is available for free, with an option to buy commercial support.
Note
Go was a commercial tool but has been open sourced recently. The license terms for Go were very similar to that of TeamCity and allowed small teams to use Go for free.
Pipelines form the heart of Go. It has been designed with the build/deployment pipeline in mind, and as such, the visualization and configuration of pipelines is first class. There is no need to wire different stages of a pipeline manually, as they all fit together automatically. The following screenshot shows the pipeline visualization of Go in action:
Go's plugin API is very limited and so is the number of plugins. The support for platform-specific task runners is very minimal at the moment. While all of the CI servers that we have talked about so far support the ability to run any arbitrary shell commands from the builds, it is good to have specific runners for specific tools. Having a Maven runner, for example, means that the setup is straightforward. One can specify the POM file, the goals, and other required parameters in the appropriate fields, rather than having to specify the exact command line in a shell runner.
In general, Go can be seen to have a limited set of features and doesn't provide a lot of flexibility. While tools such as TeamCity and Jenkins can be bent to meet our peculiar requirement, we might find that doing so with Go is not possible. This is mainly due to two reasons: the feature set of Go is small (but growing) and the developers of Go want the users to follow certain practices, hence restricting the options available. For example, in Go, templates can only be created for a pipeline. In TeamCity, we can create a template at the build configuration level (equivalent to a stage in Go).
The comparisons given here, obviously, aren't extensive but give you an idea about the most important advantages and shortcomings of the different tools. This can be seen as a starting point of your investigations into these tools.
In this chapter, we defined the practices and processes behind Continuous Integration and the benefits that it brings to the teams practicing it. We also had a high-level look at the build pipeline, which we will be using as the basis to set up CI for different technologies in the upcoming chapters.
The chapter also introduced TeamCity and its various licensing options, in addition to looking at the most important features that TeamCity brings to the table from the point of view of an effective CI implementation. We also compared TeamCity with a couple of its competitors to see how well it is placed in this space.
In the next chapter, we will look at the different ways of installing TeamCity on various platforms.
