掌握Git與CI/CD創建有效的開發工做流程

時間 2020-07-18

標籤掌握 git 創建有效開發流程欄目 Git 简体版

原文原文鏈接

一個有效且組織良好的現代軟件項目沒有持續集成和持續交付/部署很難想象。很難想象沒有某種形式的版本控制系統（VCS）的任何項目，其中最流行的是Git。android

在本文中，我將討論這些因素如何相互影響，經歷設計它們的設置的思考過程，並指出一些特定於Android的優化。git

VCS工做流程與CI / CD之間的互連

讓咱們回顧一下咱們須要CI / CD的主要內容：github

運行測試。
部署/發佈。

可是，等等，咱們能夠手動完成全部操做，那麼使用它的真正緣由是什麼？緣由是咱們能夠指定自動執行這些操做的條件。緩存

這給咱們帶來了巨大的好處：ide

保證測試可以運行，這使咱們對發佈的產品更有信心，併爲開發人員對其代碼提供了更多信心。
由於運行測試再也不是開發人員的責任（在大多數狀況下），因此他要記住的事情就更少了。這使他能夠更加專一和減輕壓力。
反饋循環能夠像咱們想要的那樣快，這使咱們可以快速解決問題。
發佈會減小工做量，準備工做和風險，由於部署是自動化的，而且全部問題/衝突均可以事先解決。
因爲發行變得愈來愈難管理，所以發行頻率可能會更高。這爲咱們帶來了快速的迭代和快速的用戶反饋。

聽起來不錯吧？可是，讓咱們回想一下使用CI/CD的緣由。我提到了兩個主要詞：「條件」和「自動」。猜猜，誰負責第一個？這是您的VCS！或更確切地說，它的工做流程。gitlab

您的VCS模型定義了能夠設置運行各類自動化任務的條件。固然，這也取決於所選CI解決方案的功能集。可是它們傾向於提供類似的功能，只是形式不一樣。post

這是設計開發工做流程時必須問本身的問題：學習

您想在何時推出新版本？您須要多快迭代一次？您的應用程序是否有多個分發（例如，alpha，beta，穩定版）？
您是否有隻但願針對代碼庫的某些狀態運行的特定測試？仍是隻是想分別運行愈來愈少的較大和較小的測試套件？
您想多久運行一次測試？您是否須要一個快速反饋迴路，並進行頻繁的可靠性測試？
仍是優先考慮快速前進，所以，開發人員須要花費更少的時間等待CI構建完成？
您是否有任什麼時候間或容量限制來運行構建？您是否可使用某些特定的VCS設置來優化這些內容？

牢記全部這些，並瞭解您的工做流程設計的重要性，讓咱們來看看使用最受歡迎的VCS-Git時的選擇。測試

剖析Git工做流程

在這裏，咱們僅討論各類分支模型以及它們如何與CI/CD一塊兒使用。關於合併vs變基vs squanch壁球的討論不在本文討論範圍以內，由於這並不會真正影響CI功能。優化

GitFlow

Gitflow是一種很是流行的工做流程，它定義瞭如下類型的分支：

master包含生產代碼。
develop：包含最新的開發更改，這些更改將包含在下一版本中。
功能分支：爲咱們使用的每一個新功能建立一個新分支。咱們從開發開始，一旦完成，就合併回去。
版本分支：從開發開始，表示一旦將該分支合併到master中，就會有一個新版本。
修補分支：當咱們須要對生產應用程序進行緊急更改但開發還沒有準備好生成發行分支時使用。從master開始，併合並爲master和develop。

此工做流程的基本CI/CD設置以下所示：

在除master之外的全部分支上運行自動化測試。
每次合併到master後進行部署。

GitHubFlow

Gitflow是一個實體模型，儘管不是最簡單的模型。學習它須要花費時間，而且因爲須要進行大量操做，所以須要花費時間將代碼庫從一種狀態轉移到另外一種狀態。

