Continuous Integration (CI) & Continuous Delivery (CD) is a culture every company should adopt for better productivity, troubleshooting, timely delivery, happy customers, and many more.

It doesn’t matter how big your company is or how complex is your application, it is a best practice we should follow.

It can be Continuous Delivery or Continuous Deployment; both are similar concepts in some manner but there is a slight difference. Continuous Delivery means changes in the software are automatically tested & uploaded to repository like GitHub. The main purpose of it is to reduce the efforts required to deploy the code.

Continuous Deployment means automatically releasing new code changes from repository to live customers. This is useful to avoid all manual processes which slow down the release. We will talk more about CD in the next blog.

CI is a practice that focuses on keeping release ready always. Here is a high-level diagram that talks about processes to be followed in continuous Integration.

CI needs a lot of discipline to get it right, to make it successful new changes in your application should be pushed, built, merged & tested regularly to a shared repository.

Failure/s in each module should be communicated to a development/concerned team immediately. It is recommended to complete the whole process within 10-15 minutes.

As a part of Continuous Integration, developers commit their code daily (or as decided by the team) into the repository. This will help to identify bugs and other quality issues on small code rather than large code implemented over a period.

It’s recommended that commit frequency should be daily or twice a day to avoid conflicts which occurs working on the same code and merging it before commit. You need a version control system for the same as GITHUB.

The goal of implementing CI practice is to allow multiple developers/teams to work on the same application simultaneously. If all the developers are trying to merge code manually after development is done, the task will be time-consuming & error-prone because of conflicts. Continuous Integration helps the developer team to merge their changes in a shared branch daily. Once merged, changes will get validated automatically by building the application and running different levels of automated testing (smoke, unit & integration testing) to make sure new changes didn’t break the existing running application.

CI needs a lot of discipline to get it right. There are different techniques team can use to make their life better.

It is also known as simple branching which allows developers to keep changes for a specific feature in its own branch and collaborate with the central repository. Feature branching mainly used to work on user stories. Changes to the branch do not affect other developers.

It’s quite common that a developer is working on something and can’t complete it in a day or in a week or business priority changes (which is common always ) and he has to leave his work which is incomplete. Committing such a code to the repository is dangerous because it will cause conflicts. Not doing so will disturb your hard-earned practice/discipline. Featured flags can help you in this situation; you can keep the flag off until build is ready for testing. The testing team or business will not realize about new feature until you enable it for them.

Teams can use flags to activate or deactivate new modules depending on their readiness. This is called feature –level configurations.

Business always wants immediate results so an easy rollback of a new buggy feature can always help in quicker disaster management. You will start with one flag and once you will love it there will be a series of flags one can see in your code. Business will be pleased to see a new feature can be activated/deactivated so quickly which they want. This will not restrict any deployment due to error in a feature as developers can easily disable the feature which is causing the problem.

Feature flags tool is a double edge sword so developers should be cautious while using it. Having too many flags in an application will be an error-prone design and difficult to manage.

Proper documentation is always required to implement a successful Continuous Integration. It will help new team members to understand existing processes and avoid any future conflicts such as accidentally activating/deactivating feature flags.

CI/CD is not bound to any vendor/tool. There are many tools available in the market with their unique features. Some of them are absolutely free. These tools help organizations in automated daily backup, automated build & testing, automated deployments... etc. A company can validate all these tools against their requirements to get the best one.

Here is a list for reference,