Continuous integration needs to mature, there is no doubt. But that does not mean you need to dump one CI server for another. Companies often come to us looking for a continuous integration process designed for the enterprise. They ask ‘what should we use to replace Jenkins for enterprise CI?’ My first question is “what does that enterprise CI mean to you?”
The majority of organizations use Jenkins as their primary Continuous Integration process. It has won the adoption race. This means that overtime, a substantial amount of investment has been made in Jenkins. There was never a proof of concept or budget defined for implementing Jenkins CI, it just grew organically out of open source over the last several years. Now what companies are facing is a way to mature CI into full continuous delivery with role based security, approval gates and more advanced workflows to support the full lifecycle ‘pipeline.’
Maturing your continuous integration to continuous delivery requires a full analysis of what each team requires. We all know the features offered by Jenkins serve the development teams very well. Now, how can Jenkins offer the maturity required to serve the testing and production teams?
It is important to remember that your Jenkins CI process itself performs no particular task, it simply orchestrates a set of task in an ‘if this, then that’ drumbeat. So in essence, you need to identify which steps in the Jenkins developer workflow that must be repeated in a test or production workflow in order to achieve mature continuous delivery. By identifying and improving these steps, you build on top of the investment you have already made in Jenkins.
Common Ground
So the next question is what workflow steps are common across all teams and should be repeatable from development through production. If you can establish what is common, you are in essence defining the processes that need to be matured. From a high level perspective most companies will discover all states of the pipeline need a deployment process followed by a testing process. Yes, even production deployments often incorporate some level of smoke test – load the application and process a single test transaction.
By looking at these two common steps in the CI process, you will be able to see where the ‘enterprise maturity’ is lacking. For the most part, developers create their CI process with tools that are easily available to them. They write version control check-out scripts, build scripts, deploy scripts and test scripts. In some cases they may use an open source solution for some level of automation, but this automation is limited.
The next question to ask is ‘can we mature our Jenkins continuous integration into continuous delivery by improving the common steps?’ For most companies the answer is a resounding ‘yes.’ Take a close look at how these common steps are executed by Jenkins. What you will find is that Jenkins is executing scripts that cannot mature across the pipeline. Jenkins is bound by the intelligence of the scripts it executes. And the common steps executed across the pipeline simply require more features and functions then the scripts can provide. A developer test script may not be robust enough for what testing needs to do. A developer’s deployment script is no doubt not robust enough to adapt across the pipeline pushing code updates to test and production across hundreds of endpoints. And most organizations don’t want a test or deployment process that cannot be audited, built on one-off scripts and requires a Jenkins agent to execute.
Building More Automation Into Your Jenkins Workflows
Jenkins is very good at executing external DevOps tools. In fact, most DevOps tools already have robust plug-ins for Jenkins. So the process of maturing your Jenkins CI into mature continuous delivery is as simple as selecting the appropriate DevOps tools to get the job done replacing the one-off scripts preventing Jenkins from being more than a CI server for developers. And you may be thinking ‘what about role based access and workflows that are private across teams?’ Again, the question is what steps in the Jenkins workflows need to be secured. Most likely the DevOps tools that you use to enhance your Jenkins process will already offer security. For example, replacing deployment scripts with a robust application release automation tool will provide you the security needed for deploying to different environments. The testing or production Jenkins workflow can execute a call to the deployment tool, and the deployment tool handles the environment security. This is similar to more robust testing tools.
In other words, there is no reason to think that your Jenkins workflow needs security built around it if you are replacing one-off scripts with more intelligence for the common processes that must be repeated across the pipeline.
Watch Out for Waterfall Habits
I know most of us think that defining a continuous delivery process with gated approvals between the workflows is core to an enterprise process. However, if you think about agile practices you will quickly see how gated approvals can be a throwback to the waterfall approach. Your best option is to allow workflows across the pipeline to execute in a rhythm that meets your agile cadence. If a release candidate comes across the pipeline, let the more robust deployment and testing tools block the updates and report back to Jenkins why a release did not occur. In most cases, these tools are going to be setup with this level of security built-in – there is no reason to set these types of road blocks in too many places. Yes, if you are doing everything based on one-off scripts, then the workflows must be blocked with gated approvals. However you will eventually learn that the one-off scripts are the road block to a more mature process. The sooner you move away from one-off scripts for executing common processes that must repeat across the pipeline, the sooner you will achieve a mature continuous delivery process suitable for the largest enterprise.
