如何通過連續部署自動化項目版本並發布

採用語義化版本控制能更輕鬆地維護和溝通軟件變更，但手動操作卻很繁瑣。即使手動合併PR、標記提交並推送發布，仍然需要編寫發布說明。步驟眾多，且重複性高，耗時費力。

本文將介紹如何通過將語義化版本控制集成到持續部署流程中，實現更高效的流程並完全自動化發布流程。

語義化版本控制

語義化版本是一個由三個數字組成的版本號，例如1.4.10。每個數字都有特定的含義：

主要版本變更(Major)

第一個數字表示主要版本變更，意味著存在破壞性變更。

次要版本變更(Minor)

第二個數字表示次要版本變更，意味著添加了新功能。

修補版本變更(Patch)

第三個數字表示修補版本變更，意味著修復了bug。

可以將語義化版本更簡潔地理解為：破壞性變更.功能變更.錯誤修復。這種描述方式更精確，避免歧義。

提交信息格式

為了確保正確遞增語義化版本號並發布正確版本，需要標準化提交信息格式。標準化的提交信息格式有助於確定何時遞增哪個數字，並輕鬆生成發布說明。這裡將使用Angular 提交信息約定，當然也可以根據需要更改。

格式如下：

<code></code>

每個提交信息包含標題、正文和腳註。

提交標題

標題是必須的，它具有特殊的格式，包括類型、可選的範圍和主題。

標題的類型是必填字段，用於說明提交內容對下一個版本的影響。它必須是以下類型之一：

• feat : 新功能
• fix : bug 修復
• docs : 文檔變更
• style : 不影響代碼含義的變更（例如：空格、格式、缺少分號等）
• refactor : 代碼重構，既不修復bug也不添加功能
• perf : 性能改進
• test : 添加或修正測試
• chore : 構建流程或輔助工具和庫的變更，例如生成文檔

範圍是一個分組屬性，用於指定提交相關的子系統，例如API、應用程序的儀表板或用戶帳戶等。如果提交修改了多個子系統，則可以使用星號(*) 代替。

標題主題應簡要描述所做的更改。編寫主題時需遵循以下規則：

• 使用祈使句，現在時態（例如，“更改”而不是“已更改”或“更改”）。
• 首字母小寫。
• 末尾不加句點(.)。
• 避免主題長度超過80 個字符。提交正文。

與標題主題一樣，正文也應使用祈使句，現在時態。它應包括更改的動機，並將其與之前的行為進行對比。

提交腳註

腳註應包含任何有關破壞性變更的信息，也是引用此提交關閉的問題的地方。

破壞性變更信息應以BREAKING CHANGE: 開頭，後跟空格或兩行新行。其餘提交信息在此處。

強制執行提交信息格式

在團隊協作中，標準化任何需要每個人都遵守的內容始終是一項挑戰。為了確保每個人都使用相同的提交標準，我們將使用Commitizen。

Commitizen 是一個命令行工具，它簡化了使用一致的提交信息格式的過程。使倉庫與Commitizen 兼容意味著團隊中的任何人都可以運行git cz 並獲得詳細的提示以填寫提交信息。

生成發布

現在我們知道我們的提交遵循一致的標準，我們可以開始生成發布和發布說明了。為此，我們將使用名為semantic-release 的包。這是一個維護良好的包，對多種持續集成(CI) 平台具有良好的支持。

semantic-release 是我們旅程的關鍵，因為它將執行發布所需的所有步驟，包括：

1. 確定您發布的最後一個版本
2. 根據自上次發布以來添加的提交確定發布類型
3. 為自上次發布以來添加的提交生成發布說明
4. 更新package.json 文件並創建與新發布版本對應的Git 標籤
5. 推送新版本

任何CI 都可以。在本文中，我們使用GitHub Action，因為我喜歡在尋求第三方解決方案之前使用平台的現有功能。

安裝semantic-release 的方法有很多，但我們將使用semantic-release-cli，因為它提供了逐步操作。讓我們在終端中運行npx semantic-release-cli setup，然後填寫交互式嚮導。

該腳本將執行以下幾件事：

• 使用提供的NPM 信息運行npm adduser 以生成.npmrc。
• 創建GitHub 個人訪問令牌。
• 更新package.json。

CLI 完成後，它會將semantic-release 添加到package.json，但不會實際安裝它。運行npm install 以安裝它以及其他項目依賴項。

剩下的唯一事情是通過GitHub Actions 配置CI。我們需要手動添加一個將運行semantic-release 的工作流程。讓我們在.github/workflows/release.yml 中創建一個發布工作流程。

 <code>name: Release on: push: branches: - main jobs: release: name: Release runs-on: ubuntu-18.04 steps: - name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci - name: Release env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # If you need an NPM release, you can add the NPM_TOKEN # NPM_TOKEN: ${{ secrets.NPM_TOKEN }} run: npm run release</code>

Steffen Brewersdorff 已經出色地介紹了使用GitHub Actions 進行CI，但讓我們簡要回顧一下這裡發生的事情。

這將等待對主分支的推送發生，然後才運行管道。可以隨意更改此設置以在一個、兩個或所有分支上運行。

 <code>on: push: branches: - main</code>

然後，它使用checkout 拉取倉庫並安裝Node，以便npm 可用於安裝項目依賴項。如果這是您偏好的內容，則可以添加測試步驟。

 <code>- name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci # You can add a test step here # - name: Run Tests # run: npm test</code>

最後，讓semantic-release 完成所有神奇的操作：

 <code>- name: Release run: npm run release</code>

推送更改並查看操作：

現在，每次對指定分支進行提交（或合併）時，操作都將運行並進行發布，並附帶發布說明。

發布派對！

我們已經成功創建了一個CI/CD 語義化發布工作流程！是不是沒那麼痛苦？設置相對簡單，擁有語義化發布工作流程沒有任何缺點。它只會使跟踪更改變得容易得多。

semantic-release 還有許多插件可以實現更高級的自動化。例如，甚至還有一個Slack 發布機器人，可以在項目成功部署後發佈到項目頻道。無需前往GitHub 查找更新！

以上是如何通過連續部署自動化項目版本並發布的詳細內容。更多資訊請關注PHP中文網其他相關文章！