AWS Open Source Blog

Why Jenkins still continuously serves developers

Jenkins stickers - variousFor an estimated 15 million developers, Jenkins is synonymous with countless iterations of collectible stickers of the iconic, non-assuming butler that have adorned their laptops all over the world. The butler is representative of the ubiquitous open source continuous integration (CI) technology that has quietly automated an endless set of development tasks for well over a decade.

Jenkins origins trace back to late 2004 at Sun Microsystems where it started life as Hudson. Its creator Kohsuke Kawaguchi is a coder who simply wanted to give his developer teammates some idle time back to write good software. In 2011, the project was emancipated from Oracle after the Sun acquisition and took the name Jenkins. Maintained by a large open source community, Jenkins has thrived as a versatile automation engine for mundane, repetitive software development jobs. Continuous integration is the term adopted for the infinite set of time-and-resource-intensive testing and integration processing that Jenkins performs to free up software delivery teams to continuously build and deliver more rapidly.

The extensibility built into this engine still fuels its current popularity. Designed with a plugin architecture, it allows software developers to quickly write their own plugin or choose among the thousands contributed by the Jenkins community. This model allows teams to build a custom continuous delivery (CD) pipeline that connects to any code repository and triggers automation jobs using their preferred tools to build, test, store, version, deploy, and monitor their software projects.

40 million—and growing— Jenkins jobs automated

Since April 2007, the Jenkins project has been collecting baseline, anonymized statistics on Jenkins usage. These statistics only represent projects that have not opted out of data collection. The total numbers are much bigger, since a large percentage of software is built in organizations that close their firewalls to such reporting. But even at that, the numbers are significant.

Jenkins growth over the past 5 years: 2015-2020

Jenkins growth 2015-2020

  • 145% Server growth of installed servers represents sustained adoption by new teams.
  • 535% Jobs growth represents unique tasks “jobs” automated with Jenkins.
  • 583% Plugin growth represents plugins created to automate a myriad of specific use-cases.
AWS Jenkins plugins

Popular AWS-specific Jenkins plugins

Built for increasingly faster software delivery

Most of today’s developers run all or part of their delivery pipelines on cloud platforms, creating services and applications that run in the cloud. There are more than 37 AWS-specific Jenkins plugins that help developers automate everything from passing AWS credentials across their delivery pipeline to executing builds with the AWS-supported CodeBuild plugin.

Well-architected Jenkins using ECS and Fargate

Jenkins is a server<>worker architecture, and, with so many plugins, it can be susceptible to versioning and configuration challenges. The AWS team recently created a new Jenkins-on-AWS project that can build and deploy an immutable, fault tolerant, and cost-effective Jenkins environment in AWS using Amazon Elastic Container Service (Amazon ECS), managed by AWS Fargate.

Deploying Lambda with Jenkins

Serverless deployment presents a new way to deliver applications with less concern and dependencies on underlying infrastructure. As teams adopt these new practices, Jenkins can be called upon to help out. A Cloud Guru is an AWS partner and has shared a post on how to deploy Lambda functions using AWS with the help of Amazon Simple Storage Service (Amazon S3), Amazon CloudWatch, and Jenkins.

Jenkins deploying Lambda

Into the future

All of this points to many more productive and useful years as an open source favorite. And to take the helm (pun intended) for the next generation of Kubernetes development, a new project, Jenkins X, arrived in 2019.

GitOps and containerized app delivery using EKS

Where Jenkins is highly extensible and reliant on plugins for its wide versatility, Jenkins X is designed specifically for Kubernetes-native development. Jenkins X detects projects; anticipates the use of dev, staging, and production environments; and creates pipelines for you. Where Jenkins focuses on being something of a Swiss Army knife, Jenkins X attempts to be a specialty tool for complete Kubernetes CI/CD.

Jenkins X is designed to make it simple for developers to adopt DevOps principles and best practices. At the heart of the system is Kubernetes, which has become a popular virtual infrastructure platform for DevOps. Jenkins X also caters to the practice of GitOps, the Git-repository-centric approach for managing and deploying containerized and serverless applications.

For ambitious teams who love all things new, the blog post “Serverless all the things — GitOps using Jenkins X on AWS EKS” will provide ample insight to get you shoulder deep in all the latest CI/CD innovations for containerized, serverless app delivery.

The Jenkins project now runs on AWS

AWS is committed to working with, supporting, and contributing to new and existing open source projects. Jenkins has been part of the software development landscape throughout the rise of cloud computing and all of the rapidly changing approaches from microservices, containers, orchestration, and serverless computing. To assure the project continues, for 2020, AWS has sponsored the infrastructure that supports the Jenkins project. With our support of the Jenkins projects in this way for the Continuous Delivery Foundation (CDF), we look forward to many more years of the unassuming butler to serve the next generation of cloud-native software development teams.

Get involved

TAGS: , ,
Brad Johnson

Brad Johnson

Brad Johnson currently curates the selection of leading DevOps tools for customers of AWS Marketplace. A pioneer of cloud-based testing, CI/CD champion, and Chaos Engineering breaker-of-things, he’s worked with, written and spoken about innovative tools and practices that have disrupted software delivery for the past 20 years. As a contributing author, he can claim to have written (part of) the book on “Continuous Testing for DevOps Professionals”. Follow him on Twitter @bjohnsonsv.