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)