隨着GitHub的興起，他們共享了本身的工做流程。它只是簡單地說：「爲每一個新功能從master建立一個新分支，而後合併回去」。這樣，根據您爲部署作準備的方式，修補程序將成爲另外一個功能分支，而develop分支將被忽略，發行版可能不存在，或者也不是功能。

該模型可能不像之前的模型那麼複雜，可是卻帶來了一個殺手級功能- 簡單性。

GitHub Flow具備較大優點的另外一個地方是開源軟件。使用Gitflow的開放源代碼項目有兩個錯誤的選擇-默認狀況下，向訪客和貢獻者顯示不多更新的master分支或非生產質量的development分支。

此工做流程的基本CI / CD設置以下所示：

在全部分支上運行自動化測試。
在每次合併到master或每次建立指定標籤後進行部署。

GitLabFlow

GitHub Flow出現不久後，彷佛開始出現了每個VCS值得尊敬的Web服務都應該有一個以它命名的工做流。所以，GitLab Flow誕生了。

它創建在GitHub Flow的基礎上，旨在解決更復雜的部署邏輯的需求，而不是每次將代碼合併到master分支時都這樣作。

這些要求能夠是：

因爲某些外部條件（應用程序評論（App Store），部署窗口），沒法隨意部署。
多個環境（測試，預生產，生產）或多個分發渠道（alpha，beta，穩定版）。

一次支持多個應用程序版本。

此工做流程的基本CI / CD設置以下所示：

在全部分支上運行自動化測試。
根據具體策略進行部署-能夠從主分支，生產分支或多個分支進行部署。

自定義工做流程

不要懼怕提出本身的定製工做流程！若是您以爲除了在線上找到的任何其餘模型之外，還須要其餘東西，請繼續修改現有模型或從頭開始建立新模型。互聯網上沒有人比您更瞭解您團隊和項目的要求！

設計工做流程

在爲應用程序（尤爲是Android應用程序）建立工做流時，請仔細考慮一下。

開始

一個不錯的起點是咱們以前探討的Git模型之一。

一般，在如下狀況下，GitHub Flow多是更好的選擇：

您但願常常發佈（對於Android系統，一般天天發佈，甚至天天發佈）。
您有一個開源項目。
您不肯定您的要求。從簡單開始並隨後擴展比從複雜系統開始老是容易的，後者之後將很難拆除。

在如下狀況下考慮使用GitLab Flow：

您對部署時間有限制。
您須要獨立發佈幾種應用程序版本（例如，alpha，beta，穩定版）。
您須要同時支持多個應用程序版本。

最後，在如下狀況下考慮Gitflow：

您的發佈應該不多（每週或更罕見）。
您可能常常須要等待一段時間才能將候選版本合併到master中，可是與此同時繼續研究新功能。
您須要同時支持多個應用程序版本。

最佳化

咱們始終但願儘量減小CI構建的執行時間，以快速查看反饋並向前發展。有時，這樣作的緣由也是構建時間限制。例如，若是您使用的是免費套餐。並且因爲Android版本可能會花費大量的時間，所以這個問題變得更加嚴重。

有幾種方法能夠減小構建時間：

徹底不須要時，不要觸發它們。
查找須要大量時間但在某些狀況下能夠省略的任務。
針對特定狀況自定義任務。有時，咱們能夠爲同一任務設置不一樣的配置，而這會花費不一樣的時間。

如今來看具體的優化示例：

因爲咱們只想構建有意義的代碼，所以運行CI僅針對請求構建。一般，能夠在CI設置中啓用此設置。
爲從未包含或未經測試的代碼的分支跳過CI。例如，若是不須要在每次更改時都進行部署，則能夠跳過master分支。只需確保在合併以前將任何新分支從新創建到主分支上便可。
緩存您的Gradle文件。經過避免在不更改依賴項的狀況下下載它們，能夠節省大量時間。
在其餘狀況下，使用assembleRelease和assembleDebug代替bundleRelease和bundleDebug。您會節省一些時間，由於生成APK的速度比捆綁包快。