This paper mainly introduces the front-end automation deployment scheme summarized in my work, from branch management to CI/CD, mainly describes the process and ideas, without details.

Main pain points (parallel pain) :

  • 1. The front-end is independently developed without a unified construction environment
  • 2. Currently, the operation system adopts single project management, which needs to support the operation functions of multiple businesses. It is inevitable to develop and test multiple businesses in parallel (inconsistent online time)
  • 3. Code clutter from multiplayer development

Solution idea:

Aiming at the core problem of multi-service parallel development test, the multi-branch code management model is introduced to support the multi-branch parallel integration deployment and solve the problem of no unified construction environment synchronously.

It mainly describes the following parts:

  • 1. Front-end branch management model
  • 2. CI/CD with multiple branches and multiple environments
  • 3. Automatic code generation

First, front-end branch management model

Git workflow model has many kinds, such as centralized, gitflow, functional branch workflow, etc., can be defined according to the way suitable for the current working mode and scene. For the problems we are facing, workflow is as follows:

Note :(XXX below is any name, do not repeat)

Master: a branch used for pre-Pro and Pro environment releases; You cannot commit code directly

Release/XXX: as the main branch of the current iteration, the owner or master will cut out the latest branch from the master branch at the beginning of the current iteration. XXX has no fixed name and can be decided according to needs. Do not submit code directly; This branch serves as the branch for validation of this iteration’s functionality;

Feature/XXX: As a branch of a certain function development, the developer should cut off from the corresponding release/ XXX branch by himself, and complete function development, commissioning, self-testing, static code detection, unit testing, etc., on this development branch, and submit merge Request to Release/XXX after completion. The main purpose is to isolate the developer’s development content to facilitate code review;

Feature /bugxxx: features similar to feature/ XXX, listed separately only to show that bug fixes during the test phase were made from release/ XXX splicing

Release /hotfix: Merge Request to the master after test and verification. Release /hotfix: Merge Request to the Master after test and verification

It can be seen that the above workflow mode is actually a combination of centralized and Gitflow mode. The release/ XXX branch is taken as the main branch of iterative development test to solve the problem of multi-business parallel development test. The timing of release/ XXX merging into master is controllable. It also brings room for variations in the uncertainty of the launch time of functional iterations

The following are ways or ideas to solve some possible problems of this model (welcome to supplement and exchange) :

1. Two release/ XXX branches at the same time, changes involving the same files, common modules, methods, etc

Solution: 1) Experienced developers identify this situation and negotiate adjustment to avoid mutual influence; 2) The later release/ XXX branch will rebase the content of the first release/ XXX back to the branch, and resolve conflicts and regression verification

2. Normal automation processes will automatically release the latest content for the Release/XXX branch, which may affect the functionality being tested for that branch

Solution: 1) Specify the timing of code merger, such as the owner or master or other people regularly merge after work or before work, to reduce the impact on the function under test; 2) Add a stable branch dedicated to testing, which is maintained by testers who decide when to merge the release/ XXX branch into the stable branch. In this way, automatic deployment strategy needs to be adjusted

3. In addition, we welcome additional exchanges

The above branch model is the basis to support the simultaneous development and testing of multiple businesses, and the corresponding CI/CD is needed to ensure its feasibility

TODO: Detailed explanation of various branch models

Ii. CI/CD with multiple branches and multiple environments

Common CI/CD schemes are 1, gitlabCI/CD; 2. Use Jenkins to customize release steps; 3. Github CI/CD; 4. Various cloud deployment solutions, such as Coding, Gitee, etc

Specific implementation can be adopted: 1. Compile, build, publish static code to the target machine; 2. Compile and build, package for Docker image and deploy docker, etc.; Online deployment generally involves CDN, so the corresponding CI/CD process should be adjusted accordingly for the release of CDN.

The following is an example of docker Image deployment based on Gitlab CI/CD:

1. Customize the build process through the Gitlab-ci.yml file (sensitive information and some details are ignored, only used to illustrate the process)

stages: - test - build - ship - deploy cache: untracked: true job_release_test: stage: test tags: - Frontend Environment: name: TEST script: - Execute code check code only: - /^release\/.*$/ job_release_build: stage: build tags: - frontend environment: name: TEST script: - Dependent installation, code build command only: - /^release\/.*$/ job_release_ship: stage: ship tags: - frontend Environment: name: TEST script: - Send build results to remote docker repositories only: - /^release\/.*$/ job_release_deploy: stage: Deploy tags: - frontend environment: name: TEST script: - Deploy start docker only: - /^release\/.*$/ job_master_build: stage: Build image: Base image path tags: - frontend environment: name: DEMO script: - Dependent installation and code building commands only: -master job_master_ship: Stage: ship tags: - frontend environment: name: DEMO script: - Send build results to remote Docker image repository only: - master job_master_deploy: Stage: deploy tags: - frontend Environment: name: DEMO script: - Deploy start docker only: - masterCopy the code

It can be seen from the above that through the definition of the only field in each stage, release/ XXX branches are allowed to independently execute CI/CD. In the deployment stage, each release/ XXX branch is guaranteed to be independently deployed and accessible, namely, the basic demands of multi-branch parallel development and testing are fulfilled.

There are many details that need operation and maintenance cooperation to handle, such as how to make different release/ XXX branches deployed separately and accessible by separate domain names or paths? How should the docker image be arranged? What should be done if the vue uses the history mode and needs to redirect the access path? The same set of code deployed in different environments (test, demo, online) access the back-end interface address is different, how to facilitate the handling? And so on… These issues are detailed and vary from deployment to deployment. Please leave a comment

Three, automatic code generation

This section is a bit long and will be updated for the full article…

Reference article:

Github.com/xirong/my-g…

Juejin. Cn/post / 684490…