GitLab CI/CD for Front-end engineering

In the process of this project, I often do function between branches – test branch – deployment code merge work, although our team has a reasonable Git Flow, Commit the specification, but can’t ensure that each developer in each time you submit all strictly abide by, and submit time nodes in complex branch, under the condition of uncertainty, Conflicts occur when merging branches, and conflict management seems inevitable, with a significant impact on productivity throughout the development lifecycle.

One aspect of “engineering” is production efficiency, also known as “automation”. Any simple mechanical work that is repeated more than twice should be handed over to the machine. This is the process of “automation” in front-end engineering. Any team that needs to deliver applications frequently wants a tool, a way to deal with integration hell and mechanized deployment.

CI/CD profile

CI

Continuous Integration. The action of integration refers to the process of merging code during software development, while continuous integration refers to the automated process we need to automate — building, testing, and merging code into a code repository as developers submit new code.

¹

CD

CD has two meanings: Continuous Delivery and Continuous Deployment. Continuous delivery refers to the completion of application, integration and build for the team or the business requirements, automatic to deploy applications to the production environment, can deploy to the prospective production environment means that can be directly deployed to the formal production environment, so the continuous delivery means any code changes can deploy in any desired deployment, said a kind of ability.

Continuous deployment, on the other hand, is the practice, the final action, of automatically putting changes into production after passing through all the previous phases. Different teams have certain requirements for continuous delivery and deployment. For example, our company requires us to deploy to a quasi-production environment for further testing before deploying to production.

GitLab CI/CD practice

CI/CD is a built-in tool for GitLab and is ready to use without the need for third-party tools. GitLab CI/CD automatically executes scripts using GitLab Runner based on the specific YAML files created by the user. The scripts in the files are the operations we need to perform, such as adding dependencies, building, unit testing, and so on.

Configuration GitLab Runner

The YAML file that stores the script is the key, but first you need a tool to execute the script, GitLab Runner. Every project to implement CI/CD must specify a specific Runner, Runner is a terminal like tool written in Go language. Can run in Linux, Docker, maocOS, and many more environments, and can choose to configure three different types of Runner:

• Specific Runners: Project-specific Runners for projects that have Specific requirements, such as the need to perform deployment jobs
• Shared Runners: Runners installed and registered by GitLab administrators for all projects
• Group Runners: Also installed by GitLab administrators, except that specific Runners can be assigned to specific groups

Because continuous deployment is required, and the target server for deployment needs to communicate with the repository in GitLab to meet the “need to perform Specific Runners” requirements, create a Specific Runners first. Here, take the cloud server (Ubuntu 18.04.5) where the Vue project is to be deployed as an example. There are two steps: installation and registration. The Runner to be installed is registered and bound with GitLab to enable it to communicate through API:

1. Add the official GitLab repository

$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
Copy the code

2. Install GitLab Runner

$ export GITLAB_RUNNER_DISABLE_SKEL=true; sudo -E apt-get install gitlab-runner
Copy the code

3. Obtain the URL and token

Go to the Setting ➡️ CI/CD page for the GitLab project to add CI/CD (provided you have Maintainer permissions for the project), expand the Runners panel, Find the GitLab URL and token at Specific Runners.

3. The registered Runner

Run the $sudo Gitlab-Runner Register in Ubuntu and enter the Gitlab URL, Token, description, tag, performer (shell in this case) 2 as instructed.

Once registered, you can see the Specific Runner that has been successfully bound under the Runners panel:

After the Runner is replaced, run the $sudo gitlab-runner restart command to restart the Runner to take effect.

Writing a script file

The.gitlab-ci.yml file needs to be manually created in the project root directory. The configuration in this YAML file is called gitlab CI/CD Pipeline. GitLab will first execute the corresponding Jobs on Runner according to the contents in the pipeline. Jobs is the basic unit in the.gitlab-ci.yml file, which defines the conditions under which an operation is performed and the specific contents of the operation in script clauses, such as:

stage:          Declare the phases explicitly and specify the order of execution
  - job1
  - .

job1:           # Custom Job name
  stage: test   The current Job stage
  script:       # Shell script executed by Runner
    - echo "Hello, Zander!"
Copy the code

Stage determines the execution order of each Job. Jobs at the same stage are run in parallel, and Jobs at different stages are executed in the written order. If the previous Job fails, the Job is submitted as failed and subsequent Jobs are not executed. See Job Keywords for more parameters than stages and scripts that are available within a Job.

Create a new.gitlab-ci.yml file in the project root (preferably in the local workspace rather than online, since the pipeline will run directly after submitting the change push locally to see the effect) and write the script:

stages: 
  - build
  - deploy

build_site:
  stage: build
  script:
    # Print content
    - echo "Start build"
    # install dependencies
    - rm -fr ./node_modules && npm install --registry=https://registry.npm.taobao.org
    # Package build
    - npm run build
    - echo "Build done"
  only: 
    - master              Execute the Job only if the master branch code changes
  tags:
    - test                # select tag for Runner
  artifacts:
    - expire_in: 1 week
    - paths:
      - dist/

deploy_site:
  stage: deploy
  script:
    - echo "Start deploy"
    Copy the built dist directory to the NGINX mount directory
    - rm -rf /var/www/cicd-test
    - cp -r ./dist /var/www/cicd-test
  only:
    - master
  dependencies:
    - build_site          # accept the product passed by build_site
  tags:
    - test
Copy the code

The idea is that the build phase should perform packaging to generate a dist directory, and then mount it to the NGINX directory in the following deploy phase to complete the project deployment. But the pipeline is set up so that every Job starts with a.gitignore file in the repository and automatically deletes the files declared in it — the dist directory is gone by the time the deploy phase starts.

Therefore, another parameter artifacts needs to be used in the script file, which I translate to “artifacts,” indicating that the specified file or directory can be saved to GitLab after the current Job succeeds/fails, which can be used in the following Jobs, along with an expiration time for the artifacts. Dependencies are used to receive previous products in the current Job. By default, all products in the previous Jobs are passed forward. If set to empty array, no products are received.

/var/ WWW directory is assigned to root user by default, while Runner runtime user is gitlab-runner.

$ chown -hR gitlab-runner:gitlab-runner /var/www/
Copy the code

After pushing changes, details about pipes and Jobs can be viewed in the CI/CD panel of your project:

Click on the individual Job to see the detailed execution. The UI operations are not described much. When all stages in the pipeline are executed, the Vue project is successfully deployed:

It is also worth mentioning that when I copy the new dist directory to the NGINX mount directory, I first use the cp command with the -fr parameter, which means copy and.. Cover.. The original catalog. The problem was that the application content could not be updated in time after the completion of each pipeline operation, which was later found to be caused by the underlying principle of cp command. Simply speaking, CP-FR could not guarantee the safe replacement of original files, so rm + cp command was used, and everything was normal 🎉.

References & Resources

1. GitLab CI/CD | GitLab
2. What is CI/CD? How to understand continuous integration, continuous delivery and continuous deployment | Red Hat
3. To a product manager about, what is the continuous delivery and the conversation | acejoy
4. How to auto deploy a Vue application using GitLab CI/CD on Ubuntu 18.04 | Michael Okoh