logo头像

Edward.K Thinking

(學習DevOps系列 13) 關於Package Management


程式碼或是系統要開始做Package管理會是一大學問,為什麼要做Package Management?開發好好就開啟專案開始寫就可以啊!!不過,會發現當一個產品或是系統逐漸擴大時候,或是開發團隊成員開始擴大且又加上現在開發團隊不一定會在同一個區域,除此之外,程式碼也會開始變多且專案也變得更廣,甚至,同一套系統已經開始在不同團隊進行開發,又或是企業內發現同一種邏輯或是商業行為會被擴展到多個系統,諸如此類的情境越來越多,就表示團隊合作會走向另一個層次了,在整個DevOps流程,將會會意識到幾點問題

  • 團隊開如何有效共享或是重複使用相同元件
  • 如何讓每個團隊開發的功能能快速迭代又不影響他人
  • 如何讓團隊擁有自主權能快速迭代

這些問題問題不僅僅會發生在新的團隊身上,對於有歷史包袱的開發團隊依舊會這樣問題產生。主要在於開發團隊都會被要求能夠更快,提供有價值的系統給客戶。不僅僅合作範圍更大,速度也越快了。因此,在Package Management範疇中,不僅僅要考慮到系統進行元件化,也考慮到如何把系統拆分到耦合性最小,元件化可以建構一個容易被擴展到團隊或是其他團隊的快速開發模式,也能符合今日迭代速度的流程。藉由元件管理方式將可以幫助我們管理系統外部依賴和隔離共享元件的風險。另外一點,整個耦合性降低時,在於持續整合方面也將會讓速度加快且更好釐清問題


元件化是將系統或是產品依照功能或是商業邏輯去區分與建構小單元的開發方式。大多數的.NET專案中或多或少都已經提供這樣的概念。又像是我們會拆分前端、後端以及資料庫,做一個比較粗略的元件化區隔,讓彼此間的耦合性盡量降低。在.NET開發模式中,通常我們使用solution + project方式建構我們的專案,當開發的系統或是產品的擴大,這樣將可能讓效率上會變得越來越低,且整合編譯的時間會越來越長,並且可能更難以合併。甚至在某些情況下,IDE速度將會變得更慢。尤其,當我們的project必須參考到多個solutions時候,往往會造成開發某些的困難。例如,當Solution A必須仰賴solution B,且是參考solution B編譯好的元件來使用。這時候,將必須先將solution B進行編譯後才可以讓Solution A編譯成功,當然,做到這件事情技術本身並不難,可以進行用下面幾種方式達成

  • 在編譯Solution B之前,必須先從版控把程式碼抓回,進行編譯,如果這元件程式碼較大,勢必需要花些時間進行取得和編譯。因為是透過參考方式,有可能其他團隊在分支上,會遇到版本衝突裝況
  • 把元件放在資料夾分享內,直接抓取參考,但是這樣就沒有元件版本歷程


因此,透過元件化方式,則可以將solution B產生的dll檔案封裝成Nuget Package,讓Solution A單獨的使用。而不需要把solution B程式碼,嵌入到Solution A內,造成整個專案複雜度提高,更難維護。不過,元件化並非在所有情境下都是美好的,當元件們本身循環依賴時候,像是元件B和C相依於A,元件D又依賴於B和C。如果今日A更新了,B也更新了,但是C沒有,D就不能進行B的更新,因為更新後,有可能會與C發生版本上衝突(A會出現兩種不同版本),最好辦法則是也必須更新C,通常這樣就會讓整個開發效率變慢。但這樣是否元件化就不好呢?一般在大型企業或是團隊中,往往不太可能只會使用一種流程,大多數情況下,會混合使用這些方式進行。另外,好的區分方式,是會讓整個CI效率提升的,畢竟,這樣可以減少每次Build時候,就必須拉下所有程式碼進行編譯,在拉下程式碼這一段往往會隨著系統越大越耗費時間。


在VSTS引入Package management擴充套件,進行元件的管理,讓整個DevOps團隊可以更輕鬆管理與持續交付,同時,也可以讓代碼被共用。提升整個團隊的開發效率

上一篇