foreword

Everyone presumably deploys front-end projects through automated deployment at work, that is, when we develop a certain requirement, we only need to push the code to a certain branch, and then the deployment can be completed automatically. We generally do not need to Care about how the project is built and deployed, which greatly improves our development efficiency.

In the absence of automated deployment, the deployment process of front-end projects is generally like this: (manual deployment)

• Build locally after development is complete

• Hand over the built files to the operation and maintenance (the front-end personnel have permission to omit)

• Upload the package file to the specified directory on the server

Front-end projects have to go through this process every time they go online. For programmers, how can this be tolerated? They would rather waste time on B-huts than on these unskilled workflows, and manual operations will inevitably lead to error.

So today I will share with you how to automate the deployment of your own front-end projects.

Automated deployment scripts

Let's share a simple automated deployment solution - automated deployment script

Every time we deploy a project, several steps are fixed. Since it is fixed, we can help us to complete it by writing scripts, which can not only improve our development efficiency, but also avoid the possibility of human operation. mistakes that occur.

New warehouse

We can create a new project on GitHub and try to deploy it to GitHub Pages.

New Project

Here we create a new Vue3 + TS project

add script

We create a new script file directly in the project root directorydeploy.sh

#!/usr/bin/env sh

set -x # here is to see the error log

# package project
npm run build

# Enter the packaged folder
cd dist

git init
git add -A
git commit -m 'auto deploy'

# Push the packaged file to the specified branch

git push -f https://github.com/bettersong/nanjiu.git main:static-pages

execute script

Now we can execute sh deploy.sh, and then the contents of our script file will be executed, first packaged, and then pushed to the remote designated branch (static-pages). We can go to the github repository to view the packaged products.

How do we access this page after deployment?

Setting -> PagesThe access address of this page can be viewed in the warehouse

Finally, we visit this address https://bettersong.github.io/nanjiu/ to see our deployed page.

This solution is finally GitHookscombined, and the packaging and deployment can be automatically completed when a branch is submitted, which will not be introduced here. Let's look at another, more elegant solution.

CICD

CICD translates to continuous construction and continuous delivery.

CI Continuous Integration (Continuous Integration)

Continuous Integration: Frequent merging of code into the master branch, emphasizing feedback to development through integration testing, whether it fails or succeeds.

Continuous integration is divided into three phases:

• Continuous integration preparation stage: according to the needs of software development, prepare some pre-work for CI

• Code repository with integrated CI tools (Gitlab, Github, Jenkins, etc.)

• Scripts for unit or integration tests

• The configuration file that triggers CI, realizes the Jobs of various functions

• Continuous integration in progress

• Push code to start CI system

• Monitor the testing and construction of the code through the CI system, and feedback the integration results

• Realize version management through version management system

• Continuing the integration completion stage: feedback integration results

CD Continuous Delivery (Continuous Delivery)

Continuous delivery: mainly for testers and products, it can ensure one-click deployment, and the content to be delivered often includes

• Source code: disadvantage, the environment that the code depends on is not easy to control

• Packaged binaries or system packages: Deployment failures due to compatibility issues and environment differences

• Virtual machine image delivery: system isolation is the best, but it takes up system resources seriously

• Docker Delivery: Container Delivery, Lowest Cost, Best Compatibility

Continuous deployment: At this time, a stable version should be provided, including the required environment and dependencies, mainly to provide services to users, and to be able to roll back quickly if an error occurs.

CICD is currently a deployment solution chosen by most Internet companies because it can flexibly configure various stages in the project deployment process. Let's introduce how to use GitHub's CICD to deploy front-end projects.

GitHub Actions

GitHub ActionsIt is a platform for continuous integration and continuous delivery, which can automate building, testing, and deployment. You can create workflows to build and test each pull requestor deploy the merged code to production.

Workflows

A workflow is a configurable automated process. To create a workflow, you need to define a YAML file. When your repository triggers an event, the workflow will run. Of course, you can also trigger it manually, or define a schedule. A repository can create multiple workflows, each of which can perform different steps.

Events

Events refer to specific actions that the warehouse triggers to run the workflow, such as creating a new one, creating a pull requestnew one issue, or pushing a new one commit. You can also trigger a workflow using a schedule, either by requesting a REST API, or manually.

Jobs

A task is a set of steps executed on the same runner. A step is either a shell script or an action. Steps are executed sequentially and independently of each other. Because every step is executed on the same runner, you can pass data from one step to another.

You can configure a task to depend on other tasks. By default, tasks have no dependencies and are executed in parallel. When a task requires another task, it waits until the dependent task is completed before executing it.

Actions

An action is a custom application of the GitHub Actionsplatform that performs a complex but frequently repeated job. Using actions can reduce duplication of code. For example, an action can pull your git repository from GitHub, create the appropriate toolchain for your build environment, etc. You can write your own actions, or find already implemented actions on the GitHub marketplace.

Runners

A runner is a service that can run workflows. Each runner only runs a single task at a time. GitHub provides Ubuntu Linux, Microsoft Windows and macOS runners, each of which runs in a separate, newly created virtual machine. If you need a different operating system, you can customize the runner.

After understanding the above related GitHub Actionsconcepts, we start to build our own workflow for project deployment.

Build workflow

.github/workflows

We click on the previously built warehouse New workflowto create a new workflow.

Then you will be taken to the page for selecting a workflow

Here you can choose a workflow created by someone else, or you can choose to create your own workflow.

We still choose to create our own workflow, and then we will create a new directory under the root directory of our project .github/workflows. Here we will create a new ci.ymlyml .

yml

In this file, what we have to do is to package and deploy

name: Build and Deploy
on: # Listen for push events on the main branch
   push:
     branches:
       - main
jobs:
   build-and-deploy:
     runs-on: ubuntu-latest # build environment using ubuntu
     steps:
       - name: Checkout # Pull the code to the virtual machine
         uses: actions/[email protected]
         with:
           persist-credentials: false

       - name: Install and Build # Download dependencies Package project
         run: |
           npm install
           npm run build

       - name: Deploy  # deploy
         uses: JamesIves/[email protected]
         with:
           branch: static-pages # Branch to commit to after deployment
           Folder: dist # Fill in the packaged directory name here

We submit this file, and it will complete the packaging and deployment work by itself after submitting the code.

Automated deployment

After the code is submitted, it will be packaged and deployed according to the steps of our workflow

And the log of the entire workflow can be viewed above, which is convenient for troubleshooting

After deployment, the access address is still the same https://bettersong.github.io/nanjiu

At this point, our GitHub Actionsimplementation-based automated deployment process is complete. Now, after we modify the code locally, we only need to push the code to the remote to achieve automatic packaging and deployment.