Automate the hell out of your code Automate the hell out of your code

2025-05-25

自动化你的代码

自动化你的代码

自动化你的代码

说到自动化,你会想到什么?软件自动化涵盖了所有旨在利用你的编码技能和资源来避免手动执行重复性任务的实践,我们编写脚本来处理所有重复性任务,从而提高工作效率,更快地交付代码,并真正专注于代码编写。在本文中,我将向你介绍软件自动化的概念,我们将讨论 CI/CD。如果你不知道这些缩写的含义,也不用担心,读完本文后,你将能够彻底实现代码自动化。好了,让我们开始吧。

带上你自己的 Repo

为了跟上本文的学习,你需要创建一个 GitHub 仓库,或者你也可以使用之前创建的一个。我将使用 GitHub Actions 来自动化我们的代码,如果你觉得 Circle CI 更适合你,也可以使用。

创建 GitHub 工作流

要创建 github 工作流,请在当前工作目录的根目录中创建一个名为 .github 的文件夹,并在其中创建一个工作流目录,我们将在此工作流目录中实际编写处理 CI 的代码。

------.github/-----workflows/-----integrate.yml
Enter fullscreen mode Exit fullscreen mode

Github 使用 yml 文件作为其工作流程,每个以.yml扩展名结尾的文件都将被 github 视为工作流程,并且根据我们在文件中指定的任何条件,github 将自动运行工作流程,只需知道每个工作流程都应具有以下语法;请参阅 github 操作文档

name: WE SPECIFFY THE NAME OF THE JOB

on:                                 # Which event to trigger this workflow
 github_event:                      # e.g pull, pull_request, push, commit etc
   banches: [ branch_to_run_workflow_on, another_branch]


# A workflow run is made up of one or more jobs that can run sequentially or in parallel

jobs: 
  give_the_job_a_name:

    runs-on: machine_to_run_on      # ubuntu-latest, windows-latest, macos-latest

    steps:
      - uses: use_already_defined_workflow
      - run: terminal command
      - run: another terminal command
Enter fullscreen mode Exit fullscreen mode

什么是持续集成 CI?

持续集成是一种软件开发原则,它建议开发人员编写小段代码,并将这些代码推送到代码库时,这些代码应该由在远程机器上运行的脚本自动测试,从而自动执行向代码库添加新代码的过程。这实现了软件测试的自动化,从而提高了开发人员的工作效率,并使他们能够专注于编写通过测试的代码。

让我们编辑我们的integrate.yml工作流,当存储库中有拉取请求时,它将自动测试我们的代码

# This workflow will run on every pull request to the master branch, 

# This is the name of the workflow, every workflow needs a name
name: NODE CONTINOUS INTEGRATION WORKFLOW 

# Here we specify on which action in the repository that we want to run this workflow, e.g push, pull_request, commit, pull e.t.c

on:
  pull_request:
    branches: [ master ]

# we define one or more jobs, every workflow should have a job, we can give each job a name

jobs:
  automate_our_testing: 

  # we need to tell it which machine to run the job on
  runs-on: ubuntu-latest

  # Steps represent a sequence of tasks that will be executed as part of the job

  steps:
    - uses: actions/checkout@v2         #This pulls our code to the remote machine
    - uses: actions/setup-node@v2       # This setsup node js on the machine
      with: 
        node-version: 12
    - run: npm ci                   # installs our project dependencies
    - run: npm run build                # builds the project
    - run: npm test                 # runs our test command
      env:
        CI: true

Enter fullscreen mode Exit fullscreen mode

如果您在计算机本地创建了此文件,则可以保存、提交它,然后将其推送到 github。完成后,转到操作选项卡,您应该会看到该工作流程列在那里。如果您对代码库进行了一两处更改并将其推送到 repo,发出拉取请求,返回到操作选项卡,您应该会看到此工作流程正在运行,并且可以获取有关工作流程中每个步骤的信息。很酷的是,如果我们的测试失败,我们会得到一个日志,我们可以在日志中检查作业中的每个步骤,以了解哪里出了问题,修复它并将其推送回 repo,我们的工作流程将再次运行,因为我们有一个打开的拉取请求,如果所有测试都成功通过,我们将在每个步骤旁边看到检查,然后我们就可以合并拉取请求。这就是持续集成的实现。

什么是持续部署 CD?

如果说持续集成是向代码库添加新的代码块,那么持续集成 (CD) 就是自动构建代码并将其部署到生产环境,从而确保生产环境与代码库中的最新功能保持同步。您可以阅读这篇文章了解更多关于 CI/CD 的信息。
我使用 Firebase 托管服务,因此我们可以定义一个工作流来构建代码并将其部署到 Firebase 托管服务,而不必自己手动操作。

但是我们有一两个问题需要处理。通常情况下,我们可以从电脑上将代码部署到 Firebase,因为我们是从终端登录的。但是,如何授权远程 CI 服务器执行此操作呢?打开终端并运行以下命令,firebase login:ci它会返回一个 FIREBASE_TOKEN,我们可以使用它来验证 CI 服务器。我们需要将此令牌添加到 GitHub,以便 GitHub 可以安全地为我们加密,并且我们可以将其作为变量调用,而不是在工作流中进行硬编码,这可能会导致安全问题和担忧。

  • 打开 GitHub 和您想要添加此 CD 工作流程的 repo
  • 导航至设置
  • 在设置下点击秘密
  • 点击添加新秘密
  • 将其命名为 FIREBASE_TOKEN
  • 将 Firebase 给我们的 token 粘贴为 secrete 的值
  • 点击添加秘密。

在您的本地机器上,我们需要创建另一个工作流来处理此部署,创建一个新文件并随意命名,我将其命名为 build.yml

------.github/-----workflows/-----integrate.yml
                               |---build.yml
Enter fullscreen mode Exit fullscreen mode

它应该包含以下内容

# This workflow runs on every push/merge to the master branch

name: FIREBASE_DEPLOY

# Controls when the action will run. 

on:
  # Triggers the workflow on push or pull request events but only for the master branch
  push:
    branches: [ master ]

  # Allows you to run this workflow manually from the Actions tab

  workflow_dispatch:


jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest


    steps:

      - uses: actions/checkout@v2       # import our files to the remote CI server

      # Runs a single command using the runners shell
      - name: Use Node.js version 12
        uses: actions/setup-node@v2     # using node js
        with:
          node-version: 12
      - run: npm ci                     # clean install of our dependencies
      - run: npm run build              # building our project
      - name: GitHub Action for Firebase  
        uses: w9jds/firebase-action@v2.0.0  # predefined workflow for firebase
        with:
          args: deploy --only hosting       # deploying only hosting
        env:
          FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}  
          # using our secrete token to authenticate the remote CI to push code to firebase hosting

Enter fullscreen mode Exit fullscreen mode

现在,如果我们直接将代码推送到主分支,或者从主分支合并拉取请求,此工作流程将自动触发,将代码部署到 Firebase。但我并不指望每个人都使用 Firebase,有时我也会部署到 Netlify,但我只是以 Firebase 为例,帮助你入门。我建议你观看此视频,了解使用 GitHub Actions 的其他功能。

这就是本文的全部内容,希望您觉得这篇文章有趣并且能学到一些东西,欢迎在下面留言。

文章来源:https://dev.to/kalashin1/automate-the-hell-out-of-your-code-3j42
PREV
坚实的设计原则
NEXT
100 多个前端项目助您提升技能