I. Concepts related to automated construction

1.1. What is automated testing?

Automated testing is the process of converting human-driven testing behavior into machine execution. Typically, after a test case is designed and reviewed, the tester performs the test step by step according to the procedures described in the test case to get a comparison of the actual results with the expected results. In this process, in order to save manpower, time or hardware resources, improve the efficiency of testing, it introduced the concept of automated testing.

In short, automated testing is the automatic completion of unit tests, which are a kind of build task of automated builds.

1.2. What is an automated build?

The so-called automatic construction is to make different construction tools cooperate with each other through the automatic scheduling of construction scripts, so that the computer can automatically complete the software construction operation.

Spreading pancake fruit is construction, aunt booth for you is artificial construction, machine booth for you is automatic construction.

A build represents a processing operation that has inputs and outputs. The input is the raw material and the output is produced by the operation of the build. The pancake is the build. In software development, the raw material of construction is program code, and the result of construction is software.

Different programming languages and different programming projects have different complexity of building operations. For example, in C language, the source code of C language is.c and.h files. There are two steps to build and generate executable programs:

  • First compile the source file into a.o or.obj object file
  • Then link the object file with the static library.lib file into an executable

Thus, the C language build process is two basic operations, namely compilation and linking.

C is a compiled program and can’t generate an executable program without building it. For the Web, our programming language is JS. JS is an interpreted language that doesn’t need to be compiled or linked and can run directly in a browser environment, but JS projects also need to be built.

1.3. What is continuous integration?

Continuous integration is a software development practice in which team development members integrate their work frequently, usually at least once a day per member, which means that multiple integrations may occur per day. Each integration is verified by an automated build (including compilation, release, and automated testing) to find integration errors as quickly as possible.

The continuous integration encyclopedia explains very well: baike.baidu.com/item/%E6%8C…

1.4. Five common types of build tasks for front-end projects

The following is a breakdown of common build tasks for front-end projects:

JavaScript does not have the compilation and link building tasks of C, but there are five types of building tasks, which are more and more complex than C, so it is often said that the complexity of front-end development software engineering is often greater than the complexity of algorithms and architectures. The build tasks of a front-end project are different from those of a back-end project. The dotted boxes indicate the common build tasks of a back-end project. For a back-end project, there are only two common build tasks.

Therefore, back-end projects are easier to build than front-end projects, such as node.js backend code that does not require compressed JS files for performance optimization.

1.5. Build-related commonalities in software development

Different programming languages, different types of projects to create, and different build tasks. The diversity of build tasks means that whether a manual build or an automated build is different.

This makes sense, for example, if you make a set of pancakes and a set of wedding banquet, the operation complexity will be different.

Therefore, it is necessary to make an abstraction, stripping out the differences between programming languages and different projects, and listing the common software development processes related to build. As shown in the figure below, a single column is the narrow sense of automated build, while the six columns from left to right add up to the broad sense of automated build.

1.6. Advantages of automated builds

  1. It is done automatically by computer and does not require human involvement, so it can effectively reduce errors and errors during construction and deployment

  2. Automated by computers, you can improve development efficiency, and the low cost of automated builds means you can build more frequently, so you can build on a daily basis, or as soon as the code changes, you can keep building

  3. Automated builds perform unit tests, which begin by modularizing the code to make it easier to maintain and refactor

  4. By automating unit testing in a build, software quality can be improved and bugs reduced

  5. By automating static code reviews in a build, project team members can make the code they write more compliant with coding specifications and more collaborative

1.7. Build process

We write software from scratch that runs on three different environments throughout the development lifecycle.

Same product code in a different environment configuration is different, corresponding to two kinds of patterns, such as: your girlfriend at home and in unit dress certainly is not the same, if I have to send you a wc), and different occasion requirement is different also, in the same way, the same function of the software product in a different environment it will build different models. As shown below:

The test environment needs to find bugs, so the code contains a lot of debugging information for easy debugging. The production environment has already found bugs, so you don’t need these debugging prints, it needs performance and simplicity. So it can be said that debug mode corresponds to the test environment (strictly speaking, the development environment does not correspond to any mode, it can be called debug mode), and release mode corresponds to the production environment.

1.7.1. Environmental differences

1.7.2. Differences between the two modes

Second, related tools for automated construction

Those who have played chicken know that after landing, they must first pick up guns, automatic rifles, submachine guns and so on. Only when they pick up weapons can they fight. Similarly, to complete automatic construction operations in automatic construction, they also need corresponding tools and software to support, which need three categories of software to support:

2.1. Version control system

Version control systems are the basis of automated builds and are often used in conjunction with continuous integration tools to complete automated builds. The main version control systems fall into the following two categories.

SVN is out of date. Git is now used.

