GitHub Actions nâng cao: Các workflow có thể tái sử dụng

GitHub Actions đã cách mạng hóa cách các nhà phát triển triển khai các đường ống Tích hợp Liên tục và Triển khai Liên tục (CI/CD) trực tiếp trong kho lưu trữ của họ. Khi các dự án mở rộng và các tổ chức phát triển, sự phức tạp của các quy trình làm việc này thường tăng lên theo cấp số nhân. Việc duy trì nhiều tệp YAML giống hệt nhau hoặc hơi khác nhau trên hàng chục kho lưu trữ nhanh chóng trở thành một cơn ác mộng bảo trì. Đây là lúc việc nắm vững các tính năng nâng cao như quy trình làm việc có thể tái sử dụng, xây dựng ma trận và quản lý bí mật hiệu quả trở nên quan trọng đối với bất kỳ kỹ sư DevOps hoặc nhà phát triển nào.

Trong hướng dẫn toàn diện này, chúng ta sẽ khám phá cách chuyển đổi từ các thiết lập GitHub Actions cơ bản, lặp đi lặp lại sang một kiến trúc CI/CD mạnh mẽ, có khả năng mở rộng và an toàn bằng cách sử dụng các quy trình làm việc có thể tái sử dụng, chiến lược ma trận và quản lý bí mật nâng cao.

Vấn đề với sự lặp lại trong CI/CD

Khi bạn mới bắt đầu với GitHub Actions, việc sao chép và dán định nghĩa quy trình làm việc từ kho lưu trữ này sang kho lưu trữ khác là điều phổ biến. Một dự án Node.js điển hình có thể có một .github/workflows/ci.yml kiểm tra mã, thiết lập Node, cài đặt các phụ thuộc, chạy thử nghiệm và lint mã.

