今日份 Ferris

今天要在我們的模板中設定 GitHub Actions，讓昨天的 make all 工作流程自動化，未來就能以此為基礎增加更多自動化工作，進而達到持續整合 (continuous integration) 與持續交付 (continuous delivery)，所以 Ferris 今天也轉起來了呢！！

GitHub Actions 在 MLOps 中的角色

MLOps 發展自 DevOps，因此許多 DevOps 的最佳實踐都能應用在 MLOps 上，而 GitHub Actions 便在此扮演著關鍵的角色，以下是它在 MLOps 中可以協助的工作：

• 自動化訓練和評估模型：GitHub Actions 可以設置定期或根據特定事件 (例如程式碼推送）觸發的工作流程，以自動化機器學習模型的訓練和評估。
• 持續整合（CI）和持續交付（CD）：GitHub Actions 可用於構建、測試和部署機器學習模型和相關程式碼。
• 自動模型版本控制：通過GitHub Actions，您可以自動化模型的版本控制，以確保每次模型訓練都有唯一的標識，並記錄訓練參數、數據集、性能指標等信息。
• 模型部署：GitHub Actions 可以協助自動化模型部署到不同的生產環境中，無論是雲上的容器化環境、伺服器、邊緣設備還是其他目標平台。
• 持續監控和反饋：一旦模型部署，GitHub Actions 可以設置自動化監控任務，以跟踪模型的性能、數據分布漂移、模型漂移等。
• 自動化文檔生成：在 MLOps 中，文檔是非常重要的一部分。GitHub Actions 可以用於自動生成文檔，包括模型 metadata、數據處理流程、訓練歷史等，以幫助團隊成員了解專案的狀態和歷史。
• 與外部工具的整合：GitHub Actions 可以與其他流行的機器學習工具和平台（如 TensorFlow、PyTorch、Docker、Kubernetes、MLflow 等）整合，以更輕鬆地執行各種 MLOps 任務，例如，自動化使用 Docker 容器封裝模型，然後將容器部署到 Kubernetes 集群。

當然，關於模型管理目前還沒有一個很完美的平台，但 GitHub Actions 確實可以加速和簡化 MLOps 工作流程，提高團隊的生產力，確保模型的質量和可維護性，並幫助實現持續交付和監控機器學習應用程序的目標。

GitHub Actions 的 YAML

昨天我們使用 Makefile 建立了 make all 的工作流程，今天我們將以此為基礎建立 GitHub Actions 的工作流程，而工作流程 (workflows) 是以 YAML 檔案進行設定的。
而這些 YAML 檔 (副檔名 .yml 或 .yaml) 會被放在 .github/workflows 資料夾中。
以下我們就用今天要實作的 YAML 檔來說明其基本結構，完整程式碼可以在 GitHub 找到：

# 工作流程的名稱
name: Rust CI/CD workflow

# 工作流程何時被觸發
on:
  # 當 push 或 pull request 到 "main" 分支時觸發工作流程
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]
  # 定期觸發，設定為每週一早上 6 點運行
  schedule:
    - cron: '0 6 * * 1'

# 工作流程是由一或多個 Job 組成，Job 可以被依序或同時執行
jobs:
  # 這個工作流程由一個名為 "rust-ci-cd-basic" 的 Job 組成
  rust-ci-cd-basic:
    name: Run Rust CI/CD basic workflow
    
    # 指定作業運行的運行器（runner）環境
    runs-on: ubuntu-latest
     
    # Job 包含一系列步驟，每個步驟都是一個執行單元
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Check Rust versions
        run: make version
    
      - name: Format
        run: make format
        
      - name: Lint
        run: make lint
        
      - name: Test
        run: cargo test --verbose

詳細說明如下：

• name：工作流程的名稱，在這裡我們命名為 "Rust CI/CD workflow"，這可以在 Actions 分頁中看到：
  

  上圖右邊則剛好是工作流程執行的三種狀態，依序是：

  • 正在執行中 🟠
  • 成功 🟢
  • 失敗 🔴

  若沒有設定名稱，則會以工作流程的文件路徑+檔案名稱命名，例如 .github/workflows/rust_base.yml

• on：指定工作流程運行的觸發事件。在這個例子中，它有三個部分：

  • push：當主分支（main）有新的推送時觸發工作流程。
  • pull_request：當主分支上有拉取請求時觸發工作流程。
    這兩個事件確保工作流程在主分支的推送和拉取請求上運行。
  • schedule：定期觸發，設定為每週一早上 6 點運行。

• jobs：工作流程由一個名為 "rust-ci-cd-basic" 的 Job 組成，但我們在其下方的 name 將其重新命名為 Run Rust CI/CD basic workflow，這會反映在工作流程的頁面中：
  
  而上圖右邊則為此 Job 的各個步驟，詳細說明在底下。

• runs-on：指定 Job 運行的運行器（runner）環境，在這個例子中，使用的是 ubuntu-latest，即最新版本的 Ubuntu 環境。

接著是各個步驟的解釋：

• Checkout code：此步驟使用 actions/checkout@v3 操作來將 repository 的程式碼 Check-out 到 $GITHUB_WORKSPACE，以使 Job 可以存取。
• Install Rust toolchain：這個步驟使用 actions-rs/toolchain@v1 操作來安裝 Rust 工具鏈，它配置為安裝穩定版（stable）的 Rust，並包括 Clippy 和 Rustfmt 組件，以用於程式碼檢查和格式化。
  感謝 @marvinhsu 大大的提醒，這部分現在已經不需要囉！順便推薦 Rust Web API 從零開始 系列 超級讚！
• Check Rust versions：此步驟運行 make version 命令，檢查 Rust 版本，以確保所需版本的 Rust 正確安裝。
• Format：此步驟運行 make format 命令，用於程式碼格式化，這個步驟將確保程式碼按照規定的格式進行排列。
• Lint：此步驟運行 make lint 命令，用於程式碼檢查，Clippy 和其他檢查工具可能在此步驟中運行，以查找程式碼中的問題並提供建議。
• Test：最後一個步驟運行 cargo test --verbose 命令，用於運行測試套件。
  這裡不使用 make test 的原因在於它捕捉了 stderr 的結果以得到更易於閱讀的結果，但這樣即使測試失敗也會在 GitHub Actions 中顯示成功，所以這裡直接使用 cargo test。

而在 GitHub Actions 成功執行後，可以在工作流程的頁面點選建立狀態徽章：

這樣就能在 README 告訴大家我們有多棒：

總的來說，在這裡我們重現了除了 make run 以外的工作流程，如此一來我們可以自動化 Rust 程式碼的檢查、格式化和測試等基本 CI/CD 任務，以確保程式碼的品質和穩定性。
而這裡也簡單介紹了如何使用與配置 GitHub Actions，未來我們可以根據需要自定義這個工作流程，例如，添加部署到生產環境的步驟等。

好啦，以上就是今天的內容，到這裡我們已經完成一個通用的 GitHub Template，未來的專案都可以用得上。
明天我們再來看看測試要怎麼做吧