2.2. Open source distributed version control system open source community

A git is not enough, when the team development often need to centralized remote warehouse code, then you need the git server, in the large Internet companies generally use gitlab to build their own server to store the private code, a small team or individual developers can use the free git server, generally, also known as open source community, Common open source communities are shown below.

2.3. Build task tools

In front-end project development, there are many construction tasks (five categories) and complex operations, so special construction task tools are needed. Common construction task tools are as follows. Front-end project construction tools can be grunt, gulp, webpack, etc. Node.js backend projects simply choose NPM (script scripts can also be written in NPM). The tool selection depends on the team.

Build scripts are often written in build task tools, which build patterns are assigned, and which task lists are to be executed under each build pattern.

Every build task usually requires configuration parameters, and there are three types of parameters:

  • Input parameters for the build operation
  • Where to put the result of the build operation, which is the output parameter
  • General parameters for the build operation

Take image compression as an example. The first parameter tells the build task which directory to put the image source file in, the second parameter tells the build task which directory to put the compressed image, and the third parameter tells the image compression ratio.

2.4. Continuous integration tools

A continuous integration tool should be called a continuous integration server precisely, because all automated build execution is done on a continuous integration server, and you have to have a server on which to work and build tasks.

Common continuous integration tools include the following:

Travis CI and Jenkins are most commonly used. Travis CI is integrated with Github and supports most major programming languages. Jenkins is open source, and many Internet companies build their own Jenkins servers internally to automate the build.

Iii. Actual combat (Gitbook Automatic Construction)

The actual results are shown below

Demo link: mr-jemp.github. IO /cjpbook/

3.1. Automated build tool selection

  • Version control system: Github
  • Build task tool of choice: NPM
  • Continuous integration tool of choice: Travis CI

3.2. Procedure

The first release needs to be manually built and released, and subsequent releases can be automated.

3.2.1. First Release Procedure (manual)

1, go to Github and create a new repository (add README file and.gitignore file, select MIT protocol)

2, clone repository, enter project directory, create gh-Pages branch (note that the branch name is specified, do not write, this branch is used for publishing)

3. Switch to the main branch (after October 1, 2020, Github changed the default branch for creating repositories to Main), create two chapter. Md files, and add a SUMMARY.

4. Prepare the content of the. Md file

5. Install gitbook CLI tool globally (need to use Taobao source), use gitbook -v command to check the version, gitbook 3.2.3 will be automatically installed (some versions will fail to be installed, my Node version 10.21.0 was successfully installed). Run the gitbook build command to generate the ebook

When it is installed, it is very slow, maybe more than ten minutes, Taobao source is still slow, the installation is completed as shown in the figure below

The installation is successful. Enter gitbook -v again to check whether the installation is successful

Then run the build command

After the build is successful, there is a _book directory in the project directory. This is where the build result is stored

Edit the.gitignore file, exclude the _book directory from the repository, and push the code to the main branch

At this point, the github repository main branch code is as follows

7. Switch to the GH-Pages branch, copy all files in _book directory to the root directory of the project, then delete _book directory (after deletion, our Git repository does not need to save an additional package code), commit the changes to this branch and push the changes to the remote branch. The process of pushing the remote repository is the process of publishing

After deleting the _book directory, the file will look like the picture below.

Push the changes to the remote gh-pages branch (git push –set-upstream origin gh-pages)

Github name + github. IO + repository name

Such as: XXX. Making. IO/cjpbook /

The published page looks like the following figure

3.2.2. Subsequent Release Steps (automatic)

If we want to add a new chapter, we need to do the following steps:

1. Switch to the main branch and create the ch03.md file

2. Edit the ch03.md file and modify the summary. md file

Increased after a chapter also need to do repetitive work, and then run gitbook build, then switch to the gh – pages branch will be newly generated file copy complete release action in the past, very trouble, if there is ten times add, we will perform the two actions ten times, so we need to make below two actions automatically, This is an automated build.

Take Travis CI as an example. The following is a description of the official document

Document address: docs.travis-ci.com/user/tutori…

Visit Travis Ci server: app.travis-ci.com/, log in with github account and send you a verification email. After successful verification, go to the Dashboard page and select the warehouse to build. Click Trigger Build button to build

This is the Travis CI continuous integration server configuration file. This configuration file is equivalent to a continuous integration script file, which indicates what the continuous integration server does when it receives your build trigger. The common configuration is as follows:

Language: node_js node_js: - "10" # This script is NPM test after_script in node.js: -gitbook build # build as AN HTML file, Git config. Name "${USER_NAME}" # git config Git commit -m "publish gitbook" "publish gitbook Git push --force --quiet "https://${ACC_TOKEN}@${GH_REF}" master:${BRANCH} # branches: only: - mainCopy the code