Tuy nhiên, hãy tưởng tượng việc quản lý 50 microservice, mỗi microservice yêu cầu cùng một đường ống Node.js cơ bản. Nếu tổ chức của bạn quyết định bắt buộc sử dụng một công cụ quét bảo mật mới, hoặc nếu bạn cần nâng cấp phiên bản Node trên tất cả các dịch vụ, bạn sẽ phải đối mặt với nhiệm vụ khó khăn là cập nhật 50 tệp YAML riêng biệt. Cách tiếp cận này vi phạm nguyên tắc DRY (Don't Repeat Yourself) và tiềm ẩn rủi ro cao về sự không nhất quán và lỗi của con người.

Giới thiệu Quy trình làm việc có thể tái sử dụng (workflow_call)

Quy trình làm việc có thể tái sử dụng cung cấp một giải pháp thanh lịch cho vấn đề lặp lại. Được GitHub giới thiệu để giúp các nhóm chia sẻ cấu hình CI/CD, quy trình làm việc có thể tái sử dụng cho phép bạn định nghĩa một quy trình làm việc một lần và gọi nó từ nhiều quy trình làm việc khác, ngay cả trên các kho lưu trữ khác nhau trong cùng một tổ chức.

Cách hoạt động của Quy trình làm việc có thể tái sử dụng

Một quy trình làm việc có thể tái sử dụng được kích hoạt bằng cách sử dụng sự kiện workflow_call. Sự kiện này báo hiệu rằng quy trình làm việc được thiết kế để được gọi bởi một quy trình làm việc khác, thay vì chạy để phản hồi các sự kiện kho lưu trữ điển hình như push hoặc pull_request.

# .github/workflows/node-ci.yml (The Reusable Workflow)
name: Node.js CI

on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string
        description: 'The Node.js version to use'
    secrets:
      npm-token:
        required: false
        description: 'Token for accessing private npm packages'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          
      - name: Install Dependencies
        run: npm ci
        env:
          NODE_AUTH_TOKEN: ${{ secrets.npm-token }}
          
      - name: Run Tests
        run: npm test

Gọi một Quy trình làm việc có thể tái sử dụng

Để sử dụng quy trình làm việc này từ một kho lưu trữ khác, bạn sử dụng từ khóa uses, trỏ đến vị trí của quy trình làm việc có thể tái sử dụng. Bạn cũng truyền các inputs và secrets bắt buộc:

# .github/workflows/main.yml (The Caller Workflow)
name: Main Application CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  call-node-ci:
    uses: my-org/shared-workflows/.github/workflows/node-ci.yml@main
    with:
      node-version: '20.x'
    secrets:
      npm-token: ${{ secrets.NPM_TOKEN }}

Bằng cách tập trung hóa logic CI của bạn, một bản cập nhật duy nhất cho node-ci.yml ngay lập tức lan truyền đến tất cả các kho lưu trữ sử dụng nó, giảm đáng kể chi phí bảo trì.

Mở rộng quy mô với Matrix Builds

Trong khi các quy trình làm việc có thể tái sử dụng xử lý việc trùng lặp mã trên các kho lưu trữ, thì các bản dựng ma trận giải quyết các tác vụ lặp đi lặp lại trong một lần thực thi quy trình làm việc duy nhất. Một chiến lược ma trận cho phép bạn chạy một công việc nhiều lần với các biến khác nhau, tạo ra nhiều phiên bản công việc thực thi song song.

Định nghĩa một chiến lược ma trận

Hãy xem xét một kịch bản mà bạn cần kiểm tra ứng dụng của mình với nhiều phiên bản Node.js và trên các hệ điều hành khác nhau. Thay vì sao chép cấu hình công việc cho mỗi sự kết hợp, bạn định nghĩa một matrix:

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node-version: [18.x, 20.x, 22.x]
      fail-fast: false

Trong ví dụ này, GitHub Actions tự động tạo 9 công việc song song (3 hệ điều hành * 3 phiên bản Node). Tùy chọn fail-fast: false đảm bảo rằng nếu một công việc trong ma trận thất bại (ví dụ: Windows với Node 18), các công việc khác sẽ tiếp tục chạy, cung cấp một bức tranh hoàn chỉnh về khả năng tương thích của ứng dụng của bạn.

Các tính năng ma trận nâng cao

Các bản dựng ma trận có thể rất phức tạp. Bạn có thể sử dụng các khóa include và exclude để tinh chỉnh các công việc được tạo.

Ví dụ, bạn có thể muốn loại trừ việc kiểm tra trên Windows cho một phiên bản Node cũ cụ thể, hoặc bao gồm một bản phát hành beta đặc biệt chỉ dành cho Ubuntu:

    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node-version: [18.x, 20.x]
        exclude:
          - os: windows-latest
            node-version: 18.x
        include:
          - os: ubuntu-latest
            node-version: beta

Khi kết hợp với các quy trình làm việc có thể tái sử dụng, các bản dựng ma trận trở nên cực kỳ mạnh mẽ. Một quy trình làm việc gọi có thể định nghĩa một ma trận phức tạp và truyền các biến đó làm đầu vào cho một quy trình làm việc có thể tái sử dụng tập trung duy nhất, điều phối việc kiểm tra song song lớn với mã tối thiểu.

Quản lý bí mật ở quy mô lớn

Bảo mật là tối quan trọng trong CI/CD. Các quy trình làm việc thường yêu cầu quyền truy cập vào thông tin nhạy cảm như khóa API, mã thông báo triển khai và mật khẩu cơ sở dữ liệu. Việc quản lý hiệu quả các bí mật này là rất quan trọng, đặc biệt khi sử dụng các quy trình làm việc có thể tái sử dụng trong một tổ chức.

Truyền bí mật cho các quy trình làm việc có thể tái sử dụng

Như đã trình bày trước đó, các quy trình làm việc có thể tái sử dụng khai báo rõ ràng các bí mật mà chúng yêu cầu bằng cách sử dụng ngữ cảnh secrets trong on: workflow_call. Quy trình làm việc gọi có trách nhiệm truyền các bí mật này xuống.

Tuy nhiên, việc truyền rõ ràng mọi bí mật có thể trở nên tẻ nhạt. Để đơn giản hóa điều này, GitHub đã giới thiệu tùy chọn secrets: inherit. Khi một quy trình làm việc gọi sử dụng secrets: inherit, tất cả các bí mật có sẵn cho người gọi sẽ tự động được truyền cho quy trình làm việc có thể tái sử dụng:

jobs:
  call-deploy:
    uses: my-org/shared-workflows/.github/workflows/deploy.yml@main
    with:
      environment: 'production'
    secrets: inherit

Mặc dù tiện lợi, hãy sử dụng inherit một cách thận trọng. Chỉ kế thừa bí mật khi bạn hoàn toàn tin tưởng quy trình làm việc có thể tái sử dụng, vì nó cấp quyền truy cập vào tất cả các bí mật của kho lưu trữ hoặc môi trường của ngữ cảnh gọi.

Bí mật cấp môi trường

Đối với các quy trình làm việc triển khai, các bí mật cấp môi trường cung cấp một lớp kiểm soát bổ sung. Bằng cách định nghĩa các môi trường (ví dụ: staging, production) trong cài đặt kho lưu trữ của bạn, bạn có thể đính kèm các bí mật cụ thể vào chúng. Hơn nữa, bạn có thể thực thi các quy tắc bảo vệ, chẳng hạn như yêu cầu phê duyệt thủ công trước khi một quy trình làm việc có thể truy cập môi trường production và các bí mật của nó.

Khi một công việc tham chiếu một môi trường, nó sẽ có quyền truy cập vào các bí mật cụ thể đó:

jobs:
  deploy:
    environment: production
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Prod
        run: ./deploy.sh
        env:
          PROD_API_KEY: ${{ secrets.PROD_API_KEY }}

Kết luận

Chuyển đổi sang các tính năng GitHub Actions nâng cao sẽ biến các đường ống CI/CD của bạn từ các tập lệnh dễ vỡ, lặp đi lặp lại thành một cơ sở hạ tầng trưởng thành, có thể bảo trì. Bằng cách tận dụng các quy trình làm việc có thể tái sử dụng (workflow_call), bạn thiết lập một nguồn chân lý duy nhất cho các tiêu chuẩn của tổ chức mình. Các bản dựng ma trận đảm bảo kiểm tra toàn diện trên nhiều môi trường với cấu hình tối thiểu. Cuối cùng, các thực hành quản lý bí mật mạnh mẽ đảm bảo rằng các quy trình tự động của bạn vẫn an toàn ở quy mô lớn.

Áp dụng các kỹ thuật nâng cao này sẽ không chỉ giúp nhóm của bạn tiết kiệm vô số giờ bảo trì mà còn cải thiện đáng kể độ tin cậy, bảo mật và khả năng mở rộng của quy trình phân phối phần mềm của bạn. Hãy bắt đầu tái cấu trúc các hành động của bạn ngay hôm nay và trải nghiệm sức mạnh của các đường ống DRY.

Bạn cũng có thể thích

• Cách tôi thiết lập CI/CD với GitHub Actions
• Tăng cường bảo mật Runner tự lưu trữ của GitHub Actions
• Triển khai bảo mật Zero-Trust trong Kubernetes: Hướng dẫn sản xuất hoàn chỉnh
• Triển khai kiến trúc Zero Trust vào năm 2026