如何改進我們的構建和部署過程？

Question

我們的構建/部署過程非常繁瑣，充分手動且容易出錯。你能提出改進建議嗎？

因此，讓我描述我們的部署策略和構建過程。 我們正在開發名爲Application Server（簡稱AS）的系統。它基本上是基於servlet的web應用程序，它駐留在JBoss Web服務器上。 AS可以安裝在兩個「環境」中。每個環境都是一個帶有webapp代碼的目錄。該目錄放置在網絡存儲上。存儲安裝到安裝了JBoss實例的多個生產服務器上。目錄鏈接到JBoss'webapps目錄。因此，所有JBoss實例對環境使用相同的代碼。 JBoss的配置與環境是分開的，並且基於實例進行更新。

因此，我們有兩種類型的補丁：Web應用程序的補丁（針對不同的環境），並配置補丁（每個實例配置）

補丁是一個可執行文件。實際上它是帶有嵌入式二進制rpm包的bash腳本。安裝非常簡單：您只需執行文件並選擇回答一些問題。重要的一點是，修補程序不是整個系統 - 它只包含一些修正配置文件的類和/或修改配置文件的腳本。類被複制到WEB-INF /類中（AS被部署爲爆炸目錄）。

我們建立這些pathes的方法是：

1. 我們採取了一些以前的補丁文件，並複製它們。
2. 修改補丁的內容。其中最重要的部分是RPM規範。在那裏，我們更改補丁的名稱，更改其先決條件rpm包並寫下實際的bash命令以備份，複製和修改文件。這是最令人討厭的部分之一，因爲我們並不總是可以得到實際的變更。對於跨越多個變更請求和提交的新複雜功能尤其如此。另外，編寫這些變更集的命令也很乏味且容易出錯。
3. 對於webapp補丁，我們還修改了其他環境的規範。除了rpm包名以外，它們通常是相同的。
4. 我們把所有與rpm相關的文件都放到了VCS中
5. 我們通過添加一些構建新補丁的目標來修改build.xml。修改是通過複製和編輯完成的。
6. 我們通過copypasting項目並在
7. 改變Ant目標最後修改CruiseControl的配置，我們建立了一個系統

另外，我感興趣的是在貼劑和部署實踐的任何引用，最好是Java應用程序。我沒有成功使用Google搜索。

Answer 1

我工作的地方有類似的問題，但可能並不複雜。

我們的迴應是完全消除了補丁的概念。我們停止了修補程序，並開始簡單地安裝整個應用程序（即使我們只做了一點小修改）。

我們現在有巡航控制構建完成安裝工具包，恰好包含安裝套件名稱中的構建時間戳。這是巡航控制構建神器。

Cruise Control自動安裝在測試服務器上，並運行一些自動化的煙霧測試。然後我們在測試服務器上運行手動測試。然後，我們在臨時安裝產品服務器上安裝工件。

擺脫打補丁導致一些人慌張，「如果你只是在改變一些事情，這不是浪費嗎？」和「爲什麼你會覆蓋所有的軟件來修補某些東西？」

但事實是，良好的源代碼管理，自動安裝套件構建和一步安裝爲我們節省了大量時間。安裝需要幾秒鐘的時間，但我們可以更多地重複這些操作並減少開發人員的工作量。

Answer 2

我們也在嘗試轉向修補程序/修補程序版本以及發佈基於RPM的完整安裝軟件包。

我必須說我也同意，在大多數情況下，這種努力是浪費，假設您已經建立了構建管道，我還會發布完整的安裝包。

在我們的案例中，我們有一個多模塊交付，每個包裝爲一個RPM幷包裝在ISO中進行交付。我們的目標是保持我們的構建管線大部分不變，以便發佈修補程序。因此，我們將重點放在使我們的RPM更加細化（更小更有針對性的RPM），以便我們只能發佈包含某個修補程序/修補程序的已更改工件的RPM。

通過這種方式，完整版本的RPM和補丁RPM是相同的，唯一的區別是您在傳送ISO中打包的RPM數量。

我還有一個問題解決這個問題，你可以看看有：

hotfix-patch-build-delivery-approach