Automated deployment of Github Pages with Travis CI


Link to the original text: Automated deployment of Github Pages with Travis CI


Github Pages can’t run dynamic programs, it can only output some static content. So Github Pages is very suitable for front-end project demonstration. It can be used to store project introductions, project documents or personal blogs. This article describes how to deploy Github Pages with Travis CI automation.


Continuous integration is a software development practice in which team members often integrate their work, usually at least once a day, which means that integration may occur many times a day. Each integration is validated by automated builds (including compilation, publishing, automated testing) to detect integration errors as early as possible. Currently, Circle CI and Travis CI are the main CI used in GitHub open source projects, both of which use container technology to adapt to different project environments.

(Figure 1 CIrcle CI, Figure 2 Travis CI)


1. Install Github App

Install Travis CI in Github Market Place. Select the project permissions you want when installing.
<img” rel=”nofollow noreferrer”>…; width=”50%” />

2. Configure Github Token

Configure Github Token for Travis CI access to your project, after configuringDon’t refresh the page. First click the copy button behind Token.Because you can only see this Token once, refresh it and it’s gone.I have to admire Github’s security: +1:

3. Encryption Github Token

The following is an example of Github Pages configuration for Travis CI official documents:

  provider: pages
  skip_cleanup: true
  github_token: $GITHUB_TOKEN # Set in the settings page of your repository, as a secure variable
  keep_history: true
    branch: master

$GITHUB_TOKENIt is an encrypted environment variable. Github will delete the token without encrypting it and submitting the plaintext directly to a Repo. It’s just too safe.The encryption step is

Gem install travis Travis CI official cli tool
Travis login -- pro # login to Travis CI, account password for your Github account password
Travis encrypt'GITHUB_TOKEN= <YOUR_GITHUB_TOKEN>'-- add # encrypt GitHub token and add it to configuration file automatically

4. Configuration.travis.yml

Complete.travis.ymlConfiguration example, you need to decrypt the previously encrypted GitHub token, of course, only Travis CI knows what the result of decryption is.

Address: Bougie Design Travis CI config

language: node_js
  - '10'
  - composer config --global "$GITHUB_TOKEN"
  - yarn
