指南：小型團隊的軟件發布管理

正式化發布管理流程（如果有的話）

在某些團隊配置中，尤其是在初創公司中發現的團隊配置中，沒有 DevOps 或基礎架構工程師在發布產品的新版本時提供支持。

此外，與具有明確正式流程的大型官僚公司不同，初創公司的 CTO 或軟件開發團隊負責人通常不了解軟件發布管理流程的複雜性； 公司中的少數開發人員可能知道該過程的複雜細節，但不是所有人。 如果這些知識沒有被徹底記錄下來，我相信它可能會導致混亂。

在本文中，我將嘗試提供一些關於如何規範發布過程的技巧，尤其是從開發人員的角度來看。

輸入軟件發布清單

根據 Atul Gawande 的書Checklist Manifesto ，您可能熟悉某些操作的清單的概念。 我相信正式的發布過程（就像軟件開發世界中的許多其他任務一樣）為開發人員提供了實施該協議的機會。 發布過程清單應保存在共享文檔中，最好以協作 wiki 或 Google Drive 上的電子表格的形式保存。

通過與團隊共享此重要文檔並授予編輯權限，每個成員都可以訪問正式定義的發布流程。 這使他們能夠了解該過程是如何工作的。 此外，在與其他團隊成員討論之後，它使團隊能夠不時地對其進行改進。 這應該帶來透明度，並允許整個團隊實時訪問發布期間發生的事情、已完成的步驟以及由誰完成。

通過查看此電子表格，利益相關者可以根據步驟的結果來決定“去”還是“不去”。 例如，如果測試環境中的壓力測試出錯，項目經理可能會根據事件決定取消生產版本。

用作基礎的建議步驟

在本節中，我將提出一些步驟，您可以使用這些步驟為您的發布過程構建您自己的清單。 其中一些步驟絕不是強制性的。 每個應用程序都不同，每個組織的工作方式也不同，因此請隨意調整併做出更適合您的工作流程的更改。

1.創建發布分支

您可能熟悉 Git Workflow 的概念，或者熟悉發布分支的概念，這個主題已在之前的博文中解釋過。

理想情況下，您應該至少有三個分支：

• master ：這應該反映生產環境中的當前狀態。 master上的每個新提交都應該只包含一個新版本。
• 開發：這個分支應該包含已完成（和測試）即將推出的功能。 通常為每個功能創建一個單獨的分支，然後在功能準備好時將其合併以進行開發。
• release ：發布分支是準備發送到生產環境的提交的集合，以及與發布相關的一些額外的小錯誤修復。

請注意，發布完成後應該刪除發布分支，因此這些分支一直被創建和銷毀，與master或develop不同，它們總是相同的。

為了創建一個新的發布分支，在你的 git 終端的開發分支中，輸入：

$ git checkout -b release/xyz

使用命名約定很方便，例如上面定義的命名約定，根據您的需要將 xyz 替換為 major.minor.patch 版本號（這是您應該在團隊中定義並堅持的策略）。

同樣重要的是，如果您將一些錯誤修復編碼到發布分支中，您不應該忘記將它們合併回​​develop 。 發布分支的主要目的是預覽應用程序在投入生產後的行為方式。

2.凹凸版

下一步是在發布分支上增加（修改或增加）版本號。

您應該打開 AndroidManifest.xml / package.json / pom.xml / 或應用程序版本存儲在項目中的任何位置 (YMMV)，更新版本號，然後將更改提交到當前發布分支。

出於兩個原因，更新版本號很重要。

首先，您可以跟踪和映射每個版本中引入的功能，其次，如果他們需要進行一些故障排除或聯繫您尋求支持，您將了解他們正在使用的版本。 如果你正在構建一個移動應用程序，你在這一步更新的版本號通常會顯示在用戶端，在關於部分或者在Google Play或Apple App Store中。這一步也是更新環境依賴的好機會- 配置文件（儘管我建議將它們保存在單獨的存儲庫中），例如將分支指向生產數據庫，或構建過程所需的任何其他調整。

最後，建議您將發布分支推送到 origin，以便您的其他開發人員可以使用它：

$ git push -u origin release/xyz

3a。 將發布分支合併到 master 並標記它

只有master分支應該部署到生產環境中，因此在這一步中，我們需要將發布分支合併到master中。

 $ git checkout master $ git merge --no-ff release/xyz $ git push

--no-ff標誌是可選的，但是，建議使用它以強制創建新的提交對象，即使可以使用快進技術完成合併。

接下來，是時候在master分支上標記發布了：

$ git tag -a xyz -m 'description of new version, features or fixes included'

標籤很有用，因為您在 git 存儲庫中保留了歷史中的這個特定點，您可以稍後再回來從特定標籤重新創建一個單獨的分支。

