Comparison of Jenkins, Team Services, Bamboo, and Tutum
Continuous Integration is a core part of the process. Let’s compare some of the top products in the space: Jenkins, Visual Studio Team Services, and Atlassian Bamboo.
From the perspective of establishing a build, all three of these products provide a somewhat similar boilerplate. Bamboo relies on a Build Plan, Jenkins requires creating a Build Project (also called a Build Job), and Visual Studio Team Services relies on Build Definitions.
In Bamboo, a single plan consists of multiple stages. As we discussed earlier, this might involve getting the source code, collecting all artifacts, running all required tests, and any complimentary parts of the process. Each stage is scheduled to be executed in a sequential order. If one of the stages fails, Bamboo will not automatically step over to the next stage. Within a single Bamboo stage there can be multiple Build Jobs that require different capabilities from the build agent. The great thing about Build Jobs is the capability to run those in parallel, where failure no longer impacts any adjacent jobs. In addition, each job is sequenced in Build Tasks.
Jenkins, unlike Bamboo, does not have the granularity of substages within a single plan. A Build Project is similar to a single build plan, with a single build stage, with a single build job, and a number of child tasks. None of these can run in parallel without the help of the Multijob Plugin. One of Jenkins’s key strengths is its third-party ecosystem with hundreds of extensions that make it easy to integrate into any Docker workflow.
Visual Studio Team Services offers the capability to define continuous integration steps as a set of customizable, extensible tasks in a build definition. It also includes support for defining multiple environments like Dev, QA, Staging, and Production environments. Figure 6.13 shows the tasks needed to create the Dev environment, including creating an ARM template, creating Docker containers, and running a PowerShell Selenium script.
