Introduction:

With the birth of Nodejs, the popularity of Nodejs brings more convenience to front-end development, various NPM packages, Node tools. Front-end engineering has also been greatly enhanced, with a series of automated processes from project creation, development, to release and build. Today, we’ll explain how to automate the release build process.

Related Concepts

  • What is the CI/CD? Through continuous integration, developers can frequently integrate their code into the main branch of a common code repository. Developers can submit their work to the repository multiple times at any one time, rather than developing each feature module independently and submitting it at the end of the development cycle. The goal of CI is to simplify integration into a simple, easily repeatable daily development task that helps reduce overall build costs and find defects early in the development cycle. Effective use of CI requires a shift in the development team’s habits, encouraging frequent iterative builds, and actively addressing bugs early on when they are found. Continuous delivery (CD) is actually an extension of CI in which the software delivery process is further automated so that it can be easily deployed to a build environment at any time. Mature continuous delivery solutions also demonstrate a code base that is always deployable. With CDS, software releases become a routine event without any tension. The development team can make production-level releases at any point in the day, without the need for detailed release plans or special post-production testing.

    This continuous integration process is the deploy process shown above.

  • There are Travis-CI, Github Actions, Gitlab Runner, CircleCI, etc. I have used the first three of them myself and they are running well. Here I’ll use Travis-CI and Github Actions as examples of how a github private repository’s front-end code is automatically built into the GitPage of another Github public repository.

  • Travis – CI entrance

Travis- Ci provides a virtual environment to pull remote repository code from your Github licensed token via a configuration file, and then package and compile it. Once packaged, you can run scripts and push them to other repositories or remote services. See Travis- Ci usage documentation for details

  • First, go to your Github to create a token with pull code permission, and go to Settings.

    Find the developer Settings

    Find Personnal Access Tokens and create a token

    Each is specific what meaning, oneself can go to consult, tick more, authority is bigger, security hidden trouble is higher, generally speaking, enough to go. Select the following two items based on project requirements.

    After the token is created successfully, keep it safe and display it only once

    With token, we can go to Travis -ci to set up. The second step finds the Settings for Travis -ci and configates the environment variables

    All of the above variables are used in the configuration environment, which is located in the project root directory as.travis-ci.yml

    Push code specifically triggers the automatic build process of Travis – CI. The following is the content of the configuration file

# language
language: node_js
# version
node_js: stable
Depend on the installation mode
Install command
install:
  - yarn
 Run the script
script: yarn build
After the script is successfully executed, run the multi-line script
after_script:
  - cd dist
  - cp index.html 404.html
  - echo "pro.abckey.com" > CNAME - git init - git config user.name "${USER_NAME}" - git config user.email "${USER_EMAIL}" - git add . - git commit -m "Automatically update from travis-ci" - git push --quiet --force "https://${GH_TOKEN}@${GH_REF}" Master :gh-pages # Official github- Page builddeploy:
  provider: pages
  skip_cleanup: true
  github_token: $GH_TOKEN
  keep_history: true
  on:
    branch: master
branches:
  only:
    - master
Copy the code

With all our configuration done, we can build our project on our own. When we automate builds, we can see the entire build process and trace back to errors if there are any.

Look, it’s built! Now, let’s use github Actions again.

  • Github Actions

In addition to Travis – CI, we can also use GitHub Actionss. GitHub Actions is GitHub’s continuous integration service, which launched in October 2018. Ruan yifeng also said on his blog – thought it was very powerful, creative and more than Travis CI play.

I will also demonstrate how to use GitHub Actions to automatically publish a Vue application to GitHub Pages.

  • Some terms:

(1) Workflow: Continuous integration of a running process, that is, a workflow. (2) Job: A Workflow consists of one or more jobs. Multiple tasks can be completed in a continuous integrated operation. (3) Steps: Each job consists of multiple steps to be completed step by step. (4) Action: Each step can execute one or more commands in turn (action)

As you know, continuous integration consists of many operations, such as grabbing code, running tests, logging into remote servers, publishing to third-party services, and so on. GitHub calls these actions actions.Many Actions have already been written and put on Github by developersWe can just use someone else’s, if we don’t want to write our own scripts. GitHub has created an official marketplace for searching actions submitted by others. There’s also a repository for awesome Actions, where you can find quite a few actions.

If you need an action, you don’t have to write a complex script, you can just refer to someone else’s action, and the whole continuous integration process becomes a combination of actions. This is what makes GitHub Actions special.

The process of applying for a token has been described previously, but it will be skipped here. Actions also reside directly in the.yml configuration file, specifically in the workflows folder under the.github folder at the root of the project

Because it refers to someone else’s actions, please refer to someone else’s configuration file on Github for details. The configuration content is as follows:

name: GitHub Actions Build and Deploy Project
on:
  push:
    branches:
      - master
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@master

      - name: Build and Deploy
        uses: JamesIves/github-pages-deploy-action@master
        env:
          ACCESS_TOKEN: The ${{ secrets.MY_DEPLOY_KEY }}
          BRANCH: gh-pages
          FOLDER: dist
          BUILD_SCRIPT: npm install && npm run build &&  cp ./dist/index.html ./dist/404.html && echo "pro.abckey.com" > ./dist/CNAME
      - name: deploy to target directory
        uses: crazy-max/ghaction-github-pages@v1
        with:
          target_branch: gh-pages
          build_dir: dist
          repo: abclib/pro.abckey.com
        env:
          GITHUB_TOKEN: The ${{ secrets.MY_DEPLOY_KEY }}
          GITHUB_PAT: ${{secrets.MY_DEPLOY_KEY}}
Copy the code

After the push code, the compilation process is as follows

202 years ago, using good tools can really improve productivity oh, let’s say goodbye to the slash-and-burn manual era.