Simply Explained: OpenShift and Jenkins Pipelines

A far too familiar story

You just finish responding to an email when you overhear something.

Developer 1 asks Developer 2, “Hey, after you’re done making changes to the BuildConfig, could you pull in my Jenkins code? The pipeline should kickstart new builds.”

Developer 2 jokes, “I don’t know. Did you figure out what’s wrong in the SonarQube stage, or is that still being reviewed?”

Developer 1 answers confidently, “Do you think this is my first rodeo or something? Yes, I fixed it.” Developer 1 turns to you, looking you square in the eyes, and utters what sounds like complete nonsense, “Now that we have a Jenkins implementation up and running, and a bare bones pipeline working, are we good to add in some more complex stages? I was thinking about some advanced health checks. Is that OK? The integration with OpenShift is remarkable.”

Wait. What? You, a non-technical team member, were lost the moment Developer 1 said BuildConfig, but now you have to make a decision. You’ve never even heard of a pipeline in the first place. You’re still hazy on OpenShift, too. Don’t worry. Take a second. Breathe, and read on!

Prerequisites for this lesson

1. Can read.

2. Has a willingness to learn :).

How do developers work?

Let’s build the understanding from the ground up. That starts with the developers and how they work together.

To simplify it all, developers write code to create and edit applications. (Applications can be websites, algorithms, apps, etc.) Developers share code with each other using tools like GitHub. Using a GitHub repository, developers can store and share the most up-to-date version of an application’s code. Typically, developers will work on their own version of the code (or feature branch) before merging it into the GitHub repository master branch.

At the end of the day, developers write code, and GitHub is a great place to securely store and share that code online.

What is OpenShift?

News flash: Code does not magically run by itself. That’s where OpenShift comes into play.

To simplify it all, OpenShift is a Cloud Native platform, which means, it’s a really great place for developers to deploy code from GitHub. OpenShift is what makes the application actually run. Obviously, developers have to do some configuration. They’ll need to connect a GitHub repository with an app in OpenShift. This work can be done through command line tools or OpenShift’s Web Console. There are many other great reasons to use OpenShift that you should read about once you feel comfortable with all of this. (Have you heard of containers?)

At the end of the day, OpenShift is a platform that can get your application up and running using the code from the GitHub repository. (Build configurations dictate how OpenShift will run your code from GitHub, but you don’t need to worry about that. Developers will handle it!)

What is Jenkins?

Jenkins is a tool that can automate developers' OpenShift tasks. It’s that simple. There are several ways to automate tasks (a pipeline being one of them!!). Just like before, developers will need to do some configuration to get Jenkins working with OpenShift. It’s not like they can magically talk to each other. They’ll have to exchange some credentials and permissions.

Regardless, once everything is set up, developers can automate the tasks they perform in OpenShift using Jenkins’ web interface.

What is a pipeline?

You’ve finally made it to the long awaited pipeline. All a pipeline does is automate a series of tasks in order. Pipelines are broken up into multiple stages. Each stage will run one or multiple tasks. Some stages may depend on the outcome of previous stages. Developers have to write code to define how the pipeline will operate. (They do this using a JenkinsFile. Developers might make different JenkinsFiles for different environments like production, testing, development, etc.) As you might have guessed, developers will store this code in a GitHub repository. Jenkins will access the latest code from the GitHub repository to run the pipeline.

OpenShift is great for running applications. Jenkins is great for running pipelines. In this case, you will use a Jenkins pipeline to automate some of the tasks you have to do in OpenShift to get the application up and running. A typical pipeline might include these six stages:

1. Preamble: Confirm all the right repositories and projects are in use.

2. Build: Access the application code to prepare the application. (Building varies from application to application. Is this a Python project? Java?)

3. Complexity: Using something like SonarQube to check code readability and formatting.

4. Unit Tests: Make sure existing unit tests are still successful as part of the new change.

5. Deploy: Launch the application!

6. Health Checks: Verify that the application is running after the deployment is complete.

Without a pipeline, developers would have to manually go through all these steps in OpenShift after they make changes to the application’s code in the GitHub Repository. With a Jenkins pipeline, all the developer needs to do is go to the Jenkins web interface and run the pipeline. By running the pipeline, Jenkins will access OpenShift and perform all these tasks. If there are any errors, developers will be able to quickly identify where things went wrong and make code changes. Jenkins pipelines ensure that applications are held to a standard of testing and functionality.

Put it all together!

You’ve made it this far, so you might as well put it all together. Use the diagram below as a reference point to keep you on track. (It’s the same as the one above!)

Developers write code to create and edit applications. They store this code in a GitHub repository (the yellow box). Developers can use OpenShift to actually run their application (maybe it’s a website or a machine learning algorithm).

Using Jenkins, developers can automate some of the tasks they perform to run the application on OpenShift. One way to automate tasks is through a pipeline. Developers can write code and store it in a GitHub repository (the orange box) to define the stages of a pipeline. Once this is done, developers can use the Jenkins web interface to run the pipeline.

Running the pipeline will go through several stages, which should lead to a successful build. When there are failures, developers can examine logs to identify errors and fix code issues. (Jenkins can even notify developers over email or Slack with the latest result of running the pipeline.) Jenkins saves developers time in the long run, as developers would no longer need to repeat the same six steps in the pipeline every time there is a change to the app code in the GitHub repository.

Where do you go from here?

With all of this in mind, you are equipped to move forward, even if you don’t understand all the finer technical aspects! If you’re dealing with an application that doesn’t go through very many code changes, maybe you don’t need a pipeline. Just because you can automate a task doesn’t mean that you should. In general, setting up a pipeline is going to save you time. You just need to be smart about how you use them and which stages you choose to include.

For more information, please contact Red Hat Consulting at https://www.redhat.com/en/services/consulting