The goal of this post is to share with you some ideas and experiences we’ve been collecting through the years working with customers and partners to deliver software that meets their business requirements on time.
The application of agile principles to develop software makes possible the incremental delivery of new features to the customers. But at some point we face bottlenecks to move these new features into production environments due the following reasons:
When these problems come up we start to batch up the changes to be moved to each stage (production stage is the most common one) this ends up in infrequent releases and removes the opportunity to receive feedback from users quickly.
Organizations could take an approach to implement more manual processes and constant collaboration between teams, but at some point this is going to reduce productivity and generate burnout in team members due the amount of time and meetings they will have to achieve results. At the end of the day automating the build, test and deployment steps helps to get the features done efficiently and quickly.
The point is that apply a DevOps culture at the beginning could be really hard but there is an important quote related to this:
“DevOps takes the view that if something is painful, you should do it more often”
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:
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:
A CI server has the following missions:
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:
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.
Legitimate scenario:
Questionable scenario:
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.
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:
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:
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.
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
Leave A Comment