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

Question

我們正在尋求改進我們的SDLC的幾個方面。我們現在所擁有的是以下內容，這些都是相當新十歲上下光年超出了我們幾年前有：

• 代碼：我們主要是一個.net店。我們主要開發Web應用程序（MVC/SQL Server）。但我們也有一些批量控制檯應用程序。
• SCM：Git和Enterprise GitHub。大部分工作直接在主分支（隊列boo-hiss）中完成，但我們認識到需要轉移到分支模型。我們將實施一些Vincent Driessen's model的味道。
• CI服務器：Team City。我們在一兩年前的迫切需求是設置部署自動化以避免危險的手動腳本。我們現在使用TeamCity通過PowerShell啓動部署腳本。 （它使用msbuild來簡單地構建目標配置 - 標準是調試和發佈;我們已經在每個解決方案中設置了Dev，QA和Prod配置 - 在Visual Studio解決方案中定義。）可悲的是，我們尚未實際使用TeamCity的目標是持續集成。爲此，我們需要實施TDD。部署自動化從每個存儲庫的主分支中抽取。
• 環境：我們有3個環境，每個環境都有專門的Web，批處理和數據庫服務器。我們稱他們爲Dev，QA和Prod。 Dev是我們的測試環境。 QA供最終用戶測試。 Prod是prod。通常，我們的部署自動化將每個應用程序推送到每個環境一次。它目前無法處理將同一應用推送到單個環境中的多個位置。

請注意，我們開始有一些情況需要進行並行開發：一個功能正在一個分支中進行;另一個分支的另一個;並在另一個修補程序。很顯然，在主人身上做任何事情都是不可接受的。

這裏就是我想去：

• 在Git中開始一個分支模型。
• 將部署自動化從團隊城市遷移到自定義的強大部署工具。
• 實施TDD。
• 使用TeamCity的目的，持續集成。

這些是高層次的目標，我對如何開始這樣做（特別是對於部署自動化）有粗略的想法。但是，我有一些相當大的突出問題令我（嗚哈哈）總體規劃受挫。因此，下面是我喜歡從SO社區輸入的項目：

1. 當您執行CI並啓動自動化測試時，您會針對哪個分支執行此操作？我在理論上認爲，你不想在你的「發展」和（明顯）「主」分支中「破碎」的代碼。你是否反對CI開發或所有分支機構？
2. 您是否在之前或之後將您的代碼合併爲主？換句話說，你是從發展還是主導推動？
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的 反對「發展」或所有分支？

我們遵循「分支的規則」和「分支通過的異常」模型，其中開發完成要麼反對「釋放」分支，或者是針對主幹/主做。功能分支也可以存在以用於本地開發，但不是自己構建併發布到集成和超越（即，它們與「發佈」分支合併在一起，無論它是在中繼/主設備還是單獨的設備上）。

您可以在Source Control Done Right中閱讀關於此過程的更多信息。

在將代碼移動到產品之前或之後，您是否合併到主設備中？換句話說，你是從發展還是主導推動？

強烈建議您不要爲單獨的環境保留單獨的分支。我知道，最近隨着所有分佈式源代碼管理系統的出現，這種趨勢正在成爲一種趨勢，但是從我們的經驗來看，如果不採用特殊的規則，它會導致許多問題。主要問題是：缺失/遺忘的合併，從一個環境到下一個環境的不兼容合併，未經測試的代碼偶然合併到一個新的環境中，等等。

所以要回答這個問題，分支代碼（用於「分支規則」）或中繼/主代碼（用於「分支異常」）是在它被釋放之後被投入生產的東西到以前的測試環境。

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

這種類型的測試本質上是一種預集成測試，因爲測試人員正在測試功能，而不將它們與其他開發集成。完全集成的代碼是需要測試的。您可以擁有任意數量的預集成環境，就像您可以擁有任意數量的本地開發環境一樣。

只是出於好奇，你是否每晚都做 - 如果是的話，針對 什麼分支？你是否在任何地方部署這個夜間生成？

是的，但它們對於我們的團隊基本上是無用的，因爲一旦你自動生成&釋放過程，是微不足道的創造新的基礎，因爲他們是必要的。對於較大的團隊或面向公衆的下載，當然可以有所幫助。構建適合部署到「集成」環境。使用的分支由構建的創建版本決定。

如何打包您的應用程序（即商店發佈）？ ...我們是否應該在Team City或Git（使用「發佈」 功能）中以某種方式存儲發行包？

每個環境的獨立構建是一種反模式。部署的單位應該是每一個部署到環境一樣，用當然存在的例外：

• 應用程序配置 - 如.NET，web.config/App.config文件
• 基礎設施部署 - 如設置（這與應用程序部署是正交的，通常由Ops團隊處理，因此需要DevOps，但這是一個完全不同的主題）
• 數據庫更改 - 這些都是特殊的，因爲一旦你DROP a列，它不能再被丟棄。您可以閱讀更多有關這些：Database Changes Done Right

相關，與您的部署自動化：你部署之前 包裝/內置應用程序，或者你構建和部署所有一舉？

常用的方法是分開構建和部署。對於簡單的網站（即手冊網站），不需要做出這種區分，「連續生產」就足夠了。

當其他零件和零件需要放在一起時，這當然會變得模糊不清。例如，發佈我們的BuildMaster軟件需要安裝人員才能使用。直到後來的環境，安裝程序才被使用，通過預打包的構建工件（安裝程序也使用該工件）完成到早期環境的部署。這是從一開始就保持單個部署單元（即一組工件）的地方，可以輕鬆部署到具有或不具有安裝程序的任何環境。

TL，DR - 這真的很難概括這樣一個廣泛的話題......但我建議檢查出，如果你希望得到沒有大量投資的前期啓動的一位同事撰寫的這個新Incremental Continuous Delivery paper。