GitLab CI/CD is a powerful continuous integration and deployment tool built directly into GitLab. This helps organizations automate our development process by building, testing, and deploying code automatically after a push and commit action. GitLab Runner is an application that works with CI/CD to run jobs in pipelines.

There are a variety of benefits that are available for users once they apply GitLab CI/CD to their OpenShift instances. 

• Speed: Users that employ AWS code pipelines can still suffer high processing times. CI/CD can reduce down these times significantly and reduce overall load to the services. 
• Standardization: Having multiple environments for deployment can mean that your technology can fit all use cases (and those yet to come!). Using CI/CD also allows for consolidation of multiple toolsets into a singular option for developers. This cuts down on the time needed to get developers up to speed on new building and deployment tools. 
• GitOps process: GitLab CI/CD has multiple triggers and variables within the tool UI for ease of use. This can reduce any conflicts in deployment or requests made, as they can be called using the same options across the board.

In a given environment like the example above, the GitLab runner could live on a ROSA cluster (or any OpenShift instance) in order to facilitate pipelines to multiple applications. The runner also pulls from an external GitLab instance and cluster via a single registration token. 

Multiple runners can be associated with each namespace as well. This can come in handy if your configuration uses tags to specify which runner per environment/cluster you wish to reference for specific actions. 

GitLab runners are highly customizable as they can be assigned to separate projects or shared across multiple.
 

When configuring your repository, be sure that you include a GitLab YAML file, where specific metadata will be stored about your pipelines. This includes tags, workflow rules, stages and other necessary data for the processes to run after merge or commit requests are received.

• Workflow: Defines when pipelines should specifically enact these jobs. In the example above, the GitLab runner is enacting the job whenever a merge or commit request is submitted. 
• Tags: Applies when there are multiple pipelines available. Tags can tell which pipeline to run and when. 
• Stages: Further defines when a pipeline should be run according to which stage a job is at. 
• Variables: Applies when multiple namespaces/applications are nested within the cluster or environment. 

Additional rules can be defined in the code for each stage of the job. These settings can be changed as your work processes grow or scale down, providing greater flexibility. 

To view a demo of how GitLab Runners can be applied to a given job for faster performance, watch our live demo here. Note: you will need a Red Hat account to view the video. 

Watch the demo