Gitlab CI CD basic concept

Gitlab CI CD basic concept

basic concept

Change of development model: waterfall model -> agile development → DevOps (a combination of Development and Operations, which is a collective term for a group of processes, methods and systems)

gitlab official website: https://docs.gitlab.com/ee/ci/

CI (Continuous Integration): continuous integration

• Push small chunks of code to the application code repository hosted in the Git repository, and each timeto pushevery time, a series of scripts are run toBuild, test and verifycode changes before merging them into the master branch
• Aggregating the work of various developers into one code repository, with the main purpose of catching integration errors early

CD (Continuous Delivery): continuous delivery

• When every changed code is put into the library, not only will it be built and tested, but it will also be deployed, butdeployneedmanual intervention, manually and purposefully deploy

CD (Continuous Deployment): continuous deployment

• Similar to continuous delivery, but instead of manual deployment, itautomatic deployment, without human intervention

Official Chinese introduction: https://docs.gitlab.cn/ee/ci/introduction/index.html

1. Pushing local commits to the remote branch on Gitlab will trigger the project's CI/CD pipeline

2. Autorun (serial or parallel) scripts

   • Build and test the application
   • View the modification in the application and check whether it is the same as running locally

3. Works as expected after implementing

   • Review and approve code
   • Merge the branch, and GitLab CI/CD will automatically deploy the changes to production

CI is mainly triggered when the code is submitted or merged, and is responsible for checking some basic rules. If the check fails, then roll back or modify the code before submitting or merging to reduce code risk;

CD is mainly triggered manually and automatically. On the basis of CI, it is also responsible for functional inspection. If the function meets the acceptance criteria, it can be delivered or deployed.

What GitLab offers at each stage of the DevOps lifecycle:

Pipelines: pipeline

Jobs

That is, tasks define what to do, such as compiling and testing code;
Jobs are executed by Runners, and if there are enough concurrent Runners, Jobs of the same Stage can be executed in parallel

Stage

That is, the stage, which defines when to execute Jobs, for example: enter the stage of running tests after the stage of compiling code

Generally, the Pipeline contains four stages (stages), which are executed in the following order:

• A build phase, including a compile job;
• A test (test) stage, including two jobs of test1 and test2;
• A staging (pre-release) stage, including a deploy to stage job;
• A production (production) phase, including a deploy-to-prod job.

.gitlab-ci.yml

example

stages:
  - build
  - test

build-code-job:
  stage: build
  script:
    - echo "Check the ruby version, then build some Ruby project files:"
    - ruby -v
    - rake

test-code-job1:
  stage: test
  script:
    - echo "If the files are built successfully, test some files with one command:"
    - rake test1

test-code-job2:
  stage: test
  script:
    - echo "If the files are built successfully, test other files with a different command:"
    - rake test2

Use mode 1: official website gitlab + local gitlab runner

Directly use the GitLab website https://gitlab.com/ instead of deploying GitLab locally. GitLab provides a hosting service to create private or public code warehouses and use its CI/CD functions for free.

Use mode 2: docker gitlab + docker gitlab runner

Local deployment of gitlab and gitlab runner can be completely independently managed, suitable for internal companies