One of the core components of this demonstration is to utilize the principles and tools emphasized by continuous integration and continuous delivery. This document explains how these tools and concepts are achieved.
The Jenkins Continuous Integration Server is being used to orchestrate the building, deploying and promoting of applications to OpenShift. It builds upon the official [Jenkins xPaaS image] (https://docs.openshift.com/enterprise/latest/using_images/other_images/jenkins.html) by adding essential plugins and configurations to enable continuous integration and delivery functionality and behavior driven development.
To offload the responsibility of executing build on the masters, Jenkins agents are used to provide distributed build functionality. Agents are dynamically created and managed by the Jenkins master through the Kubernetes Plugin. When new builds are started, the Jenkins master communicates with the OpenShift API to use or instantiate new pods. When the build completes, the pods are destroyed. Communication to the OpenShift API is made possible by utilizing service account tokens that are automatically injected into the running pods.
Jenkins pipelines as code is a concept where the steps an application will take from build to deployment is packaged alongside the application code in a descriptive format. A new pipeline build type makes use of this domain specific language (DSL), typically stored in a file called Jenkinsfile, to illustrate these steps. Each of the projects contains one of these files to illustrate the processes that will occur during the job execution.
The Jenkins jobs for executing the pipeline are stored in code using the Jenkins Job DSL plugin. This allows the job configuration to be managed and versioned as well as avoiding configuration drift that typically occurs in a Jenkins server. The DSL is located in the ci folder within this repository and initiated by a job built into the Jenkins image. This job is automatically run at the conclusion of the init.sh script.
Nexus is an artifact repository. It is being used to act as a Maven and NPM proxy in the environment to accelerate build time and to store artifacts produced by Jenkins build processes. This server is preconfigured with the necessary repositories to build Red Hat middleware solutions
Gogs is a self contained git server used to provide distributed source code management for the environment. Three repositories are created based on the projects located in the projects folder a
Git hooks play an integral component integrating several of the solutions to achieve true continuous delivery