3b。 使用拉取請求合併發布分支

另一種經常使用的替代方法是使用拉取請求將發布分支合併到master中。

這種方法有很多優點。 為協作創建了一個新空間，團隊可以使用它來討論各種與發布相關的問題。 此時是為合併代碼審查過程添加額外入口的好時機，同時有更多的眼球來監控將要引入的代碼，並討論潛在的修改。

GitHub、Bitbucket 和 GitLab 是一些允許您在工作流程中實現拉取請求的工具（合併請求，因為他們在後者上調用它）。 使用這些工具，您無需手動鍵入 git 命令，而是使用 Web 界面設置源分支 ( release ) 和目標分支 ( master )，然後添加一個或多個審閱者，所有審閱者都會能夠對這些新變化寫內聯評論，提出改進建議等。

在所有審閱者批准拉取請求後，您可以通過按 UI 上的按鈕自動將更改合併到master中。

4. 將Master部署到生產環境

在此階段，最好讓團隊中的測試人員在部署應用程序之前進行冒煙測試（這可以在單獨的檢查表中定義）。 一個好的建議是將主分支部署到單獨的測試環境中。 然後，測試人員可以執行一些基本操作，以確保在最新版本合併後沒有出現任何問題。 如何進行冒煙測試超出了本文的範圍，但您可以在網上找到很多關於它的資料。 冒煙測試的結果可以集成到發布清單/電子表格中，記錄任何出錯的地方。

此時，您已準備好部署更改並使其生效。 繼續部署主分支。 此步驟將取決於您使用的基礎架構堆棧。 它可能涉及連接到您的 Amazon EC2 實例以上傳您的應用程序，或推送到 Heroku 遠程，或通過 ssh 連接到您的 VPS 以復制新版本，或任何其他過程。

上傳應用程序後，確保它已成功部署並按預期工作。

5. 合併回開發和刪除發布分支

現在發布幾乎完成了，您需要將發布分支合併到開發中，以更新後者的版本號並將所有錯誤修復轉移到主開發分支：

 $ git checkout develop $ git merge release/xyz

現在是時候刪除發布分支了：

$ git branch -d release/xyz

6. 變更日誌生成

在項目的根目錄下應該有一個名為 CHANGELOG.md（或等效文件）的文件，每當有新版本時，您都應該在其中添加一個新條目，以記錄其中包含的所有內容，例如錯誤修復、新功能、已知問題，以及發行說明形式的任何其他相關信息。 這對於用戶和貢獻者查看項目的每個版本（或版本）之間進行了哪些更改非常有用。

變更日誌條目包括日期、版本號和有關發布的一些註釋。 條目應按時間倒序排列。 這是我一直在使用的一個簡單模板，您可以根據自己的項目進行調整：

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

此外，這一步可以通過編寫一個遍歷 git log 並自動生成 changelog 條目的基本腳本來完全自動化，也可以通過使用執行相同操作的工具來實現，例如：

• Github Changelog 生成器，由 skywinder 提供，
• fojuth 的 ReadmeGen
• github-changes，作者 lalitkapoor

但請記住，您獲得的自動化程度與提交消息格式的嚴格程度成正比。 我相信與團隊就提交消息的特定格式達成一致始終是一種好習慣。 通過遵循有關提交消息樣式的準則，它們將更容易解析，因此您更有可能能夠自動生成更改日誌。

7. 與利益相關者溝通

這是您通常會執行以下操作的地方：

• 通過內部消息傳遞工具（例如：Slack）讓團隊知道新版本已經完成。 我建議創建一個新頻道（即： #releases ），其唯一目的是傳達與發布相關的事件。 在採取行動後，很容易在 Slack 頻道中添加掛鉤以發布消息。
• 或者，向利益相關者發送一封電子郵件，其中包含指向更改日誌或附加更改日誌文件的鏈接。
• 寫一篇博文（如果你的應用或產品有博客）或推文。

根據組織的性質，可以採取更多行動。 重要的是不要忘記傳達您的產品有新版本可用。

8. 梳理問題跟踪器

執行發布後，您可能需要更新某些工單的狀態，以跟踪當前生產中的錯誤修復或功能。 通常，這涉及更改一些標籤（對於小型項目，我使用發布待定標籤，在發布完成後我將其刪除）。

如果您為每個新版本使用里程碑，您可能需要更新其狀態或將其標記為已完成。 一些問題跟踪器甚至可以讓您計劃發布並將其與 sprint 保持一致，跟踪錯誤是否阻礙了發布以及其他有用的信息。

這完全取決於您如何使用該工具。 我只想指出，更新問題跟踪器中的信息的任務應該包含在您的發布清單中。

