Many organizations struggle with releasing their applications and this struggle has birthed an industry of tools designed to simplify the process. Release management tools allow a release process to be defined as stages in a pipeline, and stages themselves contain sequential steps to be performed before the next begins. Stages are segmented using approval gates to ensure that QA and release managers get the final say on whether an artifact is ready for the next stage in the release pipeline, and the entire process is tracked for reporting purposes.
The goal of such processes is to ensure that only high quality releases are deployed into production and are released on time, and the release manager is responsible for it all.
An obstacle to a smooth release is the structural challenge of maintaining identical testing and production environments. When these environments differ, it allows an opportunity for unexpected regressions to slip through testing and botch a release. Ideally, all environments will be identical and contain the same dependent libraries and tooling for the application, as well as the same network configurations.
What is Docker?
Docker is an open-source project that provides a platform for building and shipping applications using containers. This platform enables developers to easily create standardized environments that ensure that a testing environment is the same as the production environment, as well as providing a lightweight solution for virtualizing applications.
Docker containers are lightweight runtime environments that consist of an application and its dependencies. These containers run “on the metal” of a machine, allowing them to avoid the 1-5% of CPU overhead and 5-10% of memory overhead associated with traditional virtualization technologies. They can also be created from a read-only template called a Docker image.
Docker images can be created from an environment definition called a Dockerfile or from a running Docker container which has been committed as an image. Once a Docker image exists, it can be pushed to a registry like Docker Hub and a container can be created from that image, creating a runtime environment with a guaranteed set of tools and applications installed to it. Similarly, containers can be committed to images which are then committed to Docker Hub.
Cookie-cutter environments and application packaging The versatility and usability of Docker has made it a popular choice among DevOps-driven organizations. It has also made Docker an ideal choice for creating the standardized and repeatable environments that an organization needs for both creating identical testing and production environments as well as for packaging portable applications.
If an application is packaged in a Docker image, testing and deploying is a matter of creating a container from that image and running tests against the application inside. If the application passes the tests, then they should be stored in a registry and eventually deployed to production.
Automating the release According to Forrester Research, the top pain of release management is a lack of visibility into the release management process and their process’ lack of automation.
However, the testing, deploying, and releasing stages of these pipelines can be orchestrated by Jenkins using the CloudBees Docker Build and Publish plugin . This plugin creates a new build step for building and packaging applications into Docker containers, as well as publishing them a images to both private and public Docker registries like Docker Hub.
Testing and QA Applications packaged in Docker images can be tested by running them as a container. Docker allows containers to be linked, granting the linked container shell access and allowing it to run scripts against the application’s container. This link can also be made between the Docker application container and another container which is packaging a service the application needs to run against for a true integration test, such as a test database.
Promotion and Release Jenkins supports the concept of promotion, where tested and approved artifacts are promoted to the next stage in a pipeline. Promotion is compatible with both traditional Jenkins jobs and the new Jenkins Workflow , and promotions can be set to only trigger if manually approved by particular users or team members.
In this case, the artifact is a Docker image containing our application, and once it is promoted it can be manually or automatically moved to the next stage of its pipeline. The next stage can range from a pre-production staging area to a registry like Docker Hub, where the promoted image is known as a “Gold” image ready for deployment.
The promotion can also trigger any other number of pre-release actions, such as notifications and sending data about the artifact to a company dashboard.
Where do I start?
- The CloudBees Docker Build and Publish plugin is an open-source plugin, so it is available for download from the open-source update center or packaged as part of the CloudBees Jenkins Platform.
- More information can be found in the newly released Jenkins Cookbook
- Other plugins complement and enhance the ways Docker can be used with Jenkins. Read more about their uses cases in these blogs:
- Docker Slaves with the CloudBees Jenkins Platform
- Jenkins Docker Workflow DSL
- Docker Traceability
- Docker Hub Trigger Plugin
- Docker Custom Build Environment plugin
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}