持續集成和Web部署工作流程

Question

我們正在尋求改進SDLC的幾個方面。 我們現在擁有的是以下這些，這些是比幾年前還新的光明的幾年：

• 代碼：我們主要是.Net商店。 我們主要開發Web應用程序（MVC / SQL Server）。 但是我們也有一些批處理控制台應用程序。
• SCM：Git和企業GitHub。 大多數工作直接在master分支（隊列boo-hiss）中完成，但我們認識到需要轉移到分支模型。 我們將實現Vincent Driessen模型的某種風格。
• CI服務器：Team City。 一兩年前，我們的迫切需要是設置部署自動化，以避免充滿危險的手動腳本。 現在，我們使用TeamCity通過PowerShell啟動部署腳本。 （它使用msbuild來簡單地構建目標配置-標准是Debug and Release；我們在每個解決方案中都設置了Dev，QA和Prod配置-在Visual Studio解決方案中定義。）遺憾的是，我們尚未實際使用TeamCity用於其預期目的，即持續集成。 為此，我們需要實現TDD。 部署自動化從每個存儲庫的master分支中提取。
• 環境：我們有3個環境，每個環境都有專用的Web，批處理和數據庫服務器。 我們稱它們為Dev，QA和Prod。 開發是我們的測試環境。 質量檢查供最終用戶測試。 產品就是產品。 通常，我們的部署自動化可將每個應用一次推送到每個環境。 當前，它無法處理將同一應用程序推送到單個環境中的多個位置。

請注意，我們開始遇到需要並行開發的情況：一個功能正在一個分支中工作；另一個功能正在一個分支中工作。 另一個分支中的另一個； 和另一個修復程序。 顯然，掌握大師的一切都是不可接受的。

這是我想去的地方：

• 在Git中開始一個分支模型。
• 將部署自動化移出Team City，並移入自定義的強大部署工具。
• 實施TDD。
• 將TeamCity用於其預期目的，持續集成。

這些是高層目標，我對如何開始執行此工作有粗略的想法（尤其是使用部署自動化）。 但是，我遇到了一些相當大的懸而未決的問題，這些問題使我的（woo-ha-ha）總體規划感到沮喪。 因此，以下是我希望SO社區提供的意見：

1. 當您執行CI並啟動自動化測試時，您針對哪個分支？ 我認為，從理論上講，您不希望在“開發”和（顯然）“主”分支中使用“中斷”的代碼。 您是否反對CI反對“發展”或所有分支機構？
2. 在將代碼移至產品之前或之后，您是否合並為master？ 換句話說，您是從開發還是精通產品？
3. 有時我們需要測試（至少在QA中，也許在Dev中）並行更改，例如錯誤修正和功能。 您是否真的建立了多個測試網站（例如myappqa1.blah.com和myappqa2.blah.com等）？ 這些多種環境如何影響您的部署自動化？
4. 出於好奇，您是否進行每晚構建-如果是這樣，針對哪個分支？ 您是否將此夜間版本部署到任何地方？
5. 您如何打包您的應用程序（即商店版本）？ 現在，我們使用TeamCity和PowerShell對VS中定義的配置運行msbuild。 它將所有環境構建都放入一個zip文件中。 這存儲為TeamCity構建的工件。 這是我在說什么的視覺效果： 然后，另一個腳本將從zip文件中選擇合適的環境並進行部署。 我們應該以某種方式將發布包存儲在Team City或Git中（使用“發布”功能）嗎？
6. 與您的部署自動化相關聯：您是否部署了以前打包/構建的應用程序，還是一次完成了構建和部署？

非常感謝您的反饋！

謝謝湯姆

Answer 1

作為BuildMaster （一種可以在TeamCity結束后使用的工具，可能正是您所需要的工具）的開發人員，我可以嘗試回答其中的大多數問題。

當您執行CI並啟動自動化測試時，您針對哪個分支？ 我認為，從理論上講，您不希望在“開發”和（顯然）“主”分支中使用“中斷”的代碼。 您是否反對CI反對“發展”或所有分支機構？

我們遵循“按規則划分”和“按例外划分”模型，其中開發是針對“發布”分支完成的，或者針對主干/主控完成的。 功能分支也可以存在於本地開發中，但它們本身並不能構建並發布到集成中或更高版本（即，它們與“發布”分支合並在一起，無論是在主干/主分支上還是在單獨的分支上）。

您可以在“正確完成源代碼控制”中閱讀有關此過程的更多信息。

在將代碼移至產品之前或之后，您是否合並為master？ 換句話說，您是從開發還是精通產品？

強烈建議您不要為各個環境保留單獨的分支。 我知道最近所有分布式源代碼控制系統都已成為一種趨勢，但是根據我們的經驗，如果沒有特殊的紀律，就會導致很多問題。 主要問題是：丟失/遺忘的合並，從一個環境到下一個環境的不兼容合並，未經測試的代碼意外合並到新環境中，等等。

因此，為了回答這個問題，分支代碼（“按分支”）或主干/主代碼（“按例外”）是將其發布到先前的測試后推入生產的內容環境。

有時我們需要測試（至少在QA中，也許在Dev中）並行更改，例如錯誤修正和功能。 您是否真的建立了多個測試網站（例如myappqa1.blah.com和myappqa2.blah.com等）？ 這些多種環境如何影響您的部署自動化？

這種類型的測試本質上是預集成測試，因為測試人員在測試功能時並未將其與其他開發集成。 完全集成的代碼需要進行測試。 您可以具有任意數量的預集成環境，就像可以具有任意數量的本地開發環境一樣。

出於好奇，您是否進行每晚構建-如果是這樣，針對哪個分支？ 您是否將此夜間版本部署到任何地方？

是的，但是它們對於我們的團隊基本上沒有用，因為一旦您完成了構建和發布過程的自動化，就可以根據需要創建新的構建。 對於較大的團隊或面向公眾的下載，它當然會有所幫助。 該構建被適當地部署到“集成”環境。 使用的分支取決於為其創建版本的發行版。

您如何打包您的應用程序（即商店版本）？ ...我們應該以某種方式將發布包存儲在Team City或Git中（使用“發布”功能）嗎？

每個環境的單獨構建是一種反模式。 對於部署到的每個環境，部署單位應相同，但以下情況除外：

• 應用程序配置-例如.NET， web.config / App.config文件
• 基礎架構部署-例如設置IIS /網站（與應用程序部署正交，通常由Ops團隊處理，因此需要DevOps，但這是一個完全不同的主題）
• 數據庫更改-這些更改本身具有特殊性，因為一旦您DROP一列，就無法再次刪除它。 您可以在以下文章中了解有關這些內容的更多信息： 正確完成數據庫更改

與您的部署自動化相關聯：您是否部署了以前打包/構建的應用程序，還是一次完成了構建和部署？

通用方法是將構建和部署分開。 對於簡單的網站（即手冊網站），無需進行區分，“連續生產”就足夠了。

當其他零件需要組合在一起時，這當然會變得模糊。 例如，發布BuildMaster軟件需要安裝程序供公眾使用。 直到更高版本的環境才使用安裝程序，通過預打包的構建工件（也可以使用安裝程序）將其部署到較早的環境。 在這里，從一開始就保持一個部署單元（即工件集），就可以輕松地將其部署到有或沒有安裝程序的任何環境中。

TL，DR-很難概括如此廣泛的主題...但是，如果您希望在不進行大量前期投資的情況下開始使用，我建議您查閱一下由同事撰寫的這份新的增量連續交付論文 。