Posts in DevOps

When you start at programming the traditional first program you learn to write is: hello_world() and it became quite common on every programming language you choose to learn.

The hello world of CI/CD

In CI/CD you probably noticed the term build > test > deploy > repeat and this is the hello world in DevOps.

But what does it means?

so let’s assume your code is in Python, then there’s nothing to build unlike Go (golang) so why do you need build stage?

Let’s start from end to start

let’s assume your app is already deployed and running at your cloud of choice, how do you update your app to a newer code?

• first build your code, why build? because it’s easy and convenient to use and deploy on different environments and can be reused or rollback if needed.
• second test your code, why test? because you want to ensure your app runs without problems or bugs (making sure code does what it needs to do)
• third deploy your new code (new version), so the users that use your app can have the new features or the newer bugs (that’s a joke) available for use.

How do you write your first CI/CD hello world?

1. write code in your prefer language of choice
2. build it via docker, and have a docker image from it (use tag for versions)
3. run tests on the functions of the code using the built image (from step 2)
4. deploy the new image after a successful test via docker with new image tag

so have fun with CI/CD and solve this problem for your company

You need to build a new Jenkinsfile / pipeline to build and test an application or a feature, so how many stages / steps do you use?

Also do you need a few stages or one stage is enough?

Here is where your approach comes to play, there are two main approaches I noticed in workflows from people

1st option: one stage to build and deploy

let’s assume you need to build an artifact from your code so one stage can be enough, something like: build your artifact > deploy (upload to your repository)

this approach will complete a couple of goals

1. your code is built automatically via scripted job and if the build passes you know part of the code is OK, will it deployed successfully on your server? maybe, so you may want to add install stage before deploying.
2. once your code built now it’s the easy part to upload the artifact to your repository or registry if it’s a Docker image.
   so it’s easy to understand and because it only two stages it’s faster to complete but you might want more options to integrate in your build.

2nd option: many stages to build, test and deploy

this approach will probably cover most of your software needs

1. you build your code and once it’s done you start the second stage and start testing, now you don’t need a test to build because that already being done so you can add the installing stage and just deploy your artifact on a docker machine to verify it can be installed as predicted.
2. once your artifact is installed you can continue to the next stage and add more test in a separate stage, here is where you might want to add commands to check some functionality that your code needs to do.
3. after the first phase of your tests is completed you can add another stage to deploy your artifact after install to a light environment like Docker or a testing server (Jenkins agent) and make an API call to test some functions to verify that your code is working as expected.
4. Now it’s where the parts come to play together, add another stage of tests to make sure your code can integrate with 3rd parties like Email, Slack or external API

once your tests are OK it’s deploy time

Time to deploy your code / artifact to your production server, it is recommended that you deploy it first to a staging server, just to make sure you didn’t miss anything, staging will run with your new code just a few minutes before deploying to production.

once everything is OK with your staging deploy to prod, a few options here:

deploy your code instead of the current version, until your deployment will complete your service will probably be unavailable temporary.

add another server to your servers group with the new version and once is OK remove the old version from the old server.

if your app have considerable traffic you might want check deployment tools like Spinnaker to deploy a canary approach of your app.

P.S.

use your approach based on your app needs and traffic