GitLab CI/CD is a tool built into GitLab for software development through a continuous approach:

  • Continuous Integration (CI) : Continuous Integration
  • Continuous Delivery (CD) : Continuous Delivery
  • Continuous Deployment (CD) : Continuous Deployment

Continuous integration works by pushing small blocks of code into a hosted application repository in Git, and each time you push, you run a series of scripts to build, test, and validate the code changes before merging them into the main branch.

Continuous delivery and deployment amounts to a further CI, allowing the application to be deployed to production each time it is pushed to the default branch of the repository.

These methods enable the detection of bugs and errors early in the development cycle to ensure that all code deployed into production meets the coding standards established for the application.

Gitlab CI/CD is configured with a file named.gitlab-ci.yml, which is located at the root of the repository. The scripts specified in the file are executed by GitLab Runner.

GitLab CI/CD is introduced

The continuous approach to software development is based on automated script execution to minimize the chance of introducing errors when developing applications. They require little or no human intervention from developing new code to deploying it.

It involves constantly building, testing, and deploying code changes in each small iteration, thereby reducing the chance of developing new code based on previous releases that are already buggy or failing.

Continuous Integration is an application whose code is stored in GitLab’s Git repository. Developers push code changes several times a day. For each push to the repository, you can create a set of scripts to automatically build and test your application, reducing the chance of introducing errors into the application. This practice is called continuous integration, and it automatically builds and tests continuously for every change that is submitted to the application (or even to the development branch) to ensure that the introduced change passes all the tests, guidelines, and code compliance standards that you have established for the application.

Continuous Delivery is a step beyond Continuous Integration. Not only is the application built and tested with each code change that is pushed to the code base, but even though the deployment is triggered manually, it can be deployed continuously as an additional step. This approach ensures that the code is checked automatically, but human intervention is required to trigger the change manually from the policy to fail.

Continuous Deployment, which is similar to Continuous delivery, except that you don’t need to manually deploy it, but instead set it up for automatic Deployment. Deploy your application with no human intervention at all.

How does GITLAB CI/CD work

To use GitLab CI/CD, you need an application code base hosted on GitLab and specify build, test, and deploy scripts in the.gitlab-ci.yml file in the root directory.

In this file, you can define the script to run, define the included dependencies, select the commands to run sequentially and the commands to run in parallel, define where to deploy the application, and specify whether you want to automatically run the script or manually trigger the script.

To visualize the process, assume that all scripts added to the configuration file are the same commands that run on the computer’s terminals.

Once you have added.gitlab-ci.yml to the repository, GitLab will detect the file and run your script using a tool called GitLab Runner. The tool operates similarly to a terminal.

These scripts are grouped into JOBS, which together form a PIPELINE. A simple.gitlab-ci.yml file might look like this:

before_script:   
  - apt-get install rubygems ruby-dev -y   
  
run-test:   
  script:   
    - ruby --version 6

The before_script property installs dependencies for your application before running anything, and a job called run-test prints the Ruby version of the current system. Together, they form a Pipeline that is triggered every time it is pushed to any branch of the warehouse.

Gitlab CI/CD can not only execute the job you set, but also display what happens during execution, as you can see from the terminal:

Create policies for your application, and GitLab will run the Pipeline based on your definitions. Your pipe status will also be displayed by GitLab:

Finally, if there are any problems, you can easily roll back all the changes:

Basic CI/CD workflow

Once you push a commit to a branch of the remote repository, the CI/CD pipeline you set up for the project will be triggered. Gitlab CI/CD does this by:

  • Run automation script (serial or parallel) code Review and obtain approval
  • Build and test your application
  • Preview the changes for each merge request using Review Apps, as you can see on your machine
  • Code Review and approval
  • Merge the Feature branch to the default branch and automatically deploy this change to the production environment
  • If something goes wrong, you can easily roll back

All the steps are visualized through the GitLab UI.

In-depth understanding of CI/CD basic workflow

If we dig into the basic workflow, we can see the functionality available in GitLab at each stage of the DevOps life cycle, as shown in the figure below:

图片

Verify:

  • Automatically build and test your application through continuous integration
  • Analyze the Quality of your source Code using GITLAB Code Quality
  • Browser Performance Testing was used to determine the impact of code changes on Performance
  • Perform a range of tests, such as Container Scanning, Dependency Scanning, and JUnit Tests
  • Deploy the changes with Review Apps to preview the application changes on each branch

Package:

  • Use Container Registry to store Docker images
  • Store NPM packages with NPM Registry
  • Store Maven artifacts in the Maven Repository
  • Use Conan Repository to store Conan packages

Release:

  • Continuous deployment automatically deploys your application to the production environment
  • Continuous delivery, manual click to deploy your application to production
  • Deploy static Web sites with GitLab Pages
  • Deploy functionality to only one Pod and give a certain percentage of the user base access to the temporarily deployed functionality through Canary Deployments (PS: grayscale release)
  • Deploy features after Feature Flags
  • Use GitLab Releases to add a release note to any Git tag
  • Use Deploy Boards to view the current health and status of each CI environment running on Kubernetes
  • Use Auto Deploy to Deploy the application to the production environment in the Kubernetes cluster

