Summary: Jenkins is a very popular solution for managing Continuous Integration and Deployment (CD/CD) pipelines. By using Ravello for the integration and system tests phases, users can improve the fidelity of already existing on-premise VMware based pipelines leveraging the unlimited capacity of the AWS cloud.
In my previous post I talked about the importance of automation in software development and I gave an overview of a typical CI/CD pipeline. One of the things discussed there is the importance of running tests in environments that are clean and that, especially in the case of integration and system tests, closely resemble your production environment.
In this post I will show you how you can integrate Ravello based test environment into a CI/CD pipeline managed by Jenkins.
About Jenkins
Jenkins describes itself as an “extensible, open source continuous integration server”. I think this description is actually a bit too narrow. In addition to continuous integration Jenkins can manage all parts of a CI/CD pipeline, and some people even use it as a generic automation/workflow engine.
Jenkins started in 2004 inside Sun under the Hudson name and was first released in 2005. After a dispute with Oracle which owns a trademark on the Hudson name, it was renamed to Jenkins in 2011.
Today, Jenkins is a well established open source project with a lot of users. The main strength of the project is probably its very extensive ecosystem of plugins, providing many different types of add-on functionality. The breadth of this ecosystem has no doubt contributed to Jenkin's success.
Automating a CI/CD pipeline with Jenkins
There are many different ways in which Jenkins can be set up to drive a CI/CD pipeline. In this blog I'm going to describe a simple yet powerful configuration:
- The pipeline consists of 4 steps: "Build", "Unit", "Integration" and "System". I am leaving out "Deploy" here but that step can be easily added.
- Each step is implemented as a Jenkins job of type "free-style software project".
- Each step runs on its own set of slaves. This allows full control of where jobs are run. For example, you might have a source code repository that is accessible only to your office network. In that case, the “Build” phase can run on a local slave while “Integration” and “System” can run in Ravello.
- Targeting of jobs to slaves is done via labels. For example the Build slave has a label "build", and the build job has a setting "Run only on: build".
- The first step ("Build") is connected to a version control system. This step can either poll the repository, get notified via a webhook, or run on a schedule or on demand. Subsequent steps have a build trigger that starts the job when the previous step finished.
- Artifacts are copied between the different jobs via the "Copy Artifact" plugin. This requires the "Archive Artifacts" setting to be enabled.
Adding Ravello to the Pipeline
In the pipeline setup described above it is easy to integrate Ravello environments. For each environment that you want to host in Ravello, you create one (or more) Ravello applications. A Ravello application is a set of virtual machines, networks and storage that together encapsulates an entire service. Applications are Ravello’s unit of management and can be snapshotted in blueprints and spun up as many times are desired. In our setup, each application will have a Jenkins slave as part of the application. This means that build steps that run as part of the job will have access to the environment provided by the application. For example, if an application defines a database server "db.example.com" with a fixed IP of 10.0.0.10 then this server be available to the job. There is no concern for security because applications run in private software-defined network with no inbound connectivity unless specifically configured.
The picture below described a CI/CD pipeline where the “Build” and “Unit” steps run on premise, while the “Integration” and “System” steps run in Ravello.
On the Jenkins console the pipeline looks like this:
Every step in the pipeline is connected to its previous step, and the first step is connected to the source control. This means that whenever a change is added to the source control repository, all steps will run until either the end of the pipeline is reached, or until a step fails.
Summary
In this post I described a simple yet effective CI/CD pipeline managed by Jenkins that uses Ravello for integration and system tests. To try out this functionality yourself, please see our 14-day free trial.
The post Continuous Integration and Deployment using Jenkins in a hybrid VMware ESXi and AWS EC2 Environment appeared first on The Ravello Blog.