Technology / DevOps

DevOps Fundamentals: How to Create a CI/CD Pipeline

How to Create a CI/CD Pipeline
Follow us
Published on December 5, 2022

One way to think of  DevOps is as a method to release applications and services at a high velocity. This is done by merging the software developers with the release engineers into a single unit. These mergers facilitate quick software release cadences.

However, to reach an acceptable release cadence, there must be a consistent process established for releasing code into a production environment. This process is a branch of DevOps called Continuous Integration/Continuous Delivery (CI/CD).

In this article, we will discuss what CI/CD is, how Jenkins fits into the picture, and finally how to write a script using Groovy to automate your build pipeline. 

Need DevOps Training?

To be a successful DevOps pro, you need a diverse skill set that includes a little bit of everything. You’ll need a strong networking foundation, cloud skills, and a strong grasp of automation. 

You can find the training you need for all those DevOps-related skills and more at CBT Nuggets. Browse our DevOps training today.

How is CI/CD Different From What We Did Before?

Traditionally, organizations would use a software development cycle called Waterfall. In a nutshell, Waterfall methodology divided software implementation into five parts: Requirements, Design, Implementation, Verification, and Deployment. Notice how the code is deployed at the very end. That’s not agile.

Instead, we want to deliver our code throughout the lifecycle of the project. By continuously integrating our code into the existing application, stakeholders are able to give immediate feedback on what works, and what doesn’t.

To ensure high-quality code is released consistently, a CI/CD pipeline is created. The pipeline builds a docker image, then runs regression tests to ensure nothing has changed. This is usually accomplished with Jenkins. Let’s discuss how Jenkins is used to continuously release an application.

What is Jenkins?

Jenkins is the most common Continuous Integration tool with a whopping 71% of the market share. Jenkins is a free, open-source integration tool with a robust community. Installing Jenkins is a fairly complex and time-consuming process. However, it is most often downloaded and runs on a docker container. Once it’s installed, you will be able to access a Jenkins Dashboard on the server it was installed on.

Jenkins provides the ability to upload Groovy scripts to perform various functions involved with continuous integration. Most commonly, the deployment involves these steps. In this example, I will assume the objective is to build a front-end application.

  1. Build the agent on which the Jenkins Pipeline will run on. For example, if you are running a front-end application, ensure the pipeline’s agent is capable of executing node, npm, and karma tests. 

  2. Test the code. To test the code, make sure the docker image has end-to-end automation tools installed like Cypress, and unit test coverage such as Karma.

  3. Archive the Build. Once the tests have all passed either create an image of the file or push it to a git repository monitored by a helm chart. 

  4. Push to Registry Lastly, the image can be uploaded to a registry. Then, it’s deployed to a particular environment—whether that is QA, production, etc.

That is a 1,000-foot-level view of what exactly is automated in a Jenkins pipeline. However, there is a caveat: Groovy scripts serve as glue, they do not (or at least, should not) perform business logic themselves. Groovy itself will handle flow control statements, but most of the logic will be done using different technologies such as shell and docker.

How to Write a Groovy script

In this Groovy Script, we will write a pipeline that takes a front-end application. Then builds it, tests it, and deploys it. It should be noted that this is a skeleton script — purely theoretical. The individual nuances of each organization must be taken into account when writing a Groovy Script. For example, often times firewall issues will necessitate a modification to a script. Before delving into the code, keep an eye out for the following core syntax:

  • Pipeline—All Jenkinsfiles start with declaring operations within a pipeline.

  • Agent—The machine or container which executes particular tasks.

  • Environment — Variable that will be used throughout the process. For example, the location of the Chromium Binary for headless testing.

  • Stages—A group of stages we wish the Jenkins script to perform.

  • Stage—The stages can be labeled as anything you like. Each stage represents a unit of work you would like the pipeline to execute.

  • Steps—Steps are individual actions within a stage. They represent the actual work being performed. These are generally docker or shell commands.

Now that the vernacular has been reviewed, let’s take a look at a sample Groovy script. pipeline{

    agent any

    environment {

        AppName = 'example-application'

        CHROME_BIN = 'path/to/chromium-browser'

        DockerHubCredential = "my_credentials"

    }

    stages {

        stage('Create Docker Image for Agent') {

                agent {

                    docker {

                            image "node:16.13.1-alpine"

                        }

                    }

                    steps {

                        sh 'node --version'

                        sh 'npm ci'

                        sh 'ng build'

                    }

                }

        stage('Test the Code') {

                agent {

                    docker {

                        image "node:16.13.1-alpine" //For Example purposes only, this image may not           have Karma installed.

                    }

                }

                steps {

                    sh 'npm ci'

                    sh 'CHROME_BIN npm run test -- --browsers=ChromeHeadless'

                }

        }

        stage ('Archive the Application') {

            steps {

              sh "git tag -a -m \"tagging this build V1.0\"${AppName}"

              sh "git push origin ${AppName}-V1.0"

            }

           }

        stage ("Push to the registry")

            def dockerImage = docker.build("path/to/the/registry/${env.AppName}:1.0")

            dockerImage.push

        }

}

Final Thoughts

Don’t be surprised if this is confusing at first. Don’t lose sight of the overall goal: we want to consistently create production-ready applications that don’t have to be manually tested. That’s it. The Groovy script allows us to outline how exactly that will be done. Hopefully, you will have a better conceptual understanding of CI/CD after reviewing this article.


Download

By submitting this form you agree to receive marketing emails from CBT Nuggets and that you have read, understood and are able to consent to our privacy policy.


Don't miss out!Get great content
delivered to your inbox.

By submitting this form you agree to receive marketing emails from CBT Nuggets and that you have read, understood and are able to consent to our privacy policy.

Recommended Articles

Get CBT Nuggets IT training news and resources

I have read and understood the privacy policy and am able to consent to it.

© 2024 CBT Nuggets. All rights reserved.Terms | Privacy Policy | Accessibility | Sitemap | 2850 Crescent Avenue, Eugene, OR 97408 | 541-284-5522