Source: SD Times (sdtimes.com), original reporting circa early 2017.
Jenkins Usage Grew Significantly in 2016
The Jenkins project’s 2016 Community Survey revealed strong momentum for the open-source automation server across three dimensions: deeper adoption within organizations already using Jenkins, net-new adoptions, and growth driven specifically by Continuous Delivery (CD) initiatives.
Key figures from the survey:
- 85% of respondents said their organization’s use of Jenkins had increased over the prior year.
- 54% of practitioners implementing Continuous Delivery were using Jenkins as their primary automation engine.
- 90% considered Jenkins mission-critical to their business.
- 96% used Jenkins for build tasks.
- 62% used Jenkins for deployment activities.
- 36% used Jenkins for operations tasks.
Sacha Labourey, CEO and co-founder of CloudBees, attributed the growth to the broader DevOps movement: “As an ever-increasing number of teams implement DevOps, we are seeing them naturally turn to Jenkins as the de facto business-critical solution for Continuous Integration and Continuous Delivery. The survey and increasing usage statistics reflect how adoption continues to grow despite an already massive installed base, all while the community’s involvement keeps increasing.”
Jenkins 2 and Pipeline Support: The Catalyst for Growth
Jenkins creator and CloudBees CTO Kohsuke Kawaguchi pointed to the Jenkins 2 release—launched in early 2016—as a turning point. Jenkins 2 introduced native Pipeline support, giving teams a powerful, scriptable way to define and manage their entire CD workflow as code.
“Early in 2016, the community invested in Jenkins 2, adding Jenkins Pipeline support to enable the leading automation engine with the power and ease of use to support organizations implementing Continuous Delivery and DevOps,” Kawaguchi said. “The 2016 Jenkins Community Survey results indicate the investments are showing a return for both existing and new users through the expanded use of Jenkins within organizations.”
New Pipeline Features: Declarative Syntax, Graphical Editor, and Shared Libraries
Alongside the survey results, the Jenkins project announced a significant update to Jenkins Pipeline aimed at lowering the barrier to entry for Continuous Delivery. The release introduced three major capabilities:
1. Declarative Pipeline Syntax
The new declarative syntax offers a structured, opinionated way to write Jenkinsfiles. Unlike the fully Groovy-based scripted pipeline, the declarative format uses a predefined, human-readable structure that makes pipelines easier to write, read, and validate—especially for teams less familiar with Groovy scripting.
A minimal declarative pipeline looks like this:
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'make build'
}
}
stage('Test') {
steps {
sh 'make test'
}
}
stage('Deploy') {
steps {
sh 'make deploy'
}
}
}
}Code language: JavaScript (javascript)2. Graphical Pipeline Editor (Blue Ocean)
The release included an initial version of a graphical editor, part of the Blue Ocean project—a redesigned user experience for Jenkins. The editor allows teams to define and visualize CD pipelines without writing code directly, making pipeline authorship accessible to a wider range of practitioners, including those without strong scripting backgrounds.
Kawaguchi described the goal: “Declarative Pipeline combines the power and flexibility of Jenkins Pipeline with the simplicity of Blue Ocean. Defining and evolving Continuous Delivery pipelines is made not only easier but also pleasant, which is an important milestone for making Continuous Delivery accessible for everyone.”
3. Shared Pipeline Libraries
Shared pipeline libraries allow teams to extract common pipeline logic into reusable code that can be referenced across multiple Jenkinsfiles. This promotes consistency and reduces duplication in organizations running many pipelines—particularly valuable in large enterprises with dozens or hundreds of projects following similar build and deploy patterns.
Why This Mattered for DevOps Teams
The combination of survey results and feature announcements painted a clear picture of Jenkins’ strategic direction at the start of 2017: move from a plugin-heavy, UI-driven CI server to a programmable, pipeline-first automation platform. The declarative syntax and graphical editor addressed two distinct user segments—experienced engineers who want code-defined pipelines and less experienced users who need a visual interface—while shared libraries served platform engineering teams managing CD at scale.
For DevOps practitioners evaluating or already running Jenkins, these changes signaled that pipeline-as-code was becoming the primary supported workflow, not an add-on. Teams still relying on freestyle jobs and manually configured build steps had a clear migration path toward reproducible, version-controlled pipelines.
Further Reading
If you are new to Jenkins Pipeline or looking to deepen your knowledge, the official Jenkins Pipeline documentation is the most reliable starting point. The Blue Ocean documentation covers the graphical editor in detail.