It´s worth investing a little time to understand continuous integration (CI) and continuous delivery (CD), mainly in the development software world in which exists are builds and controls version repositories.
CI — Continuos Integration
CI is a process that allows us to make changes quickly and easily without being painful.
Newman, Sam. Building Microservices . O’Reilly Media. Kindle Edition.
The main goal of CI is to keep the team in sync with the existing code from the repository. Basically, a good CI detects that the code has been committed, and runs some verifications such as if the code is compiling and if the tests are passed.
This process brings us many benefits, such as fast feedback about the application. This process allows us in each modification to have faster feedback about the last changes made, if any flow was broken, for example, we can do this over and over again, gaining more confidence when we need to update a feature, o refactor any piece of the code.
Tools it’s not enough
Sometimes we think that because we have a Jenkins or Circle CI or any tools that you know, have been installed and working in the CI server, we believe… ok I use CI in my team, but in fact, to have these tools it’s not enough.
In my career, I’ve had the opportunity to see what these big guys, Sam Newman and Martin Fowler explain about this process.
CI the right way
Building high-quality pipeline
I’ll share with you some format pipelines I saw in my career.
In a pipeline, there are stages that run some tasks that need to validate and build the application which will be deployed.
In img-1.0 above, is a great form to build a pipeline process, basically, the code source is a git serve, for example, the CI serve does checkout this code source. After checkout, the pipeline can build the artifact by source code.
The pipeline has some stages that all CI processes should have
Why don’t run all tests together?
The main reason is unit tests are faster than integration tests, so if any unit test has broken, you get feedback faster by running the unit tests first.
Continuous Integration & Continuous Delivery by environments
There are ways to build a CI process for different environments, it is necessary because, for example: if a software engineer is developing a new feature yet, he can run the pipeline and deploy this new feature until the staging environment for executing exploratory tests.
Below there are other pipeline examples
In IMG-1.1 above is a pipeline without a migration stage, if the software engineer needs to do structural modification, he needs to run a migration script in your workstation or in another pipeline.
In IMG-1.2 above, are pipelines for each environment sometimes some teams have the preference split the CI server by environment instead keep a unique pipeline, the reason is security, and these teams work with Feature Branch normally, for example, to trigger the production pipeline should have a commit for the main branch.
Another way of working with a pipeline is adding manual releasing for some environments
In IMG-1.3 it is very common for many teams to use this way, to prepare a version of code for production but only release it manually.
CI process it’s not just having a server with CI tools, but you made and keep a process in a team.
The CI process improves the confidence of software and provides faster feedback and reduces bugs in production, the CI tools run these processes.
Continuous Delivery (CD) — means that if the process of tests, and builds are being run with every commit and validated, then it is possible to release the software to production at any time, as we see in examples such as IMG-1.3 each commit to your code is ready for production but does not being release to production.