DevOps knowledge points-how much 3C knows
Posted May 27, 2020 • 5 min read
CI/CD is the two cornerstones of any DevOps operation. This is a way to develop software designed to produce fast and powerful software that can be updated in a sustainable manner at any time. When code is changed routinely, the development cycle becomes more frequent, more meaningful, and faster. Through this process, we can ensure that only known good code becomes part of the software product.
Continuous Integration, Continuous Delivery, Continuous Deployment, that is, continuous integration, continuous delivery and continuous deployment constitute the 3C of DevOps. In this article, the following aspects will be explained:traditional integration, continuous integration and process, continuous delivery, continuous deployment, 3C advantages.
In traditional integration, the team does not have any type of central build server. Source code can be stored in a central source code repository, but developers do not have to submit changes regularly. Before the planned release, developers may manually integrate changes, which can cause many problems, such as last-minute conflicts caused by many developers integrating at the same time, or component failures due to integration.
Some of the disadvantages of traditional integration are as follows:Developers do not often integrate code, resulting in hidden dangers at the last minute; the feedback loop is slow; problems cannot be easily solved due to the need to repair many components; it is difficult to deliver products on time; In order to overcome these problems, CI and CD came into being, they have many advantages from the technical and business perspectives.
Continuous integration is a development practice that requires developers to integrate code into a shared repository multiple times a day to avoid code conflicts. **
Then, each check-in is verified by an automatic build, allowing the team to discover problems early. This allows the team to spend less time backtracking and spend more time building new features.
The concept here is to have multiple developers on a project to keep the main branch of the repository in the latest form of source code, so each developer can check out or extract from the latest code to avoid conflicts .
Developers develop their functions in their own specific branches, and then push their new branches to the collaborative repository. Run automated unit tests and integration tests, and notify the team of errors and other code quality issues. Once the automated test passes, the developer creates a pull request. Developers and reviewers can directly comment on changes submitted by developers to the master branch.
After completing the review process and merging the new code into the main branch, the function development and bug fix cycle will continue to run from the integrated main branch. This usually happens many times within a team(especially large teams where everyone is dealing with many small tasks), which means everyone is working on the same common code base. This greatly reduces the code differences and related problems caused by the function developers being out of sync with each other.
Continuous delivery is a process in which code changes are automatically generated, automatically tested, and prepared for release into the production environment. Software can be released into the production environment at any time.
The code submission for continuous integration will be further tested for performance and functionality until it is approved for release. To effectively implement continuous delivery, strong continuous integration is required. If implemented correctly, developers will always have deployable build artifacts that have passed standardized testing processes.
This process starts when the developer submits the code and ends after completing the test in the staging environment so that the code can be deployed to the production environment. If any errors or bugs occur during the automatic testing process, the CI tool will automatically notify the developer through any kind of notification(such as email or SMS).
Continuous delivery usually involves a staging area similar to production, which needs to be manually accepted before changes are released to production.
Decisions released to the production environment are more business decisions than technical decisions.
Continuous deployment is very similar to continuous delivery. The only difference between the two is that in continuous deployment, all code submissions that pass the automated testing phase will be automatically released to the production environment.
Continuous deployment does not require any manual testing in the staging environment, because automated testing will be performed in all phases of the release.
Both of these CDs rely on real-time infrastructure configuration and application monitoring tools to discover problems that were not identified in the test feedback loop due to lack of manual verification before deployment.
1. Mitigating risks
Many developers face the problem that applications can run in the local environment, but cannot run in the face of more advanced usability. This is because there may be many differences between the local environment and the place where it is put into production. Some quality assurance tasks, such as browser testing, can reduce the risk of spreading bugs all the way to the active site.
2. Speed up time to market
Continuous integration, continuous deployment, and continuous delivery applications can enable teams to find faults and fix them faster, thereby increasing software release rates and speeding up delivery.
3. Changes can be traced back
All team members must use the same source repository to maintain their code. Obviously, you can see what changes were made to the code base and by whom.
4. Improve code coverage
The CI server checks the test coverage of each build. No matter where you submit new code for untested classes, the server will display an error because there is not enough code coverage, so developers will work to increase the coverage of low-level availability so that when deployed to higher-level availability No problems related to code coverage will occur.
5. Quality:from excellent to excellent
CI helps testers spend 50%of the total project time on running integrated nominal tests, finding bugs and other subtle issues. This allows the test team to study the problem more deeply, test more scenarios, and produce better overall quality and results.
6. Less backlog
Incorporating CI/CD into the team's development process can reduce the number of non-critical defects in the backlog. These small defects will be detected before production and fixed before release to the end user.
7. User Satisfaction
As the deployment runs in successive cycles, this will enable the team to track the project and provide feedback in real time, and fix defects in the team if necessary. Through a consistent review, the development of new products will be more elaborate and will better meet the expectations of end users.
8. Reduce friction between team members
Code that ensures that multiple developers working across multiple locations is always integrated into a common repository. This avoids confusion caused by large and conflicting code submissions.
In today's rapidly changing competitive environment, developers are trying to get their products to market quickly, and it is almost impossible to release high-quality code without a concise and appropriate process. Thus, the shift to continuous integration and continuous deployment will greatly change the software development process. It will simplify the entire process, thereby helping the team to provide more stable, safer, and better products.
References:Krishnagayathri Gopinath .Continuous Integration And Delivery \ [OL ].(2020-04-27) https://dzone.com/articles/co ...