An overview of CICD

DevOps culture is a set of practices that reduce the barriers between developers, who want to innovate and deliver faster, on the one side and, on the other side, operations, who want to guarantee the stability of production systems and the quality of the system changes they make.

We saw earlier that one of the key DevOps practices is the process of integration and
continuous delivery, also called CI/CD. In fact, behind the acronyms of CI/CD, there are
three practices:
– Continuous integration (CI)
– Continuous delivery (CD)
– Continuous deployment

  1. Continuous integration (CI)

The most important of CI is give the developer a quick feedback as soon as possible if the build or unit test has some problem.
This CI process must be optimized as soon as possible so that it can run fast and developers can have quick feedback on the integration of their code. For example, code that is archived and does not compile or whose test execution fails can impact and block the entire team.

2. Continuous delivery (CD)

This is a link trigger process after CI. We call it CD process : Every build artifact that success will be uploading to Package Manager. And then this artifact build will be deployed to each stage environment : Development, Staging, Pre-Product…but not Production. During deployment process, automation test or acceptance test will be trigger to qualify the build product. Deploying to production is manually.

3. Continuous deployment

This is same flow with CD process but all step is automatically from end to end process that includes production deployment. This is best practice for CICD standard flow but sometime is not a best option to build up because production environment is very sensitive to automate everything, especially database deployment.

%d bloggers like this: