Continuous integration and continuous deployment (CI/CD) is an agile approach used by many organizations. It is helping these organizations distribute software efficiently and safely.
According to the GitLab 2020 DevSecops survey, almost 83% of developers say they are releasing code faster and more often than before. Fifty-nine percent of companies say they publish multiple times almost every day. This is due to the DevOps approach, and is largely due to continuous integration, automated testing, and continuous deployment.
Each organization tries to introduce its own approach to the CI/CD pipeline, and eventually finds the perfect balance, which we often refer to as “best practices.” This article discusses some of the basic principles of an effective and safe CI/CD pipeline.
reliability
Having a CI/CD pipeline in the software development life cycle is a great boon for an organization to be able to quickly build and deliver applications, but at the same time, it is important to choose the right CI/CD pipeline that will scale as the business organization grows and run correctly. Moreover, it should be flexible enough to handle multiple use cases and multiple software delivery requirements.
The CI pipeline should be fast
It is very important to make the CI/CD pipeline as fast as possible. All of our automated tests run on the CI pipeline in the development environment and are eventually deployed to the production environment. Therefore, it is important to cover all edge cases and potentially fatal failures, and we need to ensure that all these changes do not cause any unexpected errors in our code. Therefore, it is important to keep the CI pipeline simple, fast, and safe at the same time.
With the widespread adoption of micro-service architectures, the CI pipeline becomes straightforward (as opposed to monolithic architectures). But if the pipeline is heavy, it’s best to remove tests that don’t have a significant impact, and document the trade-offs. We should also prioritize our tests. Tests that run faster should be executed first. For example, unit tests are faster and are the foundation of a program function or module, so they should be executed first, followed by functional and integration tests. In this way, we can find mistakes early and save time. Developers should run tests locally before pushing code to catch bugs early.
Build and run in a standalone environment
It is always important to run the CI/CD pipeline in a separate environment to ensure that our test results are more accurate, both from a security perspective and to ensure that it is similar to a pre-release environment and a production environment.
We can use Docker or any other container tool to run our test suite, or we can install other dependencies for our application in the Docker container. This way, we can ensure that our tests are run in complete isolation and without any influence from the underlying host. Since our CI/CD platform has full access to our code repository, most organizations are also accustomed to deploying CI/CD tools in their cloud platform infrastructure for security purposes.
Many organizations are going a step further and rendering and testing UI components in isolated environments. This process is a way to verify that they are indeed independent (which is usually done using BIT (GitHub)) before delivering them as separate building blocks and integrating them into one or more projects.
A pre-release environment is equivalent to a production environment
It is recommended that the pre-release environment and production environment should always be equivalent to avoid the small probability of an unexpected error while running the test that causes the release to pause. Our CI/CD pipeline first goes through the phase of run testing and deployment in a pre-release environment. After testing, the application is automatically upgraded (or manually deployed) to the production environment.
It is difficult to make the development and test environments exactly equivalent to the production environment, but we can make decisions when needed to keep them as similar as possible, and understand the trade-offs we are making. Most organizations also use a “blue-green deployment” or “canary release” deployment strategy, where we first deploy the application in production and handle about 1% of the traffic. Then increase the traffic to 100%, or you can easily roll back to the previous version.
conclusion
All CI/CD tools are different, and each organization uses CI/CD in the most efficient and convenient way possible. But these are some best practices that everyone should pay attention to and follow to avoid problems in the future. Every organization should license and distribute software only through the CI/CD pipeline to improve code quality and the organization’s coding specifications.
The author | Ankit Jain planning | Tian Xiaoxu
Original text: __https://blog.bitsrc.io/ci-cd-…