The configuration file is divided into three sections:

  • The first paragraph indicates in what programming language is the specification project written
  • The second section is the construction task
  • The third paragraph indicates under what circumstances does this script fire

Github has changed the default branch name of the repository to Main on October 1, 2020. Git init command: git git init command: git git git init command: git git init command: git git init

Reference: www.jianshu.com/p/e8342a72c…

3. Commit code changes to the main branch

  • git add .
  • Git commit -m
  • git push

4. Go back to Github and switch to the Main branch to see the commit

You can see that there is an icon behind the submission record. There are three types of ICONS, respectively:

  • Yellow circle: indicates building
  • Check box: The construction is successful
  • Cross: indicates that the construction fails

Click on the icon and click Details

Scroll to the bottom to see a link. Click View More Details on Travis CI to enter the Travis CI workbench

You can see the detailed build information here

The current build is failing, why?

The reason is that there are many variables like ${USER_NAME} in our.travis. Yml file. Why are these variables represented? The reason is that the.travis. Yml file is a script file in plain text, which will be put into the warehouse. The protocol we chose to create the warehouse is MIT protocol, which means that the code is open source.

So how do we get these variables to be identified correctly?

Just set the five environment variables on the Travis CI server for the project and the script file will run successfully.

The environment variables of the script are as follows:

  • ACC_TOKEN: XXXXXXXXXXXXXXXXXXXXXXXXXXXX
  • BRANCH: gh – pages
  • GH_REF：github.com/yourname/cjpbook
  • USER_EMAIL：[email protected]
  • USER_NAME: XXXX

Change the values of these variables to your own information.

Since Travis needs to push the compiled code to your repository branch after it is compiled, that will definitely require access to your repository, which is why we generated the token.

Click on the image in the upper right corner of Github -> Settings-> there will be a list on the left. Click on Developer Settings-> Personal Access Tokens -> Generate New Give your token the name ACC_TOKEN, check only the first item in the list, as long as you have permission to push the code, and then click Generate token.

Do not close the current page after generating token, please note this token; Because it is only displayed once, forgetting that it can only be generated again.

5. Add environment variables to the Travis CI server, click More Options, and select Settings

Enter the name and value of the environment variables here, and then click the Add button to Add them. When finished, they will be displayed above

With these five environment variables, there’s actually a problem, so let’s look at the build information

The command line error message is exited with 2, and the command line exit code is not 0.

6. Run NPM init -y in the project directory to generate package.json file

There is a script script in this package.json file, and there is a test command in the script, which is the script command of NPM test automatic test. There is a message in the script, which is to execute two commands, one is to print err information and the other is to exit. The exit 1 is incorrect. The exit code is 0, so we need to change the exit code to 0, so that the test command will be executed in the future, because we don’t need to test this demo, as long as the exit code is correct the command will pass.

There is also a problem because the.travis. Yml build script contains a gitbook build command. The Travis CI server will not install gitbook after cloning your code. So we also need to add the devDependencies dependency to package.json to install the Gitbook-CLI tool

7. Push code changes to the remote repository main branch

  • git add .
  • Git commit -m
  • git push

Go back to Github, view the commit, and repeat step 4 above to see that the code built successfully

You can also see in the warehouse that this submission is checked

Now you can go back to the GH-Pages branch and see the compiled ch03.html file

Refresh the GitBook page and you can see that chapter 3 has been added successfully

Four,

What is the Travis CI automated build process?

For example, when you or your team members commit new changes to the main branch of the repository, the Travis CI server is triggered to do continuous integration, provided that you have the.travis. Yml configuration file in your project directory.

What does the Travis CI server do?

The Travis CI server will clone your repository, which is equivalent to starting a development environment (virtual machine) on the Travis CI server, import five environment variables, install the Node.js environment and version, and run NPM install to install project dependencies. So the gitbook-CLI tool will be installed, followed by NPM test, followed by after_script we wrote in the.travis. Yml file, each one executed in sequence and then exited.

For node.js projects, Travis CI will execute two default scripts, as shown below. NPM test actually executes script code from package.json in the project file. Note that you need to change the default script exit code to 0, otherwise the build will fail.

The following nine scripts are executed by default on the Travis CI server, as shown in the figure below. The nine scripts are actually grouped into three categories, as shown in the blue bar below:

  • Type 1: Install project dependencies. Project dependencies will not run unless the project is installed
  • Type 2: Executing scripts. Scripts include executing build tasks, unit tests, and so on
  • Type 3: Complete the deployment.

Travis CI + Github + NPM demonstrates the process of automated builds. Different tools do different tasks, but as long as we understand the workflow of automated builds, we only need to adjust the tools accordingly.

The demo code has been uploaded to Github:

Github.com/Mr-Jemp/cjp…