How Continuous Integration & Continuous Delivery (CICD) works.

If you’ve heard about CICD and wondered what it meant or how the entire process works, this article would illuminate your understanding.

If you also always find yourself in that awkward situation where there is no working demo to present before a ready to purchase client, or it takes forever to release upgrades to end users, breathe easy there’s something you’ve been missing out on called Continuous Integration & Continuous Delivery.

Continuous Integration simply refers to the the process of committing code changes to a central repository several times daily.

Continuous Delivery simply refers to the process of moving the small integrated changes to the production environments (the product as used by customers).

If you are the business|product manager of a software development team, you should probably do a room wide moon walk, because CICD would reduce the time to market for any feature you intend to build into your product.

CICD takes aim at eliminating problems in the software development life cycle including controlling releases and increasing the speed of delivering upgrades to end users.

What do i actually mean? Most teams building software without CICD have common pitfalls, most especially with integrating upgrades to live software. Things get really tricky, bugs could result and might be difficult to track and resolve, unexpected behavior might occur leaving the developers with no clue and it all boils down to a bad customer experience, they disown your app and continue with their peaceful lives.

Continuous integration and continuous deployment creates a convenient way for moving code from a developers computer to the live server which serves the application the end users interact with. Now allow me break it down for you.

Lets picture the entire CICD thingy as a pattern that has a few steps, now lets also paint a scenario to emphasize the inner workings of the entire process.

For example we have a software development team comprising 4 developers that intend to build a car sales app. Step one would be to review the business requirement document and create user stories to cover all the use cases. Next the developers might conclude on the programming language(s) to use in building the entire project. Next, if it’s a PHP application the developers might choose to go with Laravel or Falcon. So far the user stories have been created and the framework set, everything looks great.

Next the team creates a repository on Github, and make an initial commit with a fresh installation of their newly downloaded Laravel app. Easy like a breeze, CICD is still coming along well.

Now the stories are popped into a task assignment and tracking tool like Pivotal tracker, Asana or Trello. Devs rush in and pick up stories, the coding has begun.

Heard of the word TDD before? if its an acronym that has confused you in the past, i sincerely apologize for the jab, it wasn’t intentional. Test Driven Development(TDD) in simple words means that the integrity of your code is vetted by some unit or integration test you have written even before you started writing the main code for that feature. It involves writing unit test first to validate a particular thing before writing the main code to do that particular thing. TDD can be explained easily when compared to form validation. When an invalid input is entered or incorrect credentials are entered, the form refuses to submit and the user is never logged in. In Test Driven Development you write validations for your code in form of unit tests and if your real code implementation is failing the tests, the developers commit(s) would never be deployed to the servers.

Why did I take out time to explain TDD, its because it serves as a major back bone in the CICD life cycle. The quality of your tests and the level of your test coverage serves as the gate keeper for integrating code, and if your test are poor, buggy code could still be integrated.

Now that we have TDD off our chest we can proceed with our CICD flow. To be sure allow me reiterate, so far, each of the 4 developers can commit to the same repository, they are also TDD compliant as they write quality tests before they write the actual implementation.

Next we need to integrate a CI (Continuous Integration) build server, that can automatically run all the tests that the developers have written since they started working on the project. Version control applications like Github and Bitbucket can integrate with several continuous integration servers like Circle CI, Travis Ci, Drone or bitbucket pipelines to mention a few. Don’t forget the CI servers helps us run the test directly on the repository and would require that we put a special .yml file in the root directory of the project’s repository. This .yml file contains instructions on how the CI server would build the app and test the code. The configuration of the .yml file depends on the CI server being used, but usually they are similar in some ways, just read their documentation.

Now, with TDD best practice and a continuous integration server directly connected with our repository we would need to map our branches to various environments.

Have you heard of the words, production, staging and development environments. If you haven’t, I didn’t mean to sucker punch you again. Don’t get scared, it simply means that the same application that the team is building has been deployed in 3 different places with different URLs.

For example:

http://development.carsales.com (Development Environment)

http://staging.carsales.com (Staging Envirornment)

http://carsales.com (Production Environment)

In your Github repository, you would have to create 3 separate branches E.g. develop, staging, master.

The mapping would be done in the .yml file, every CI server have documentations on how to configure the .yml file. But usually they generally give you the ability to write instructions for any number of branches on your repository.

Example:

branch: **develop:

-run test

-push code to development server

branch: **staging:

-run test

-push code to staging server

branch: **master:

-run test

-push code to production server

Most times how it works is, whenever code is pushed to any of the branches specified in the .yml file, it would run the build script for that branch, and if the build is successful, it means the code is compliant and can be safely integrated. After which the code would automatically deploy to the server specified under the branch.

Also note that it is best practice for these special branches to be restricted from direct pushing, and allow for merging only. This would provide a structured approach to how your code is deployed to any of the environments.

For example:

The develop branch would be merged into staging, then staging would be merged into master. None of the developers at any point would be able to push directly to any of these 3 special branches instead they create other branches and merge into develop. Develop becomes the single source of truth that would be promoted to the other branches.

When the quality team perform a user acceptance test on the staging environment and find it stable, they can give a thumb’s up and the commits would be merged to master for the changes/new-features to be deployed to the end users.

CICD is a life saver, speed of deployment is second to none, bugs can easily be tracked and resolved. Now that you know how it works endeavor to adopt it in your software development practice. Cheers