This is the 16th day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021

This translation: levelup.gitconnected.com/basics-of-c…

CI stands for Continuous Integration;

Continuous Delivery — Continuous Delivery;

Any business software project wants to make money quickly by automating business processes. Fast iteration, fast release and stable update mean that the project can go further;

Although this process can be done manually, cloning a code base manually, linking to a remote server manually, building manually, running commands manually, and so on — any manual process means a greater risk of error than automatic!

CI

CI continuous integration describes the repository change process, as shown below:

We can work together and the final changes are applied to the Master branch; But such a simple model also hides some problems:

How do I know if the code for the master branch is deployed successfully?

How to verify unit test coverage?

Iii. How to judge whether team members code according to uniform code specifications?

These problems can also be verified manually, but they are troublesome, inefficient and error-prone. Give it to an automated CI, that’s what it’s here to do!

First point: How do I know if the code for the Master branch is deployed successfully?

The CI process is as follows:

  1. Every time a change is pushed, the Git server sends a notification to the CI server;
  2. The CI server clones the repository, checks out the branch, and merges it with the master branch;
  3. Then launch the build script;
  4. If Code 0 is returned, the build is successful. Otherwise, it is regarded as a failure;
  5. The CI server sends a request with build results to the Git server;
  6. If the build is successful, merge requests are allowed. Otherwise, the merge is blocked;

This process ensures that code merged into the main branch does not break the build!

Second point: test coverage detection!

At no time should the master branch have less than 50% test coverage; This can be done with the Jacoco plugin;

However, how to use this plug-in also needs to be explored: not all code should be traversed ~

With SonarCloud, you can only check test coverage for new code!

Third: uniform code style;

Use the Checkstyle plugin! For example, if there is an unused import in the code, build failure is returned; Of course, this can be customized according to the needs of the project;

CD

CD continuous delivery describes the process of automatically deploying new releases of a project

A picture is worth a thousand words:

The CI server evolved into the CI/CD server, and you could delegate CI jobs to GitLab CI and CD jobs to Jenkins.

I’ve already talked about CI, so let’s talk about CD details;

In fact, we can deploy in multiple phases:

  1. Deploy when requesting a merge;
  2. Timer deployment;
  3. Deploy the Pull Request when it is joined to a specific branch.
  4. You can also combine the above options;

It is important to understand the deployment process and choose the right deployment method. Deployment is release!

Some common CI/CD tools are provided here: Jenkins, GitHub Actions, GitLab CI, Travis CI

OK, that’s it

👍👍👍👍 college

I am Anthony Nuggets, the public account of the same name, every day a pawn, dig a gold, goodbye ~