Trusted by thousands of customers globally.
Browse our library of ebooks, briefs, reports, case studies, webinars & more.
March 6, 2017
In a world of shortened release cycles, agile development practices and continuous integration (CI), it is imperative teams have access to a stable tool which can manage the process of building, testing and deploying projects as changes are made. For many years, Jenkins has been the tool of choice among Java developers, but as many projects have moved into the cloud, and in particular, Amazon’s AWS ecosystem, other tools are gaining traction. One such tool is AWS CodePipeline.
Machine data holds hidden secrets that deliver true insights about the operational health of your AWS infrastructure. Learn more about operational visibility from AWS today!
Whether you’ve been operating in a CI environment for years, or you’re new to the concept, it’s important to know what options are available and what features and advantages one tool has over another. This article will look at Jenkins and AWS CodePipeline in-depth and present reasons why you might select one over the other, or why you might consider using a combination of the two to achieve your CI goals.
If you’ve had exposure to the Java community in recent years, you’re probably already familiar with Jenkins and its capabilities. But in case you’re newer to the community, or don’t know too much about Jenkins, Jenkins actually began life in 2004 at Sun Microsystems as the Hudson project. Hudson was developed as an open source CI tool written in Java, and grew until it began to replace popular alternatives in the late 2000s.
Following the acquisition of Sun Microsystems by Oracle, and the decision to begin developing a commercial version of the tool, the community decided to continue the project under the name of Jenkins. Thus in 2011, Jenkins was born.
Due to its plugin architecture, Jenkins is highly extensible, and through continued development has remained a dominant force in the realm of CI tools.
Introduced by Amazon in 2015, AWS CodePipeline is a service which allows the user to configure a CI workflow or pipeline within the AWS ecosystem. Using either the Amazon Command Line Interface (CLI), or clean UI configuration process within the Amazon Console, the user can define a process which includes sourcing, building and deploying an application or service.
On screen display of an AWS CodePipeline running after being triggered by a code change.
While it is an AWS service, and one that is configurable with other AWS services like CodeCommit, CodeBuild and CodeDeploy, the pipeline can also be configured to use third-party services like GitHub, and even Jenkins itself.
Well-known companies such as Facebook, Intel, and Netflix currently use Jenkins as a CI solution. In contrast, while I’ve been able to find a few companies which have adopted CodePipeline as a CI solution, their names weren’t immediately recognizable.
So why compare them? Simply put, times change, and a market leader one day might be gone the next. It happens in many industries, but in the IT industry this is far more prevalent, especially in recent years as the cloud has made developing new tools and services so much easier. Disruption of the status quo is the name of the game.
While I personally don’t think Jenkins will be gone anytime soon, AWS CodePipeline is worth considering, and I’d like to share why.
The biggest difference by far between Jenkins and CodePipeline is in the offering itself. Jenkins is an open source solution which can be downloaded and installed free of charge. (Well, free unless you factor in the cost of the physical server, or EC2 instance that you need to provision in order to host it, and the time required to install and maintain it.)
AWS CodePipeline is a service available to any user of the AWS ecosystem. Within minutes of making the decision to try it out, you can be configuring your CI pipeline in the cloud. As with other AWS services, you don’t have to be concerned with infrastructure provisioning or maintenance. And at the time of this writing, a CI Pipeline can be had for just one dollar a month.
CodePipeline is customizable, maintenance is taken care of by Amazon, and you’re not going to be fielding Jenkins support questions from your development team about updates, compatible plugins and why that one project’s build keeps failing.
Part of what makes Jenkins so versatile is the plugin architecture. If there is a specific type of technology you’d like to include in your CI process, there is probably a plugin out there that can do the job, and on the off chance that there isn’t a plugin, either you or someone with a little development experience could probably write one.
AWS CodePipeline is configurable for the use of multiple tools, and while the options aren’t limited to just AWS service offerings, it is a rather limited list. However, if you’ve committed to using AWS as your cloud provider, or you use tools such as GitHub as a source code repository, CodePipeline may have all the options you need.
CodePipeline supports:
Additionally, if CodePipeline doesn’t provide support for a particular process, it is possible to add custom actions. Unfortunately, these actions must be added through the Amazon CLI, and cannot be added through the UI in the Amazon console. Additionally, AWS Lambdas can be included in the pipeline to extend functionality. You can find out more about these Advanced Tasks in the AWS CodePipeline documentation.
[Learn More: AWS Monitoring]
As the guy on my team who has been handling automation stuff for the past couple of years, I’m rather fond of Jenkins. Jenkins has served me well, and generally does what I ask. That aside, with its versatility and ability to be customized, there is a reason I’m the go-to guy on the team. Jenkins is not necessarily difficult to use, but it can be complex at times.
AWS CodePipeline is very clean, and integrates exceptionally well with projects in the Amazon ecosystem. With Jenkins, however, security is controlled on the server itself. With CodePipeline, it falls nicely under the same IAM controls as other AWS services. And, as I mentioned above, someone familiar with AWS, but new to CodePipeline could have a pipeline configured and running within a couple of hours.
For teams and organizations already using Jenkins, perhaps now might not be the time to switch, but CodePipeline is definitely worth taking a look at. The more astute of you may also have noticed that Jenkins is a build provider option within CodePipeline, and there’s the option to keep your build logic in Jenkins, while at the same time integrating it into a new CodePipeline pipeline. Jenkins and CodePipeline can work well together, and need not be considered mutually exclusive.
If you’re new to AWS and new to CI, then selecting CodePipeline is definitely something you and your team should consider. You can learn more about CodePipeline from the AWS CodePipeline User Guide.
Reduce downtime and move from reactive to proactive monitoring.
Build, run, and secure modern applications and cloud infrastructures.
Start free trial
Mike Mackrory is a Global citizen who has settled down in the Pacific Northwest — for now. By day he works as a Lead Engineer on a DevOps team, and by night, he writes and tinkers with other technology projects. When he's not tapping on the keys, he can be found hiking, fishing and exploring both the urban and rural landscape with his kids. Always happy to help out another developer, he has a definite preference for helping those who bring gifts of gourmet donuts, craft beer and/or single-malt Scotch.
More posts by Mike Mackrory.
No credit card required. Up and running in minutes.
More than 2,100 enterprises around the world rely on Sumo Logic to build, run, and secure their modern applications and cloud infrastructures.
