CICD on OpenShift Part One


I have successfully migrated ‘Dilbert’ from EC2 instance to OpenShift. Dilbert is an automation bot that we use to offload some daily operations. In this article, I will show you how it works.

In the Dilbert project, I have one build configuration.  For each version, I only build once. This to ensure only one binary for each version. There The two deployment configurations: one for UAT environment (Bot Name: Raymond), the other is for PROD environment (Bot Name: Dilbert). They both are generated by script from the same template, the only thing that the script changes is the specific configuration for each environment, like configmap name.

Screen Shot 2017-11-06 at 9.45.15 AM.png

Screen Shot 2017-11-02 at 3.55.56 PM.png

This is the CICD workflow: commit > build image > deploy to UAT (Raymond) > test UAT (Raymond) > deploy to PROD (Dilbert)

dilbert_cicd.jpg

Lets check the current running version of both environments. They are both version v0.19.

Screen Shot 2017-11-06 at 9.55.41 AM.png

Screen Shot 2017-11-06 at 9.56.28 AM.png

Now, let me commit a change to see what is going to happen.

Commit a change to add a ping test.

Screen Shot 2017-11-06 at 10.01.56 AM.png

A new build has been triggered.

Screen Shot 2017-11-06 at 10.01.25 AM.png

A successful build triggered a new deployment to UAT (Raymond).

Screen Shot 2017-11-06 at 10.04.48 AM.png

Now it is time to check with Raymond. The running version becomes v0.20. And Raymond responds to my Ping test.Screen Shot 2017-11-06 at 10.09.21 AM.png

I am happy with my new commit, and I want it to run in PROD. All I need to do is to promote the release-4 to PROD.

Screen Shot 2017-11-06 at 10.12.15 AM.png

Lets check with Dilbert to see the difference. It is v0.20 now too. You may notice that Dilbert responds twice to my question ‘version’, that is because the deployment was doing rolling upgrade, spin up a new instance, and wait for it is ready, then terminate the old instance.

Screen Shot 2017-11-06 at 10.14.42 AM.png

Isn’t mazing? With container technology, build and deployment are becoming so efficient. I have a command ‘how old are you’ to check how long the instance has been running. Let’s have a look – the new image was built at 10:02:14, the new instance was created at 10:03:38, so it is only takes 1 min and 24 seconds to deploy a new version!!

Screen Shot 2017-11-06 at 10.20.13 AM.png

As a thumb of rule, you should always have more than one way to release your codes. Imagine now I want to roll back my change in PROD, and due to some unknown reasons Bamboo suddenly becomes unavailable.

No worries, I have got it covered. I am still able to do a new deployment from terminal on my laptop.

Screen Shot 2017-11-06 at 10.29.09 AM.png

Let’s do a new deployment to roll Dilbert back to v0.19.

Screen Shot 2017-11-06 at 10.31.54 AM.png

v0.19 is back now. By looking at the release number, I know it was not deployed from Bamboo this time 😉

Screen Shot 2017-11-06 at 10.32.52 AM.png

In my next post, I will explain in details how the thing works.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s