持續集成 - 構建分離的項目還是全部集成在一起？

我工作的一個項目，都會有這些應用程序：持續集成 - 構建分離的項目還是全部集成在一起？

- backend api (nodejs) 
- ios app  (objective-c) 
- android app (java) 
- web site  (php) 
- admin site (php) 
- client site (php)

我的問題是關於版本和管理所有這些項目。

我在考慮兩個選項：

1）建立每個應用saparately

更難測試應用程序的集成
如果我在一個應用程序改變的東西，我需要小心所有其他應用程序
我需要將所有應用程序更新日誌合併到一個文檔中

2）把所有的應用程序到一個單一的構建

這似乎不錯，生成單一的changelog
也許寫測試應用程序集成？

那麼，究竟是什麼情況下，一些好的做法？也許選項2？

來源

2015-06-15 anderlaini

我投票去選擇2到許多在其各個階段的「進位」的發展與單片方法簡單：

簡單的集成 - 所有的作品都已經集成，大家對任何一件工作整個項目不在自己的沙箱中（真持續集成，如果你想的話） - 非常重要的，如果你也打算使用敏捷方法
集成測試不再是一個單獨的活動，你可以做到這一點的一部分經常CI過程，因爲你可以一起測試所有組件（可能用一個組合測試牀而不是每個組件的專用測試牀 - 成本較低）
更簡單的相干/一致的源代碼控制（即使零件有自己的回購，他們可以可以在整體風格統一管理的就像我在這個問答&一個建議： Build dependencies and local builds with continuous integration
可能更快的整體構建（不同的構建可以使用的空閒週期其他建立是困難時，他們獨立編排 - 他們可能可能會更好「打包」，導致 c減少建設資源）

來源

2015-06-16 01:52:14

我同意你所說的一切。這是現實世界中的普遍做法嗎？將不同的應用程序構建成單個部署包我正在尋找一些關於這方面的文章，但沒有找到任何東西 – anderlaini

尚不常見（來自實施前景）。單個部署包中的多個應用程序：新鮮/最初的Linux發行版，幾乎每個複雜/高級的嵌入式系統，安裝或升級都是「單片」（用於檢驗計算/存儲/網絡/軍事裝備）。實際上它並不需要成爲一個單一的部署包（除非你真的指的是一組或多或少相關的包，它們恰好一起部署）。這些概念在這裏：http://www.martinfowler.com/articles/continuousIntegration.html –

我絕對不會選擇2.繼續整合是由90年代初期的Grady Booch所稱。今天，他們想要使用術語持續交付。我說我們應該一直使用持續改進。無論如何，您希望能夠交付，部署，投入生產應用程序，項目，「可交付成果」。你絕對不想混用應用程序。您可能需要將一個應用程序部署到生產環境中，而另一個應用程序出現問題。或者你只是對一個應用程序做了一個非常快速的修復，並且你想通過這個過程來完成今天的交付。由於這些原因，我不會選擇選項2。

來源

2015-08-19 03:58:51

持續集成 - 構建分離的項目還是全部集成在一起？

回答

相關問題