test: true
  - yarn docs:build
  - cp -r ./.docz/dist/* .
  provider: pages
  skip_cleanup: true
  github_token: $GITHUB_TOKEN
  keep_history: true
    branch: master
    secure: TTQLIDz0jL4FRFrpq6DDocxLiELUSpJsj9phdmjW9Eg9kna73KjPF2XmZaWFvkObZU3og/7Thr/iwsXQqfdq8gHShhLkHZAZqgvWqbjMIQABYIFqqqUE9grrPdrLXWVAidh+nET+pjes8VX92NBz6HA+i/15+PugVwYhC85AGyNN2JRL7nxCwh2ECiKATRiX+cLmVqFwTGpzqHovAiBFnap17whWa4C4uVEzdBwjQAZKw+IFxiiJIA7hkFTTThS11uCx//Dr7/A1X7c6ZLao/qiwvW8fNAbhV5ZA6dx4a0vtLwj6lprjcwWuGQX/vutKHnpdNpxeIDhmLNspN1U7YxjgUZJXgFjpE6tw1I8N6nSRpzhPUlrXPkKUAdN9x2jN20NSUeFDSl0FhazPwhGWzlSQb0gNyH1U04wvw3QB2VP/3UvTiyCZjum6prTpuXy/D262smG97o0/0XlNySX6MC+OLQNDIVgzO4YO2IHVB8lW6CBSMeTlcE8a4yvHwmGQpLKnX6tY06/n8lvjgZgPKZaRZL6aVrBE+/104Gt/aBFpraZZpiXJjXjdm4TO3N+u8gT8+gkDJ0BvzrX7Kf/W/WouecziCJgzYCB7y8eqec4kmZKRs2O6zyKJ0SbPrW54UuCmjFzTLEmdRCXRLIbEQsWvS5x+FKKwGNGRcrgPjxY=

5. Triggering CI

The default is triggered when git push or when tag is changed. After push, you can go to to view the CI log. If the log shown in the figure below appears, the deployment of Github Pages is successful
<img” rel=”nofollow noreferrer”>…; width=”50%” />

6. Check out Github Pages

Travis CI automatically creates a branch called gh-pages, as shown in the figure:
<img” rel=”nofollow noreferrer”>…; width=”50%” />

Set the Github Pages branch to gh-pages in the project settings:

Visit can access Github Pages. Note that the root path of Github Pages is not/But/repo-name/So remember to set the underlying routing to/repo-name/Otherwise, there will be resource path errors.

Appendix: Teacher Ruan’s Explanation of Several Concepts of “Continuity”

I. Concept

Continuous integration refers to the frequent (multiple times a day) integration of code into the backbone.

It has two main advantages.

(1) Fast detection of errors.Every little update is integrated into the backbone, which can detect errors quickly and locate errors easily.

(2) Prevent the branches from deviating from the trunk.If it is not often integrated, the backbone is constantly updated, which will lead to the difficulty of integration in the future, or even difficult to integrate.

The goal of continuous integration is to enable products to iterate quickly while maintaining high quality.Its core measure is that code must pass automated testing before it can be integrated into the backbone. As long as one test case fails, it cannot be integrated.

Martin Fowler said, “Continuous integration does not eliminate Bugs, but makes them very easy to discover and correct. “

There are two concepts related to continuous integration, namely, continuous delivery and continuous deployment.

Continuous delivery

Continuous delivery refers to the frequent delivery of new versions of software to quality teams or users for review.If the review passes, the code goes into production.

Continuous delivery can be seen as the next step in continuous integration. It emphasizes that software can be delivered anytime, anywhere, no matter how it is updated.

Continuous deployment

Continuous deployment is the next step in continuous delivery, referring to the automatic deployment of code to production environment after review.

The goal of continuous deployment is that the code is deployable at any time and can enter the production phase.

The premise of continuous deployment is to automate the testing, construction, deployment and other steps. It differs from continuous delivery by referring to the following figure.

(Photo Source)

IV. Process

According to the design of continuous integration, the whole process of code submission to production includes the following steps.

4.1 Submission

The first step in the process is for the developer to submit the code to the code repository. All subsequent steps begin with a commit of local code.

4.2 Test (first round)

The code repository configures hooks for commit operations, and automated tests run whenever code is submitted or merged into the trunk.

There are several kinds of tests.

  • Unit Testing: Testing for Functions or Modules
  • Integrated Testing: Testing for a function of the overall product, also known as functional testing
  • End-to-end testing: full-link testing from user interface to database

At least run unit tests in the first round.

4.3 Construction

Through the first round of testing, the code can be merged into the trunk, even if it can be delivered.

After delivery, build first, and then enter the second round of testing. Construction refers to converting source code into actual code that can be run, such as installation dependencies, configuration of various resources (stylesheets, JS scripts, pictures), and so on.

Common building tools are as follows.

  • Jenkins
  • Travis
  • Codeship
  • Strider

Jenkins and Strider are open source software, and Travis and Codship are free for open source projects. They all build and test and execute in one run.

4.4 Test (second round)

When the build is completed, the second round of testing is needed. If the first round already covers all the test content, the second round can be omitted, of course, at this time, the construction steps also need to move ahead of the first round of testing.

The second round is comprehensive testing, unit testing and integration testing will run, if conditions permit, also do end-to-end testing. All tests are mainly automated, and a few test cases that cannot be automated need to be run manually.

It should be emphasized that every update point in the new version must be tested. If the test coverage is not high, serious problems are likely to arise after the deployment phase.

4.5 Deployment

After passing the second round of testing, the current code is an artifact that can be deployed directly. Pack all the files for this version(tar filename.tar *) Archive and send to production server.

The production server packages the files, unpacks a directory in the cost area, points the symlink of the running path to the directory, and restarts the application. Deployment tools in this area include Ansible, Chef, Puppet, etc.

4.6 rollback

Once the current version has problems, roll back to the previous version of the build results. The simplest way is to modify the symbolic link to point to the directory of the previous version.