AWS Open Source Blog
Why Jenkins still continuously serves developers
For 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
- 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.
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.
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.