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

CI/CD

In Continuous integration, all developer code is continuously merged into the main line of the code base, and then the main line is compiled and tested to verify the code.

The main purpose is to keep the software under development in a working state at all times, focusing on whether the code can compile successfully, and whether it can pass unit and acceptance tests, etc. When a developer submits new code, the CI server automatically builds the service to which that code belongs and performs fully automated tests on it

CD: Has two meanings:

  • Continuous delivery allows the master branch to remain releasable
  • On the basis of Continuous delivery, the owner will deploy quality builds to the production environment on a self-service basis and automatically deploy to the production environment.

Continuous delivery is a prerequisite for continuous deployment.

Three big environment

The product needs to be tested during the product delivery process, various types of automated testing in various environments, and once passed, the product is released online. Generally, the environment can be divided into three parts: Test environment, Staging environment, and Prod environment.

  • The Testing environment is the primary environment in which testers perform tests. The primary concerns are: functional Testing, defect fixing, regression, etc
  • Staging environment: an environment established to prevent feature defects in the test and production environments
  • Prod production environment, the environment used by real users

Gitlab CI/CD

The basic concept

  • -Dan: I don’t think so. -Dan: I don’t think so. When the code is committed or MR, GitLab will build a pipeline on the latest COMMIT. Multiple tasks on the same pipeline use the same version of the code.
  • Jobs: The smallest unit in a GitLab CI system that can be independently controlled and run. Developers can perform CI/CD operations by completing one or more Jobs for a specific commit.
  • Schedules: Pipeline scheduling runs pipelines in the future, repeatedly, to specific branches or tabs. That would be subject to a limited arrangement of pipeline projects based on the access of relevant users.

CI/CD process configuration

Create a.gitlab-ci.yml file in the project and configure the CI/CD flow. After submitting the code, the system will automatically look for the YML file and start a job for the commit.

.gitlab-ci.yml is a YMAL file, we need to pay attention to the format

stages:
  - test
  - build
  - deploy
  
  
before_script:
  - apt-get install rubygems ruby-dev -y
run-test:
  script:
    - ruby --version 
Copy the code

Submit code, and then if you look at gitLab, you’ll see that every time you submit code, you’ll get a job task, even if different branches have different job tasks.

Using GitLab CI/CD is that simple.