Continuous Integration / Delivery / Deployment ( CI / CD )
CI / CD processes are the inevitable items of medium and large scaled software projects. They are also essential concepts in agile and devops cultures. In this article I would like give some information about these practices, why they are necessary and how we apply these concepts to real life. If you want to go into basics, I’ll leave you alone with Martin Fowler.
Let’s take a look at acm-software about CI definition, nice summary:
“Continuous Integration is the system that aims to continuously integrate the code generated by the development team with the codebase. The integration process can be (actually must be) automated by some specific tools that uses scripts and processes as frequently as needed. This way the compatibility of the new code is being tested automatically and this also supports the integration errors being found earlier. In addition to that, unit tests or system level tests can be done automatically without any human effort. Running tests frequently without any effort ensures that the system is reliable and stable, resulting in high quality products. In summary, benefits of Continuous Integration are:
* errors are found and fixed earlier
* monitoring and measuring the health of the system is easier
* testing is done over working software any time, not based on assumptions,
* repeated human effort is decreased
* working software can be delivered anytime or in a very short time
* transparency is built
* trust is established inside and outside the team.
We can summarize the CI term: CI is the validation of developer changes by creating a special build process. This build process consists these steps: Fetching dependencies from repos, building codes, running automated tests (unit, integration, etc.. ) on this build, running code analytics, notification (email, sms etc..) to developers about possible results (error, success, warnings etc..) and finally packaging the build to next step (Continuous Delivery) As a result of CI, we have always
- A buildable-runnable version,
- Minimization of integration problems,
- Regularly execution unit tests, code reviews, code-analytics, bug detection,
- Reporting capable of project builds,
- Good communication infrastructure between developers,
- Awareness of the project development lifecycle by developers,
- As a result of all these things, good quality software-product.
After explanation of CI lets go on with Continuous Delivery — CD term. This term is used for releasing of the package that is generated in CI phase, to the environment usually called “development”, “test”, “staging”, “pre production”. This releasing work can be scheduled according to business requirements like daily, weekly. Quality assurance (QA) tests are run in this phase. Deployment (Production release) is done manually in Continuous Delivery pipelines.
If the production releasing is also automated then this process is called “Continuous Deployment.” It means user acceptance tests (UATs)are automated.
Both Continuous Delivery and Continuous Deployment save us the trouble of Release-Day-Pain. Because we already have a running, versioned, tested deployments in our environments.
Here is the big picture:
