Automate deployments with GitHub Actions
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.
0 Comments