The implementation of the Continuous Integration culture allows for immense gains and benefits for development teams, including Continuous Delivery.
Like DevOps, Continuous Integration (CI) is about culture and process and you need to implement it quickly.
In general terms, it is a practice of the development team to centralize all the codes in a repository.
Next, several actions and possibilities are considered, such as process automation, test execution, standardization, notifications, execution of routines and the publication of updates in the desired environment.
In this article, the idea is to approach the concept and some possibilities, in the next articles we will talk about tools for the implementation of this culture.
Continuous Integration is also commonly known as CI, the initial letters, but we also find literature addressing the subject as Continuous Development (CD).
Repository and Environments
The starting point for implementing this process is to centralize all project files into repositories for versioning.
In addition to being necessary to enjoy the possibilities, it is also required for teamwork. In addition to backup and alternative to go back to the time codes (like a time machine) and save each version already published and those that are in development.
Considering GIT as a repository, we can link branches to each development environment in use.
Considering a scenario with three environments, Development, Homologation, and Production, we could consider, for example, branches development, homolog and master, respectively, to associate the repository with their respective environments.
Process Automation
With the alignment between repositories and development environments, we can have the magic of automatic publishing of files.
That is, whenever a file is sent, through commits, to a particular branch we would have a process attached to it to send the files to their development environment.
Nothing to finalize programming and need to connect in FTP programs to send files. And honestly, a good developer does not like FTP, it is retrograde, slow and nothing functional.
The self-publishing process files in environments with a CI process open the door to an infinite possibility of automation. The simplest of these is the automatic publishing of files on the server.
Testing and Standardization of Development
With several developers working on the same project, it’s important to follow a developmental pattern. Everyone on the same team needs to speak the same language.
You can configure tests to run before the code is sent to the branches in the GIT. With this, only if the code is in the default would be accepted.
So the developer would be warned that there is something wrong or the pattern was not followed. So, nothing like a good cup of coffee to help you standardize and complete the demand.
Routine Execution
Files, when published to the server, must be routinely performed to ensure security and performance, for example.
Folders and files need to follow different permissions. These settings can be made automatically by performing a routine for this purpose after publishing the files on the server.
JavaScript and CSS files can also be compressed for better performance and loading time.
When you have defined the necessary processes to be done after publishing the files on the server, you can automate these routines with the Continuous Delivery culture.
Communication in Continuous Integration
As we are talking about processes, routines, and automations, we must also consider communication for better process flow.
With each posting of files in the repositories or server, you can notify the team involved via e-mail or channels in Slack. Be positive to report success or report failures.
In this way, automation talks with those involved, notifies, alerts and everyone is in tune with events.
Backup and Rollback
With all the files centralized in repositories, in addition to all the benefits mentioned here, we ended up performing backups and a true machine of the time of the project and we can go back in what time we would like.
A Continuous Integration culture also allows us to be very responsive with the rollback of publishing to the server.
Imagine that some bug has happened, or that for some other reason the publication needs to be undone (and fast) because it is peak time and we have a large audience.
Just go back to the previous time of publication and let the process carry out a new publication. Thus, we solve the problem in an agile, effective way and we return the programming for analysis and corrections.
Imagine having to perform this process with FTP?
Conclusion
The culture of Continuous Integration employs numerous benefits and possibilities. The winnings are really incredible.
With this culture employed, we will dedicate more time to creativity and focus on the production of the project. The rest will be robot responsibilities.
The well implemented Continuous Integration scenario will perform incredible Continuous Delivery actions.
