preface

Before we begin, let’s quote the official explanation of DevOps so that the confused reader can have a simple idea in mind

DevOps (a portman of Development and Operations) is a culture, movement, or practice that values communication and cooperation between “software developers (Dev)” and “IT Operations technicians (Ops).” Build, test, and release software faster, more frequently, and more reliably by automating the software delivery and architecture change processes

Well, according to the convention, this paper is still in this order: what is the status quo -> what are the problems of the status quo -> how to solve -> what are the solutions -> comparison of solutions -> implementation details. Cut the idle chatter and get straight to the point

What is the status quo

First, the environment:

From front and back end development to launch, different enterprises have different names and even finer divisions for different environments. But generally it can be divided into three environments, and I’ll name them as follows

  1. Localhost: localhost:8080: clone the project git to your own laptop or development machine. At this point, the environment is primarily object-oriented for developers.
  2. Dev: test environment. The local service iteration is completed and delivered to the test for functional testing. The test is performed on a secondary domain like dev.company.com. The object orientation of the environment at this point is primarily the tester. (Just a test domain name environment)
  3. Prod: indicates the production environment, which is used by users on the line. The company.com address is similar. The object orientation of the environment is primarily the user.
Talk about the development process:
  1. The feature branch corresponds to the local environment
  2. The Develop branch corresponds to the test environment
  3. The Master branch corresponds to the production environment

At present, the department’s front-end project is based on Jenkins’ CICD. If you want to know about Jenkins’ use and principle, you can refer to the previous article. After the development, the developer submits mergeRequest to the Develop branch, triggering Jenkins’ automatic build process and automatically deploying to the test environment. In this case, the test teacher can execute the test case, and the operation is similar to that of launching the test case. All you need to do is merge the develop branch code that passed the test into the master, and then the master tags the test, selects the tag on Jenkins, and triggers the automatic deployment of the test case to the online environment. If you want to roll back, simply select the previous version of the tag and rebuild it

(Note: Select tag Build online, need to use Jenkins Plugin Build With Parameters Plugin)

What’s wrong with the status quo

Based on the above situation, it seems that there is no problem, and it is also true. For a small team, there is no problem with the business with few iterations. However, if not, the problem will be gradually exposed, such as:

  1. When multiple features are developed at the same time, the Develop branch gets crowded and features end up on the same page because there’s no way to keep a clean Develop branch all the time, which is at odds with the agile, iterative approach that we’re now promoting. (Most important question)
  2. If a bug appears in develop tests, the devlop branch needs to be merged into the Develop branch each time it is fixed. The most important thing is that, even after testing, devlop cannot be merged into the Master branch if there are other features that Develop is testing
  3. Multi-functional simultaneous development, both submitting codes to the test environment, easy to affect each other, for example, I was developing function A and was in the testing stage, and another person also submitted codes to the test environment, but made a mistake, at this time, my corresponding test teacher would call me

In fact, the above three points are simply one: single test branch and test environment cannot meet the requirements of multi-function simultaneous development, but not simultaneous online

At this point, feature-based branches are in urgent need of a set of independently testable environment. There is another important question about going online: Is a rollback operation, it is not hard to find, the rollback operation is a version of the tag on the need to choose, to choose building to work, according to the current front build time of the project, build time quick, 30 s, slow is to say, if launched out of the question, really want to roll back, in this period of build time, what was good, can only touch your hair

In fact, whether large or small enterprises, multi-branch front-end test environment has basically become the standard, that is, each functional branch is equipped with a corresponding test environment.

How to solve (Knowledge principle)

For the first type of problem, the purpose is simple: to support the multi-branch test environment on the basis of the current build, that is, for now:

Develop: test environment dev.company.com

Change it to something like this:

  • Urea Test environment featureA.dev.company.com
  • FeatureB test environment featureB.dev.company.com
  • The lateral branch featureTest environment feature.dev.company.com

This allows different functional iterations to run at their own pace. How

Take a server to illustrate:

Will different branch of the build results on branch first name in the corresponding folder, if done here: / var/WWW/HTML/project/featureA is the second most important nginx do a generic domain name resolution to go, probably as follows:

So you should be able to is arguably a similar featureA.project1.company.com domain access different test branch

For the second question, the goal is much simpler, that is, when the rollback, do not perform the build, to implement the rollback immediately, what to do? If you want to roll back the previous version, keep the previous 2 build results, of course, there must be a folder name rule, otherwise how to know which version to roll back, for example, you can simply follow the following

Each project corresponds to an ID, the VUe_test project id is 2, followed by the release record, followed by the release timestamp. The database records the current version of the project, rolls back, finds the folder of the previous version, and then replaces the current service directory

Note: The directory structure above does not take into account multiple branches, so the folder name should also have flags for branches, such as 2_featureA_3_20211122

What are the options

Okay, so once you’ve got it in your head, do you want to do it right away? No! No! No! “, some people will say that another KPI project, another wheel, cannot be achieved, even harder to explain, haha. Spug, CoDO, BigOPS, Walle, etc. Some of them also provide dependencies between projects. For example, project A depends on project B and project C. If project A is launched, project B and project C should be launched first. Before, it was all artificial memory, so you could make mistakes, but now with this dependency, you just focus on the top item, and it’s perfect

Comparison of various schemes

Here is not to repeat, a lot of online, you can search by yourself, choose suitable for their current company business can be, the author stood in the best, but the most suitable point of view, selected SPUG

Scheme implementation details

The SPUG project provides two modes of operation, one is code operation and the other is Docker container operation. The official container image provided does not have node environment, so it is not friendly to the front-end project. I build new ones and upload them to docker Hub by myself, and can directly use Delonglimin/SPug if necessary

Since WE choose SPUG, if we do not understand its implementation method, we will have to take it by ourselves if there is a problem. Therefore, we must first be familiar with the key technology path of this project, and if there are bugs or requirements, we must support it. Let’s take a look at some of the key technical points. Let’s start with an overview of spUG’s business flow. (Most DevOps are like that.)

The following diagram mainly explains how the front end shows the build status through xterm and manipulates the server (also known as the Webshell)

Other:

  1. The entire service flow relies on the SSH protocol, which is commonly referred to as secret-free operation
  2. The project involves three confusing concepts that can be searched and interpreted: Asgi, Wsgi, and CGI