Git workflow

For a team of front-end, Git workflow is very important, not only is advantageous to the version control and rolled back, also can be done in terms of automated deployment of fine grained control, automated deployment in research before, I think you should first understand the workflow and for your team to customize a suitable scheme of the current epidemic of workflow is Git Flow, Adopt dual primary branches and other secondary branches as the basic flow

Definition and function of branches

The following is the branch management process customized by my current team

branch instructions Protected or not (direct push is not allowed)
master The master branch, which stores all code published in the production environment, with Git tags as version management is
develop The development branch, which stores all the code to be released to production no
feature/* Functional branches, with a single business function as the point of segmentation no
fix/* The functional repair branch, usually cut out by Develop and merged into Develop no
hotfix/* Hotfix branches, usually cut out by the master and merged into the master no
beta/* The test branch, combined with multiple business functions released to the test environment, and the sub-branch under beta as version management is
release/* The grey test branch is released to the grey test environment in combination with multiple business functions, and the sub-branch under Release is used as version management is

Having a Git workflow management system for your team is very important, so having a workflow solution is a prerequisite for automated deployment

Gitlab

The automated deployment in this paper is based on the automated CI/CD of Gitlab, so if you agree with and need this scheme, then the necessary condition is the private deployment of Gitlab. There are many schemes about the installation of Gitlab on the market, so this paper will not repeat them

Gitlab Runner

Gitlab Runner is a running program used by Gitlab to support CI/CD solutions. Our primary task is to successfully build our own Gitlab Runner on a server. The installation of Gitlab should not be on the same server as the Gitlab Runner program. In addition, the Gitlab Runner program occupies the CPU of the system

The installation

Download the corresponding version of Gitlab Runner

# Linux x86-64
wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# Linux x86
wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386

# Linux arm
wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm
Copy the code

Add executable permissions

chmod +x /usr/local/bin/gitlab-runner
Copy the code

Register a user for Gitlab Runner

useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
Copy the code

Perform the installation

gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
Copy the code

Add Runner program for Gitlab

In this step, we need to prepare several necessary information in advance, open the website of Gitlab deployed internally, enter the admin center interface, find the Runner menu in the overview, you will see the following information

You can also set a single Runner for a single group or a single project. The open address is in the Settings and CI/CD under the group. We also suggest that you build a unified Runner for the whole Gitlab, and then disable the Runner where it is not needed

Here we get the URL and Token we need to configure and execute

gitlab-runner register
Copy the code

Then you have the following information to fill in

Please enter the gitlab-ci coordinator URL # the 'URL' path just obtained
Please enter the gitlab-ci token for this runner # Just obtained 'Token' Token
Please enter the gitlab-ci description for this runner Create a brief description of your application
Please enter the gitlab-ci tags for this runner (comma separated) # Input multiple tags, tag is used to distinguish between multiple running tasks, use, as a separator
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell
# Select an executor for your Runner, here we chose shell, i.e. execute in the current environment, if you choose Docker or Kubernetes, you may need to configure the corresponding runtime environmentPlease enter the Docker image (eg. Ruby :2.1)# if you select the docker, so need to specify a docker running the default image, front-end team, running the default image should be node: the latest
Copy the code

If the registration is successful, the following message is displayed

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
Copy the code

Start Runner service

gitlab-runner start
Copy the code

If the following information is displayed on the Runner management page of the project, the Runner configuration is successful

Enable Gitlab CI

As mentioned above, we have successfully configured the Runner program for the project. How to trigger the Runner program to complete our automatic deployment needs to use the Gitlab CI file, the default file name of Gitlab is.gitlab-ci.yml. First, we should create such a file in the project

stages:
  - test

cache:
  paths:
    - node_modules/

test:
  stage: test
  tags:
    - vue # tags should be the Tag you specified in a Runner. If a Runner matches successfully, the task will be executed
  script:
    - npm install --no-optional
    - npm run lint
Copy the code

The test Runner

Push the project with.gitlab-ci.yml file to the server, if the file configuration is correct, it will start CI program to perform automatic check. The configuration of the above file is to let Runner program perform automatic code check, open the project panel, find ci /CD pipeline, and check the execution status of the task

A success status means that the submitted code of the current branch conforms to EsLint’s expected rules, and a failure means that the code has failed to be detected and the branch cannot be merged into the published branch. We usually perform code checks via the Test task to ensure that the code specification submitted online meets our expectations

Do their job

This paper brings a solution based on Gitlab Runner as automatic deployment. The definition file of Gitlab CI is just a simple example above. Automatic deployment requires us to define different tasks for their respective roles

  • A Guide to Automated Deployment for front-end Teams – Configuration (Not published)
  • A Guide to Automated Deployment for front-end Teams – Advanced (not released)