The reason for doing this is that the company is in the rapid development stage, and the front-end code is gradually changing from the original KO and jquery to the present React. Therefore, it is necessary to package a version separately and then merge it manually. Taking this as an opportunity, I started to integrate front-end resources and build an automated build process in line with the company’s existing business scenarios.

Main tools used: Gitlab, Jenkins, Sonarqube

Main modules: task management, branch management, Jenkins workflow, quality inspection, resource release.

  • 1. Task management

Before speaking task management I mention our company code management process, because it determines the starting point of the task management, our company’s similar to gitflow code management, but also made some adjustment on this process to adapt to the present situation of the company, so every time before release we create a corresponding branch release version, So that developers can merge their feature codes into the current branch (see the picture below), so the main function of task management module is to manage the direction of release. We will provide release creation, temporarily called task, and associate task with Jenkins, GitLab and operation and maintenance release system. This is what the task management module does.

  • 2. Branch management

Here you may have a question, branch management is not gitLab? There are ancillary tools such as sourceTree, Tower, etc. In fact, GitLab has many powerful functions that need to be customized. Such as
  • I mentioned above that each release creates a new release branch, and usually we create a new branch from the master. One thing to note here (if the branch name is A) is that in order to keep the current branch code from being polluted by other branches, it is usually protected. If we set it manually in GitLab, it will not be automatic, contrary to our title. At this point we can do this by calling the GitLab API.
  • For example, the feature submits the code to release via merge Request, which is then handled by the manager. The specific processing results will be associated with our tasks via Webhooks. This is actually part of branch management

In fact, we also provide branch creation and deletion, providing some real-time statistics, so that developers can do all their work in one place.

  • 3. Jenkins workflow

The build service automatically calls the Jenkins API after the branch is created to complete the job creation. The Jenkins API is a bit of a mockery. The accepted parameters are ALL XML, which reminds me of the scene of developing wechat public account 😂 in the early years. Focus on the following points when creating a job (the node names in the XML are in parentheses)
1. Build branch (Hudson. Plugins. Git. BranchSpec) 2. Gitlab certificate id (credentialsId). 3. Build scripts (command)
Copy the code
Let’s talk about the build script, which mainly uses shell to achieve functions including resource acquisition, code verification (including esLint and other libraries validity verification, you can determine the specific business), Webpack packaging, dist submission to the repository (release), message notification. The specific code will not be posted

  • 4. Quality testing

I’ll put this one in the back with the check

  • 5. Resource release

The publishing system here is set up by our company, there is no more explanation, the main thing is to release packaged resources to the online.

Above my simple do each module in this paper, in fact most of the functionality is running in our self-built service, as a tool to help developers to simplify the process, we also want to consider the feelings of users, so we also provide the management side, show task time axis, build status, code quality index, and so on.

With the growth of the company, the increase of the number of team members brought a lot of high concurrency, but easy to ignore the problem, take the release process for example, from the initial development -> test -> online three steps of operation derived from development -> test -> gray -> online four steps. It seems that there is no problem. With the business fragmentation and microservice, the step from gray scale to online has drawbacks. Developers cannot control the synchronization between gray scale and online, as well as the synchronization between brands. As a result, every release day, we had to stay up all night to verify that the test environment, the grayscale environment, was correct.

Later, we tried to remove the gray scale and only keep the test and online version, but the online version will keep multiple versions, and the flow will be switched after the latest version passes the verification. This ensures efficient publishing and provides a good way to roll back. But this process forces us to once again comb through the front-end automation process and think about how to adapt.

One day in 2019, a few of us came back to the “dark Room” to discuss how to optimize the front-end build process. Multiple releases presented us with several challenges

  • Release branch management
  • When synchronizing code, how to ensure that the latest release branch contains all pre-released features
  • Should the version number be used instead of the previous way of naming tasks, etc

We made the following adjustments: all branch creation permissions were transferred to Manager, branch information was recorded, and validity checks were added when feature submitted merge Request to Release/Develop to verify whether master and component library versions were synchronized. During the construction of release, the validity check of appeal was added and the judgment of different task states of the same project was associated to ensure that release included all pre-release functions. Meanwhile, all verification failure results will be notified to Manager/Developer in real time.

Let’s talk about what quality checks we do in addition to checking branches.

  • The first thing we did was run ESLint and TSLint in Jenkins to review the code specification
  #eslint
  {
    cp -v -r /Users/android/pc/eslint/eslintrc.js /Users/android/.jenkins/workspace/The $1/.eslintrc_copy.js
    node ./node_modules/eslint/bin/eslint.js -c .eslintrc_copy.js --ext .jsx,.js,.ts,.tsx src --ignore-path .eslintignore
  } || {
    send $2 A $5 'fail' The $1 'ESLint validation failed' 'eslint'
    exit1}Copy the code
Reports are also generated
  • Secondly, we conducted project quality audit through Sonarqube, which was also configured in Jenkins

The results will be displayed in the Sonarqube service for you to view. Here’s a quick note about Sonarqube. As an open source tool, sonarqube does a really nice jobsonarqube

  • Next is the inspection of some business, here is not to explain.

To summarize, we connect GitLab and Jenkins by building a service and provide a management side to handle tasks in a unified manner.

  • As a developer, I only focus on my own development tasks, code quality, etc., and get rid of the previous situation of participating in the whole process.
  • As a project manager, simplify the release process, eliminate the need for manual packaging, and focus on code quality and business implementation.
  • As a build service, anything I can solve should not be handled by developers or managers

And finally I’m going to share with you a little bit of my own pit

  • 1. How to obtain the corresponding XML when Jenkins creates the task?

    Answer: visit http://localhost:8080/jenkins task name/config. The XML you will understand, if you want to build good Jenkins.

  • 2. What are the Jenkins apis and how to use them?

    A: Node-Jenkins-API is recommended

  • 3. What should be paid attention to when using gitLab API?

    A: First you need to confirm your gitLab version, and then you need to confirm whether you are calling the V3 or V4 API. There is a difference between the two. Then you need to pay attention to gitLab authentication. It is not difficult to create a Private token and configure it in your header