preface

If you’ve ever deployed a project manually, you’ll be aware of the need for continuous integration, because manual deployment can be tedious and time-consuming, and even though the deployment process is basically fixed, it’s still prone to errors.

If you’re familiar with continuous integration, you’ll agree that “using it has become standard.”

Continuous Integration(CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, Allowing teams to detect problems early. Continuous integration is a development practice that requires developers to integrate code into a shared repository multiple times a day, and each commit is checked by an automated build so teams can detect problems ahead of time.

There are many tools for continuous integration, such as Jenkins, developed in the Java language, which is used by many large companies because of its ability to distribute build and load test across multiple machines.

But Jenkins’ unpolished interface makes me cringe…

As GitHub has grown, more and more CI/CD products have emerged that support GitHub. On the GitHub marketplace, you can see that more than 300 continuous integration service providers have been supported (details). I chose Travis CI because I was recommended by many friends around me.

Let me share how I use Travis CI+GitHub to achieve continuous integration and automatic deployment. Through my research and practical experience, I hope I can help friends in need.

What is Travis CI

Travis CI is an open source distributed continuous integration service developed in Ruby to automatically build and test GitHub hosted projects. Support for more than 20 programming languages including Javascript, Node.js, Ruby and so on. CI services are free for open source projects. You can also buy his paid version and enjoy more services.

Travis CI currently has two official websites, travis-ci.org and travis-ci.com. Travis-ci.org is an old platform that has gradually migrated to the new one, travis-ci.com. Travis CI supports free automated builds of private repositories on the new platform.

Obtain the GitHub Access Token

Travis CI needs to push content to a branch of the repository during automatic deployment, and Access to the GitHub repository requires user authorization by providing Travis CI with an Access Token.

Obtain tokens from GitHub->Settings->Developer Settings->Personal Access Tokens

After all items under repo and user:email under user are selected, a token is generated and the token value is copied.

Note: This token can only be seen now, and can not be seen again, and forgotten can only regenerate, so remember to keep it.

Log in to Travis using your GitHub account

Go to Travis’ website and log in with your GitHub account. (I’m currently using its old platform)

After you log in, you will see all the public Open Source repos under your GitHub account in Travis.

3. Start monitoring the project

Select the target project and turn on the right switch.

Configure Travis

  • Click Settings on the right of the switch to enter the Travis configuration page for the project
  • Check triggering conditions
  • Setting global variables

    Note: The access token obtained in the first step must be set

    The set variable can be referenced in the configuration file as ${variable name}.

5. Add in the project root directory.travis.ymlThe configuration file

Note that the file name begins with a.

A build of Travis CI takes two steps:

  1. Install any required dependencies
  2. Script to run the build script

Travis CI provides some “hooks” for building the lifecycle

A complete Travis CI build lifecycle:

  1. OPTIONAL Install apt addons
  2. OPTIONAL Install cache components
  3. before_install
  4. install
  5. before_script
  6. script
  7. OPTIONAL before_cache(for cleaning up cache)
  8. after_success or after_failure
  9. OPTIONAL before_deploy
  10. OPTIONAL deploy
  11. OPTIONAL after_deploy
  12. after_script

Custom commands can be run before before_install and before_script, or after after_script. For details, see the official document: Job Lifecycle

I’m in the footprint project. Travis. Yml complete configuration:

language: node_js # Set language

node_js: "10.16.3" Set the language version

cache:
  directories:
    - node_modules # Cache dependency

# S: Build Lifecycle
install:
  - npm i

script:
  - npm run build

#after_script #after_script #after_script #after_script #after_script #after_script #after_script #after_script #after_script #after_script #after_script #after_script
The variables in the # command are configured in Travis CI.
after_script:
  - git clone https://${GH_REF} .temp
  - cd .temp
  - git checkout gh-pages
  - cd ../
  - mv .temp/.git dist
  - cd dist
  - git config user.name "${U_NAME}"
  - git config user.email "${U_EMAIL}"
  - git add .
  - git commit -m ":construction_worker:- Build & Deploy by Travis CI"
  - git push --force --quiet "https://${Travis_Token}@${GH_REF}" gh-pages:${D_BRANCH}
# E: Build LifeCycle

The script is run only when the specified branch is committed
branches:
  only:
    - master
Copy the code

Done!

Push.travis. Yml to remote and you can see that Travis is building and compiling. And every time you push the code, Travis automatically executes the script task configured in Travis. Yml.

  • Automatic compilation:

  • Once built, Travis will automatically deploy to GitHub based on my configuration:

And One More Thing

Once the build is complete, you can add build badges to your GitHub project. Method: In Travis, click on the badge to the right of the item to get the small badge address and place it in the readme.md document.

For more information on customizing GitHub badges, see my other post, the GitHub Project Logo

—

Welcome to reprint, reprint please indicate the source: champyin.com/2019/09/27/…