DevOps: CI/CD
CI Principles
Continuous integration is a software development practice, which engages the developers to regularly merge changes in the code to the central repo, with following automated build processes and automated tests. The main goals of CI are to find and fix mistakes, bugs as early as possible, what leads to improved product quality, and reduces the time for validation before releases. Previously, in projects where different developers work on separate parts, the integration stage is final, this can greatly complicate and delay the release.
The basic principles of CI are:
to have a managed repository of code
to integrate the changes as often as possible, and build every commit
to make builds self-tested, as it is important to identify errors as early as possible
to store each build, and to have a history of these builds, the archive
to use multiple environments sorted by the code stability running on them
So, the CI process assumes that we build every commit. Why is this important? A frequent build allows you to identify problems much earlier. It's worth noting that frequent integration is useful and not suitable for all projects.
CD Principles
Continuous Delivery is a software development practice, according to which code changes are automatically collected, tested, and become ready for release in production. In fact, it extends Continuous Integration with deployment of builds to testing or staging environments, where they pass expanded testing. If everything is done correctly, the outcome is an artifact that has passed all the tests and is ready to production deployment.
CD principles:
Every successful change can go (and will likely go) to prod
All steps should be automated
Test coverage should be as full as possible, including unit tests, acceptance tests and so on
Works best with canary releases
Last updated
