Continuous Integration with Jenkins

Jenkins is a self-contained, open source automation server that can be used to automate all sorts of tasks related to building, testing, and delivering or deploying software. It is a perfect tool for helping manage continuous integration tasks for a wide range of software components.

Jenkins Pipeline (or simply “Pipeline”) is a suite of plugins that supports implementing and integrating continuous delivery pipelines into Jenkins.

A continuous delivery pipeline is an automated expression of your process for getting software from version control right through to your users and customers.

Jenkins Pipeline provides an extensible set of tools for modeling simple-to-complex delivery pipelines “as code.” The definition of a Jenkins Pipeline is typically written into a text file (called a Jenkinsfile) that in turn is checked into a project’s source control repository.

Pipelines offer a set of stages or steps that can be chained together to allow a level of software automation. This automation can be tailored to the specific project requirements.

You can read more information about Jenkins Pipelines here

Pipelines are defined in a Jenkinsfile that sits in the root of your application code. It defines a number of stages. Each of the Starter Kits includes a Jenkinsfile that offers a number of stages. The stages have been configured to complete the build, test, package, and deploy of the application code. Each stage can use the defined defined secrets and config maps that were previously configured during the installation of Development cluster setup.

To enable application compatibility between Kubernetes and OpenShift, the Jenkinsfile is consistent between pipeline registration with both platforms. Also, the Docker images are built from UBI images so that their containers can run on both platforms.

These are the stages in the pipeline and a description of what each stage does. The bold stage names indicate the stages that are required; the italics stage names indicate optional stages that can be deleted or will be ignored if the tool supporting the stage is not installed. These stages represent a typical production pipeline flow for a cloud-native application.

The Starter Kits are a good place to start to see how Jenkinsfile and Dockerfile should be configured for use in a Jenkins CI pipeline. To register your git repo, use the IGC CLI. This command automates a number of manual steps you would have to do with Jenkins, including: managing secrets, webhooks, and pipeline registration in the Jenkins tools.

By default, the pipeline will register into the dev namespace and will copy all the configMaps and secrets from the tools namespace to the dev namespace. This means the pipeline can execute, knowing it has access to the key information that enables it to integrate with both the cloud platform and the various development tools. See Cluster Configuration for more detailed information.

You can use any namespace you want to register a pipeline. If you add -n or namespace to your igc pipeline command, it will create a new namespace if it doesn’t already exist. It will copy the necessary secrets and configMaps into that namespace and configure the build agents pods to run in that namespace.

This is good if you have various squads, teams, pairs or students working in the same Development Tools environment.

In addition to continuous integration, the environment also supports continuous delivery using Artifactory and ArgoCD: