Introduction to Amazon Code Pipeline with Java part 4: comparison with TeamCity and Jenkins

Introduction

In the previous post we saw how to add a custom job runner of type Test to an existing pipeline. These runners cannot be added to a pipeline during the setup process, they can be applied when updating one instead. We went through an example with the Apica Loadtest job runner and saw how to specify the necessary inputs for the job that the runner executes.

In this post we’ll discuss some of the key differences between TeamCity/Jenkins and CodePipeline (CP). TeamCity (TC) and Jenkins are quite similar so I will treat them as a group for this discussion.

Installation

Both TC and Jenkins web based services that you can download and start using on your CI server and even start testing on your local machine. Here’s the TC download page and here we have the Jenkins download page. We can add our own projects and custom build runners after the installation. Jenkins is completely free and open-source whereas TC is free up to a number of builds, 5 I believe.

We’ve already seen that there’s nothing like that in Amazon. CodePipeline cannot be installed on a CI server. Instead, it’s a service offered by AWS and you’ll need an AWS account. It’s also a paid service but you can try it for free for a period. The pricing details are available on this page.

Build agents

Both TC and Jenkins come with their own build agents. We have our TC CI server on a Windows machine and there’s also a TC Windows service that monitors the progress of each build. It’s possible to have this build monitoring agent and a build agent on the same server but in practice the build agent is almost always located on a designated build server. The main point is that the build agent will also start and monitor any custom plugin you may develop yourself and add to a given project.

By now we know that CP cannot be installed on its own. CP also has a built-in job monitoring service that will trigger the stages and actions in the pipeline. However, if you build your own custom job runner for CP then you must also build and deploy the agent that will monitor the job execution. The CP process will only give a hint to custom action that there’s a new execution starting but if you don’t catch that signal in your job agent then nothing will happen. CP happily waits until a timeout is reached which is 1 hour.

We’ll look at the CP architecture in more detail in the upcoming posts so that this becomes clearer.

Custom build runner development

TC and Jenkins allow you to build your own plugins of various types. The Apica Loadtest build runner we saw in the previous post is also available for TC and Jenkins. E.g. here’s the TC equivalent in the GUI:

The main thing to note here is that I added these UI elements by following a couple of guidelines and conventions specified by TC. By following these rules we can extend the TC and Jenkins GUI to a great extent: we can add new elements on the setup page, we can add new tabs, new links, graphs etc. The degree of customisation is very high as long as you can find the correct extension points. Normally the source code of TC and Jenkins plugins are open-source so you can view how other developers solved a specific problem.

CP plugin development is very different. The CP UI is not customisable to any degree. All custom elements required for the job runner must be custom built and located outside CP. We saw a couple examples in the previous post, such as the external login and setup page. They are definitely not part of the CP GUI. Also, the source of the job runner isn’t necessarily open source, it’s not a requirement in order to be included on the custom job runners’ list.

In the next post we’ll start looking into the CP architecture.

View all posts related to Amazon Web Services and Big Data here.