關於自動化發布過程

讀者可能已經註意到，除了上面概述的更改日誌步驟之外，上述許多步驟也可以自動化。

自動化發布過程的某些部分的能力是一個巨大的勝利，並節省了大量時間。 我建議創建腳本，或者弄清楚如何自動化各個步驟，然後朝著持續交付目標努力。 持續交付可以降低風險、降低成本並減少開發人員在管理髮布方面需要花費的時間。 因此，就分配給開發的時間而言，您將能夠更頻繁地發布並提高生產力。

DevOps 公司的聖杯是能夠通過按下一個按鈕（或運行一個命令）來啟動一個新版本，該按鈕會自動觸發發布過程，或者更好的是，一個系統會在某個時間發布你的軟件的新版本。指定時間。 當然，這很難實現，因為您還需要自動化很多測試過程，但這並非不可能。

採用最佳實踐

在本節中，我將描述一些我認為方便的推薦實踐，以使發布過程更順暢，或者在出現問題時採取安全措施。

尋找最適合發布的日子

我通常在星期四中午和下班之間發布我正在開發的應用程序。

如果您週一至週五工作，那麼在周五啟動並不是一個好主意。 如果發布後出現問題，您將在周一之前沒有時間修復它（除非您想在周末工作）。 這就是為什麼在星期四發布更方便，因為您有星期五在部署後監控新版本、修復任何問題或進行回滾。

如果您正在管理 Web 應用程序，另一件重要的事情是要知道您的大多數用戶所在的時區。 您應該在流量較低的時段安排發佈時間，以盡量減少出現故障時的潛在損害。 有時，當您的用戶群遍布全世界時，這可能會很棘手，但無論如何，您應該做一些研究並確定最佳時間。

在新版本發布之前備份您的數據庫

如果您沒有計劃定期備份數據庫，我強烈建議您在發布過程中添加一個步驟，以便在開始發布之前執行備份。

分階段推出

有沒有想過，為什麼當出版商宣布他們推出了一項新功能時，您的手機需要幾天甚至幾週的時間才能使用該功能？ 這是因為許多公司使用分階段推出。

Facebook 已經這樣做了很長時間。 它在 5% 或 10% 的用戶上測試一項新功能，然後逐漸增加，直到達到 100% 的用戶群。 在分階段推出階段，您需要仔細查看用戶反饋和崩潰報告。 有了這些信息，您就可以在錯誤影響到每個用戶之前推遲發布或修復錯誤。

Android 的開發者控制台上有一個很好的工具，可以為您的 Android 應用實現分階段部署。

持續集成

持續集成是一種值得擁抱的實踐，原因有很多。 首先，它可以讓您及早發現錯誤，從而提高成功發布的比率。 其次，這是在實施如前所述的持續交付和完全自動化之前的第一個合乎邏輯的步驟。

Martin Fowler 是持續集成的大力倡導者。 他描述了在使用這種做法時可以為您的發布過程添加的大量好處。 這是一個很大的話題，有很多關於它的書籍和博客文章，我在這裡提到它是因為我相信它會讓您對您的運營更有信心。 在使用 CI 的眾多優勢中，您會發現：降低風險、提高可見性以了解哪些工作正常、哪些不工作、更早地檢測錯誤、提高部署頻率等等。

實施 CI 的出發點是建立一個“持續集成服務器”； 可以嘗試的一些不錯的工具是：CruiseControl、Bamboo、Jenkins 和 Travis。

尾聲：一切都會好起來的

積極地，我們都捍衛我們所扮演的角色遺憾的是，時代已經到了，我們已經看到了這一切，信任的篝火，陣陣的痛苦這並不重要，你不用擔心，它會一切都解決了

出口曲，殺手

最後，我想說的是，為您的應用程序制定明確的發布流程非常重要，無論其複雜性、用戶群或您的組織有多小。

如果您不這樣做，我建議您開始考慮一些基本步驟，使用本指南和其他類似指南，並與您的團隊一起集思廣益以提出初稿。 在您的下一個版本中嘗試一下，然後進行迭代。 最終，您將構建自己的發布流程。

之後，開始考慮如何自動化部分流程。 想想可以改進的地方。 探索通過合併小的優化來減少發佈時間的方法。 自動化應該是您的最終目標； 但是，不要從一開始就計劃，否則你會因為嘗試如此大的飛躍而失敗。 與每個過程一樣，最好逐漸改進它。

您是否有任何其他技巧或指南用於啟動應用程序的新版本？ 如果是這樣，請告訴我。 我不是來自 DevOps 世界，我只是一個開發人員，恰好組織和結構化，但與許多老手相比，我在這方面仍然是新手，所以如果你有任何評論或聯繫我要補充的東西。