Let’s start by defining what CI/CD is. Continuous Integration (CI) and Continuous Deployment/Delivery (CD) are practices that automate the steps that must be performed to release new versions of software with the following advantages:

1. The software delivery to the clients can be achieved faster and efficiently
2. Reduce the time to publish the applications to the production environment
3. The code quality can be improved by including automatic tests and static code analysis tools

But, how does this happen?

Continuous Integration reduces the risk of integration issues and improves code quality. Developers commit their changes to the codebase regularly and check whether the codebase still works when other developers are contributing. More than a technical component, Continuous Integration is a cultural component where developers learn good practices to integrate their changes frequently.

Therefore, we have integrated GitFlow in our software development workflow. It has helped us to apply good practices to work collectively, keep the history of our repositories consistent and reduce significantly the risk of integration issues and bugs introduction.

These are some tools you need to apply the principles of CI:

1. A source or version control system to store your codebase
2. Automated build scripts
3. Automated tests
4. Infrastructure (Virtual Machines) to run your tests and builds

A CI server has the following missions:

1. Monitor your repository looking for changes published by developers
2. Run automated tests, if tests don’t pass the changes won’t be merged into the code base

Is continuous delivery the next step?

After all steps of Continuous Integration have been completed, Continuous Delivery takes place. This practice automates some of the steps required to deliver our solutions to the production environment.

Continuous delivery integrates a set of processes, tools and a culture of collaboration and continuous feedback to accomplish the mission. A change of mentality of your team is important to:

1. Understand that your new feature is not done when the other team takes care of it. The feature is done when it has been released in production
2. Create practices to better understand what is needed to deliver new features to users through the software development lifecycle
3. Maintaining open communication with other teams, collaboration and feedback is very important

Implementing a pipeline requires the identification of pain points and bottlenecks that could affect the delivery process, and implementing practices to detect bugs early is relevant. After you have identified these items, think about which ones can be automated (it is not mandatory to automate all of them), it is very very relevant to manage some scenarios manually. This is what we call manual gates, some of them might be questionable, whereas some could be legitimate.

But what is a legitimate or questionable scenario?

Legitimate scenario:

• Allows the business team to make a last-minute release decision. As examples we have: They have detected that some important feature is showing failures, monitoring alerts from dev or staging environments
• The business team makes the final decision to release the product to the customers, with all the approvals required

Questionable scenario:

• Just don’t apply the all-or-none approach, this is related to subsystems building a system. This means that when a subsystem deployment fails you have to roll back the deployment of the entire system

Another important step for continuous delivery is the definition of one stage almost equal to production to validate environment configurations and execute manual testing is helpful to advance with the security audit, find vulnerabilities and detect bugs early. You are going to have a lot of space to improve.

What about continuous deployment?

The final practice you can apply is continuous deployment where continuous integration and continuous delivery are taken to the extreme making this process entirely automated.

The code pushed by developers is automatically tested, built and deployed without any manual intervention. Big companies have adopted this practice including elements to validate the releases in production with help of their users and avoid potential unavailability of services:

• Canary deployments: limits the deployment of new code to some users. This is important to detect failures, receive feedback and obtain some metrics like usage and resources consumption
• Blue/Green deployments: The new code runs in parallel with the previous version, then you compare the metrics and behavior with the baseline and take the decision of completely deploying the new version or rolling back to the previous code

What are the recommended tools for CI/CD?

We don’t want to create a ranking or something like that, thru the years we’ve seen projects that have implemented solutions with these tools:

• Gitlab
• Jenkins
• Github Actions
• AWS CodePipeline
• Travis CI
• Circle CI-

Conclusion

It is not All-important to know every detail or the semantics about the differences between continuous integration, continuous delivery and continuous deployment. At this point you should be able to identify the concepts, steps, practices and benefits of starting with the implementation of this culture in your projects.

Finally…

This post has been written with the support and collaboration of Fernanda Jaramillo and Ihann Pascuas, Thanks to Ayté and TBBC for providing the tools and projects to validate these ideas.

All the best, don’t hesitate to contact us if you have questions.

Esteban Cerón