一千萬個為什麽

搜索

敏捷方法論,CI/CD如何應用於大規模,單片式軟件項目,開發人員數量為100人/ 1000人?



使用持續集成代表了軟件項目敏捷的(幾乎)強制性要求。沒有CI,就不會有連續的交付/部署。

但CI可以面對可擴展性挑戰,請參閱如何才能持續整合規模非常大的項目/團隊?

在多個較小的預集成分支上分割工作將允許這些分支的工作變得敏捷,但是那些需要處理的是那些預集成分支的合並。而這些將是巨大的,不可預知的合並,很難計劃並納入到敏捷框架中。直到合並完成

那麽敏捷方法仍然可以如何應用於大規模,單片式軟件項目,開發人員數量為100人/ 1000人?

轉載註明原文: 敏捷方法論,CI/CD如何應用於大規模,單片式軟件項目,開發人員數量為100人/ 1000人?

一共有 4 個回答:

那麽,你將無法將敏捷方法應用於大型團隊。通常的原則之一是在比薩團隊工作(少於10人可以共享大餐披薩),因為缺乏敏捷過程所倡導的形式主義使其難以適用於大型團隊,信息會散亂而且有些會在人群中流失。

因此,在考慮CI系統之前,您必須查看圍繞您構建的軟件的組織 這主要需要用較小的獨立部分來重構大型項目,這可能是單獨的軟件(並且您將采用 microservices ),或者它可能只是一個軟件中的架構設計,其中一個類/對象/庫被提供給一個小團隊。該團隊必須記錄其服務輸入和輸出(服務合同/服務方向)。

一旦完成,您可以將每個獨立作品的責任分割為一個能夠應用敏捷過程的較小團隊 這可以解決CI/CD問題,拆分代碼庫將允許每個團隊按照自己的步調進行操作,只要它的界面已經正確版本化並且輸入/輸出對於某種類型的呼叫是固定的,產品發展,而其他部分保持以前的行為。

主要缺點是每個部分的服務契約必須在使用的版本之間兼容,這些版本需要一個依賴系統來知道哪個部分在丟棄未使用的API版本之前使用哪個版本的內容。這帶來了突破性變化的問題,並且通常需要生產者和消費者之間謹慎的橫向規劃。

我們從一個由100多名開發人員開發的大型單一後端應用程序轉變為基於Docker的微服務,使用類似DevOps絨毛的部署。以下是有關該過程的一些註意事項:

  1. 確定整體應用內的域邊界。確保邊界之間的調用盡可能少(通過調用我的意思是要麽是進程內調用,要麽是數據庫訪問)。
  2. 將開發人員拆分為團隊,並為他們分配一個域的一部分。 (一個域也可能在多個團隊中工作)
  3. 指定跨界調用仍然發生,並在其周圍定義一個API。確保跨域調用時僅使用此中間庫。
  4. 對這些中間庫進行適當的測試,檢查它們是否正常工作。
  5. 根據這些域分割代碼。

現在,您的每個團隊都應該更小,並且在處理他們的代碼時不必擔心其他問題。您放入這些中間庫的測試應該包括來自外部調用者的回歸,內部代碼是您的責任。顯然,如果中間庫需要更改,或者如果測試表明您不再遵守API規範(可能並且偶爾會發生),那麽您需要使用這些API與其他團隊開始交談。

一旦你開心,你可以嘗試用這些中間庫代替HTTP API調用而不是進程內調用。完成此操作後,實際上可以將大型應用程序拆分為真正的小型應用程序(它們可能仍然不是“微型”服務,但更小巧,更易於管理)。此外,他們至少會屬於一個特定的域,並且還有一個明確的,定義明確的API,其他人(包括新的微服務大多不含您的傳統大應用)可以用來獲取他們的數據。

是的,將更大的團隊分成更小,更靈活的子團隊顯然是必要的。但是在團隊層面更大的情況下,整體表現還不夠。

With a highly scalable CI system in place it is possible even for very large teams to use trunk-based integration, in a single master branch, thus completely avoiding the intermediate integration branches and the unknowns/risks/delays/costs associated with their merges which would otherwise represent serious obstacles impacting the sub-teams. See How can continuous integration scale for very large projects/teams?

有了這些障礙,子團隊可以真正發揮敏捷技術的最大優勢,因為它們自動地處於同一頁面,並且受益於CI方法的 all 優勢。

這種方法同樣適用:

  • 針對單片式編解碼器/產品,無論出於何種原因都無法/不會將其分解為微服務
  • 將代碼庫/產品分解為微服務,即使除了獨立部署功能之外的原因,它們不想處理服務間依賴關系管理,也不願意堅持單一部署(它們仍然共享相同的開發分支)

註意:實際的SCM存儲庫是無關緊要的,它可以是作為一個單獨管理的Repos的任意組合,術語分支表示該組合中存在的任何物理/實際回購分支的公共邏輯表示。

我一直在與100多名開發人員合作幾個敏捷項目,沒有任何問題,所以從我的個人經驗來看,要處理這麽大的工作流程,這裏有一些建議:

  • Team definitely should to be split (max. ~12 people each).

    Make sure you've the right people with the right skills in each team, so they're independent (cross-functional teams). DevOps doesn't have to be part of development teams.

  • Each team should work on their own components/modules, so their work won't conflict with other teams.

  • Once feature/component or bug is completed and tested in separate branch, developer should be responsible for sending and maintaining a valid mergeable Pull Request to be approved by other team members.
  • Often commits and pulling from master branch will avoid any surprises about code conflicts.
  • Each Pull Request should be automatically tested in CI and once approved, should be merged (either development or master branch).
  • Deployment to development branch should be done on each Pull Request being merged and tested on development environment by automated tests and manually, so only stable code can progress upstream.

總而言之,為避免在合並復雜分支上花費太多時間,引入 Pull Request ,以便每個請求者負責他自己的代碼的可合並性,其他開發人員負責審查更改,因此在這種情況下不可能出現不可預測的分支或沖突。

所以,是的,敏捷方法可以擴展到大規模項目。