Jenkins Best Practices: How to Automate Deployments with Jenkins
by Scott Reece, on Jul 24, 2019 11:00:00 AM
Jenkins automated deployments are one of the most popular software development techniques in use today. Any organization with a need to deploy applications quickly and efficiently can benefit from its core functionality.
But with 1K+ plug-ins and counting available (including GitHub), there is a lot it can do. Building complex, automated development pipelines quickly, requires knowledge of automation principles and the best practices for applying them to Jenkins use.
What is Continuous Deployment?
First, let’s start with a common source of confusion — what does “Continuous Deployment” mean? This question is often asked because the “CD” moniker is used refer to either Continuous Deployment or Continuous Delivery. And while the two are related, there is a key difference.
- Continuous Delivery is the practice of automatically sending every code change to a production-faithful environment to be automatically tested.
- Continuous Deployment is the practice of automating the release of the changes integrated and tested during continuous delivery.
In theory, each could be done without the other. Organizations can choose to integrate and test code changes automatically, while retaining a manual process to deploy (“send them live”). They could also manually test and then when the build is ready, release it to production.
However in practice, the most common scenario is to implement both.
Why do Continuous Deployment?
Continuous deployment offers benefits to both development and business stakeholders. The specific value is different between the two. However, there are a few guiding principles:
- Faster Development: For starters, automation increases the rate changes get implemented. In addition, the scope of each change is much smaller than when there is a long delay between releases. That minimizes the risk of mistakes.
- Software Quality Increases: By increasing the iteration of small changes to the codebase, problems get fixed faster. In addition, mistakes in development are smaller in scope, so they can be reverted or fixed faster.
- Easier on Users: With small frequent changes to an application, the UI remains as consistent as possible. Incremental improvement means the application’s functionality appears to remain, even as it is continually revamped over the long-term.
Benefits of Continuous Deployment (Developer)
Beyond the items listed above Continuous Deployment offers advantages that Continuous Delivery does not.
- Even Faster Development: With less overhead, and no manual interventions, features are out being used as soon as they are ready. With small incremental changes testing can be hyper-focused and performed very rapidly. Time that used to be spent executing the process can be used on development instead.
- Quality Continues to Rise: Bugs are identified faster, and the reduced volume of change means they are often easier to remediate or roll-back.
Benefits of Continuous Deployment (Business)
The benefits to the development team are enough to consider moving to Continuous Deployment, but there are also significant Business reasons to consider it.
- Flexibility: Developers making small incremental changes make it easier for an organization to change direction quickly without leaving lots of half-finished work. The organization also still derives benefit from the past activity after changing direction because it was released quickly and not delayed.
- Experimentation: Small changes to the codebase can rapidly be A/B tested by users without a delay in data gathering to see what users prefer.
- UI/UX: Small rapid changes are often invisible to users, the product they are using gradually gets better and better without a user needing to dedicate time to learn new features, creating a better user experience.
- Innovation: With Experimentation the business may be surprised by user validated results which may lead to further changes or new opportunities in the market. Seeing what users actually do in an application can generate new ideas for further Experimentation.
Stages of Continuous Deployment
Continuous Deployment is a process. While there may be many stages and environments depending on an organization's needs, 4 basic stages are required:
- Commit Changes: Saving your changes to the Source Control Repository after you’ve finished working on them.
- Build: Source Code files are converted into a stand-along form that can function (on a local machine, test server, cloud, etc)
- Test: This is the process to check whether actual results match expected results to ensure that software is performing as expected or desired
- Deploy: The final step, includes all activities to make the software / product / update/ system available to be used.
Continuous Deployment using Jenkins
This will assume that you’re currently using a manual, or mostly manual process to build, test, and deploy your software. If you already have some tools and automations in place some of the following steps won’t apply to your organization.
Begin after there is a successful Build
Once you have code that you want to deploy, you need to check-in the code to your Version Control System so that it becomes part of the codebase and the entire application can be built and tested. There are numerous options for version control, and most will work with Jenkins. Some examples that you may already be using are:
Do a Manual build/test/deploy process
Run your current process first. No matter how you’re currently deploying software you should run through the entire process through completion as a first step. The goal of this is to document everything about your process, so that when it’s time to automate the deployments in Jenkins you have the information you’ll need. Without this run you’ll be guessing at information, or may have to call in many different people to get the information you need.
How to setup Jenkins
- Install Jenkins on a machine so that you and your team can use it first.
- Install Plugins. Jenkins has more than 1000 plugins created by the Jenkins community so that you can customize Jenkins to do exactly what you need. The specific Plugins that you’ll need to use will depend on your process. Some of the most popular ones are
- Secure Jenkins and invite other team members. Making sure that other team members are involved in creating your Continuous Deployment in Jenkins is a necessity to ensure no important process are missed, as well as to give others visibility into the process.
How to create a JenkinsFile (Pipeline)
Once a Build happens in Jenkins that build artifact will move through a Pipeline that will result in the deployment of the application, assuming the artifacts passes automated tests. These Pipelines are created using JenkinsFiles.
It’s a best practice to use a JenkinsFile to create your Pipelines so that these files can be stored as code in Source Control.
- JenkinsFiles are broken into Stages (Build, Test, Staging, etc) the specific stages you create will be based on the manual process that you documented.
- Each Stage in your JenkinsFile will create environments to allocate resources to use during that stage’s operations
- Secrets and credentials (user names / passwords) can be used in a JenkinsFile in a stage or environment if used these secrets would be shown as **** in the created Pipeline
- Multiple agents can be used within a stage and environment to allow access across multiple platforms
- Each Stage will end with a true / false check to ensure that the stage was run and returned the expected results. If the value is returned false at any stage the deployment will automatically fail.
- Parallel executions can be created in a JenkinsFile at a stage or environment so that multiple testing setups can be run at the same time and reduce testing time needed. A fail at any of the parallel executions would fail the entire stage and deployment
Connecting Jenkins to your Version Control System
To create a build in Jenkins you need to hook it up to your Version Controls system. Once Jenkins has access to your Version Control it can then use that access to create builds, either on a regular basis or when triggered by a code check-in. All major Version Control Systems have Jenkins Plug-ins.
- Git’s Jenkins Plugin allows you to connect Jenkins to your Git Source. It is extremely popular and has a very active user-base and support.
- GitHub’s Jenkin’s Plugin: this is a very popular Source Control for people using Jenkins and it often gets more than 100,000 installations each month and allows you to create hyperlinks between Jenkins and GitHub
- Mercurial’s Jenkins Plugin: allows you to check repositories for changes and use that as a trigger to start a build.
- BitBucket’s Jenkins Plugin allows you to push to Jenkins to start compatible jobs based on changed repositories or branches.
- Perforce’s Jenkins Plugin allows you to synchronize your code and trigger builds on changes.
Every organization’s Jenkins set-up will be different because of its unique needs, getting started with Automation and Continuous Deployment using Jenkins doesn’t need to be overwhelming.
Inedo’s DevOps tools, like BuildMaster, integrate with Jenkins to help maximize developer time, minimize release risk, and empower stakeholders to bring their vision to life faster. All with the people and technology you have right now. To get help streamlining your CI/CD processes, contact us at email@example.com.