Using GITLAB CI/CD, you can also:

  • Easily set the entire life cycle of your application with Auto DevOps
  • Deploy the application to a different environment
  • Install your own Gitlab Runner
  • Schedule pipelines
  • Use Security Test Reports to check for application vulnerabilities

GITLAB CI/CD Quick Start

The.gitlab-ci.yml file tells the Gitlab Runner what to do. A simple pipeline usually consists of three phases: Build, Test, Deploy, Pipelines in CI/CD > page

Create a.gitlab-ci.yml file

Tell CI what to do with your project by configuring the.gitlab-ci.yml file. It is located in the root directory of the repository.

As soon as the repository receives any push, GitLab will immediately look for the.gitlab-ci.yml file and start the job on the Runner based on the contents of the file.

Here is an example Ruby project configuration:

Image: "ruby: 2.5" before_script: - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs - ruby -v - which ruby - gem install bundler --no-document - bundle install --jobs $(nproc) "${FLAGS[@]}" rspec: script: - bundle exec rspec rubocop: script: - bundle exec rubocop

In the example above, the two jobs defined, RSpec and RuboCop, execute the before_script commands before each job starts execution.

Push.gitlab-ci.yml to gitlab
git add .gitlab-ci.yml  
git commit -m "Add .gitlab-ci.yml"   
git push origin master
Configure a Runner

In GitLab, the Runner runs the job you defined in.gitlab-ci.yml.

A Runner can be a virtual machine, a physical machine, a Docker container, or a cluster of containers.

The communication between GitLab and Runner is via API, so all that is required is that the Runner’s machine has a network and has access to the GitLab server.

You can go to Settings Ci /CD to see if you already have Runner associated with your project. Setting Runner is simple and straightforward.

View the status of Pipeline and Jobs

After successfully configuring Runner, you should be able to see the status of your most recent submission.

To view all jobs, you can go to the Commands Jobs page.

By clicking on the status of the job, you can see the log of how the job was run.

To review:

  • First, define the.gitlab-ci.yml file. In this file, you define the job and the command to execute
  • Next, push the file to the remote repository
  • Finally, configure Runner to run Job

Auto DevOps

Auto DevOps provides a predefined CI/CD configuration that allows you to automatically detect, build, test, deploy, and monitor applications. With CI/CD best practices and tools, Auto DevOps aims to simplify the setup and execution of a mature and modern software development life cycle.

With Auto DevOps, setting up the software development process is made easier because each project can complete the entire workflow from validation to monitoring with minimal configuration. Just push your code and GitLab will take care of everything else. This makes it easier to start new projects and keeps the way applications are set up across the company consistent.

The following example shows how to deploy a project hosted on GitLab.com to Google Kubernetes Engine using Auto DevOps.

The example uses GitLab’s native Kubernetes integration, so there is no need to manually create a Kubernetes cluster separately.

This example creates and deploys an application created from a GitLab template.

Create a project from the GitLab template

Before you can create a Kubernetes cluster and connect it to the GitLab project, you need a Google Cloud Platform account.

Let’s use GitLab’s project template to create a new project.

Give the project a name and make sure it’s public.

Create a Kubernetes cluster from the GitLab template

Click the Add Kubernetes Cluster button, or the Operations > Kubernetes.

Install Helm, Ingress and Prometheus.

Enable Auto DevOps (optional)

Auto DevOps is enabled by default.

Navigation bar Settings > CI/CD > Auto DevOps.

Check Default to Auto DevOps Pipeline.

Finally, select the deployment policy.

Once you have completed all the above operations, a new Pipeline will be created automatically. To view Pipelines, go to CI/CD > Pipelines.

The deployment of application

By now, you should see the pipe running, but what exactly is it running?

The pipeline is divided into four stages, and we can see how many jobs are running in each stage, as shown in the figure below:

Build -> Test -> Deployment -> Performance Test

Now that the application has been successfully deployed, let’s view it through a browser.

First, navigate to Operations > Environments.

In Environments, you can see the details of the deployed application. There are three buttons on the far right, let’s look at them one by one:

The first icon opens the URL of the application deployed in the production environment. This is a very simple page, but the important thing is that it works!

Next to the second is an icon with a small image where Prometheus will collect data about the Kubernetes cluster and how the application affects it (in terms of memory/CPU usage, latency, and so on).

The third icon is the Web terminal, which opens a terminal session in the container where the application is running.

Examples

Deploy a Spring Boot application using GitLab CI/CD.

Example. Gitlab – ci. Yml

image: java:8  
   
 stages:  
   - build  
   - deploy  
   
 before_script:  
   - chmod +x mvnw  
   
 build:  
   stage: build  
   script: ./mvnw package  
   artifacts:  
     paths:  
       - target/demo-0.0.1-SNAPSHOT.jar  
   
 production:  
   stage: deploy  
   script:  
   - curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx  
   - ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io  
   - ./cf push  
   only:  
   - master

Original link:https://www.cnblogs.com/cjsbl…