Why CI/CD
Let’s take a look at what CI/CD can do for us with two short stories adapted from real work.
The story of a
Today, in order to have A date with his girlfriend, Mr. A finished the development of the login interface before work, hurriedly submitted the code and pushed it to the remote warehouse, and then shouted in the group: “Help me review”, ready to pack up his backpack and leave the company.
You may wonder why A programmer has A girlfriend……
Regardless of his girlfriend, it is quite normal for A to ask A colleague to review the code, which is also an important factor to ensure the robustness of A project. However, It seems that Mr. A is just in A hurry to complete the function implementation, and pushes the code for colleagues to review before he has time to test himself, which is A kind of irresponsible performance.
In these busy times, it’s expensive to involve people in things that consume time and energy. If A’s code has some very low-level errors, such as syntax errors, passing wrong parameters, etc., B, who is in charge of review, may throw the table up and shout: “Why don’t I have A girlfriend? No! Why does he code so badly?” .
Like this can be done by the programming language itself, tools, or framework can discover problems, also need people to step in, it is a waste of time, the person’s time is precious, should be spent on more valuable and meaningful things, rather than become a syntax checking tool or even a single syntax checking tools… Anyway, you know what I’m talking about.
If there is a CI/CD…
After A pushes the code to the remote repository, the CI/CD process is triggered. The result shows that the build phase is not passed, and there is A syntax error during the build, resulting in the build failure. At this time, Mr. A was informed by the system that the code integration had failed before he packed his backpack. No other colleagues participated in the review, because such code was not worthy of review. So! Is Mr. A choosing love or work?
The second story
Today, Mr. C came to the company early, and Mr. D, the evil product manager, was half an hour late. Mr. D walked to Mr. C and said, “The homepage of the new official website should have a XXX link. The copy is XXX. After C gentleman change good, upload the new static file to the server through FTP tool, and then say to D gentleman, D gentleman looked and said: “the link is XXX right, oh! And a new activity page! Is there…” “In this way, they were busy all morning, and Mr. C kept revising and uploading. Mr. C burst out:” Why not have a background, so that a lot of things can be modified through the background? At this time, B coldly said: “A was fired, in the recruitment, endure ha.”
If there is a CI/CD…
Mr. C made modifications according to Mr. D’s requirements every time. After the modifications were completed, he only needed to push the code to the remote warehouse and trigger the CI/CD process. Soon, the new static file was deployed to the server.
After reading two short stories, maybe you can feel what CI/CD can do for us, but there are many details omitted in the story, so you can feel it.
So, what exactly is CI/CD?
CI Continuous Integration
In software engineering, continuous integration (CI) is the practice of merging all developers’ working copies to a shared mainline several times a day.
wikipedia
The concept of continuous integration is relatively easy to understand, but if translated directly, it would be “unreasonable”, so I’ll put it in my own words.
Continuous integration helps us frequently automate the merging of code changes into trunk or shared branches. Once changes are merged, the system responsible for integration runs automated tests (usually unit tests, integration tests) to verify the changes and ensure that they do not break the application, which explains the importance of testing. If the automated tests fail or the code conflicts, the entire integration will fail, the system will give feedback, the relevant developers will step in and fix it, and then another round of integration will start until the changes are successfully integrated into the trunk or shared branch.
The trunk and the shared branch, which I’ve shared with the Git trunk and shared branches before.
Continuous integration is relatively simple to implement, so in some projects that need to add CI/CD processes, continuous integration processes are generally implemented first.
CD Continuous Delivery
Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually.
wikipedia
Continuous delivery allows us to have a code base ready to deploy.
After the continuous integration process, a more complex testing process (such as functional testing) is introduced, which is deployed to the test server, where the tester steps in and performs the testing process, during which the tester gives feedback, and if the test fails, the developer steps in and fixes it.
In most projects, in addition to the test environment and production environment, there will be a rehearsal environment, the rehearsal environment to simulate the production environment as much as possible. After passing the test environment, the rehearsal environment needs to pass the test so that the new changes are considered usable in the production environment.
At the end of the process, we have a new code base that we can deploy to production, which is what we deliver, which is not exactly accurate, because delivery is project specific, programming language specific, etc. For example, now the project is an API service written by Go, So what we’re delivering is probably a built executable, or a labeled Docker image, rather than a bunch of code files, which I think you get the idea.
So we’re done delivering, and the timing of deployment depends on the business or the release window.
CD Continuous Deployment
Continuous deployment (CD) is a software engineering approach in which software functionalities are delivered frequently through automated deployments.
wikipedia
Continuous deployment is an extension of continuous delivery, with automated deployment following the continuous delivery process, meaning that if you fully implement CI/CD, your code changes will typically be deployed to production within minutes.
Want to know ideal is very beautiful, reality is very skinny, why say so?
There is no manual release gate in the final stages of continuous deployment, which means that if there is a slip up in testing and the new changes are not fully covered, there is a good chance that an accident will result, and that accident will become your story…… Far from it, therefore, continuous deployment is very testing to the level of automated testing.
Even if we can achieve perfect automated testing, in reality there will be other factors that you can’t readily used continuous deployment, such as business, the release of such factors as the window period, of course, if you want to subdivide, some emergency repair online vulnerability changes or can apply continuous deployment process, in a word, everything from set out actually, In order to make the most suitable choice.
trailer
Do you already have a basic understanding of CI/CD? CI/CD in vernacular, I hope it doesn’t become white CI/CD, hahaha.
Before practicing CI/CD, I’ll introduce you to Github Flow.
