發布 / 展示 / 詢問

如何使用 Pull Requests 進行持續整合？

Pull Requests 已被許多軟體團隊廣泛採用。有些人喜歡它們，而有些人則渴望 持續整合 的日子——您從不建立分支，而您的團隊始終將變更放在一起。

在某些方面，Pull Requests 是一個改變遊戲規則的技術。程式碼託管工具提供絕佳的程式碼審查功能。有許多 SaaS 供應商提供可以在您的 Pull Requests 上執行的服務——從執行測試和檢查程式碼品質到部署成熟的預覽環境。

但採用 Pull Requests 作為貢獻程式碼的主要方式已造成問題。當我們進行持續整合時，我們失去了一些「準備發布」的心態。正在進行中的功能會透過延遲整合而保持在不影響運作的方式，因此我們陷入持續整合試圖解決的 低頻率整合 陷阱。

有時，Pull Requests 會擱置一段時間而變得過時，或者在等待審查時，我們不確定該做什麼。有時，當我們想「好吧，既然我在這裡，不如順便做這件事」時，它們會變得臃腫。

我們也對必須審查的 Pull Requests 數量感到厭煩，因此我們不再討論程式碼。我們不再注意，只會按一下「核准」或說「看起來不錯」。

介紹發布 / 展示 / 詢問

有一種我與團隊一起使用的軟體分支方法。它運作得非常好，所以我想與你分享。

每次進行變更時，請選擇下列三個選項之一：發布、顯示或詢問。

發布

圖 1：變更直接進入主線

這感覺最像持續整合。你想要進行變更，因此你直接在你的 主線 上進行變更。執行此操作時，你不會等待任何人將你的變更帶入生產環境。你不會要求進行程式碼審查。不用大驚小怪，只要進行變更，並使用所有常見的持續整合技術來確保安全即可。

在下列情況下運作良好

• 我使用既定模式新增功能
• 我修正了一個不起眼的錯誤
• 我更新文件
• 我根據你的意見改善我的程式碼

展示

圖 2：開啟 PR 以取得意見回饋，但立即合併

這是我們採用持續整合心態並仍然利用 Pull Requests 能為我們提供的所有好處的地方。你在分支上進行變更，開啟 Pull Request，然後在不等待任何人情況下將其合併。你會想要等待你的自動化檢查（測試、程式碼涵蓋率、預覽環境等），但你不會等待任何人的意見回饋即可繼續讓你的變更上線。

這樣做時，你已快速讓你的變更上線，同時仍然為意見回饋和對話創造空間。你的團隊應收到你的 Pull Request 通知，然後他們可以審查你所做的工作。他們可以針對你的方法或程式碼提供意見回饋。他們可以向你提問。他們可以從你所做的工作中學習。

在下列情況下運作良好

• 我很想聽聽你對如何改善此程式碼的意見回饋
• 看看我使用的這個新方法或模式
• 我重新設計了 X，現在看起來像這樣
• 真是有趣的錯誤！看看我是如何修正它的。

詢問

圖 3：開啟 PR 以取得回饋，並在合併前等待

在此我們暫停。我們在分支上進行變更，開啟拉取請求，並在合併前等待回饋。也許我們不確定是否採取正確的方法。也許有些程式碼讓我們不太滿意，但我們不確定如何改善它。也許你已經做了一個實驗，並想看看人們的想法。

現代程式碼檢閱工具為這類對話提供了絕佳的空間，你甚至可以讓整個團隊一起檢視拉取請求並進行討論。

在下列情況下運作良好

• 這會奏效嗎？
• 我們對這個新方法有什麼感覺？
• 我需要協助讓它變得更好，請
• 我今天完成了，明天會合併

規則

• 程式碼檢閱或「核准」不應該是合併拉取請求的必要條件。
• 人們可以合併自己的拉取請求。這樣他們就能控制他們的變更是「展示」還是「詢問」，並且可以決定何時上線。
• 我們必須使用所有有助於保持主線可發布的絕佳持續整合和持續傳遞技術。以功能切換為例。
• 我們的分支不應該存在太久，而且我們應該經常在主線上變基它們。

對話

雖然拉取請求可能是討論變更的有用方式，但它們有一些缺點。最誘人的反模式是它們可以取代其他對話方式的想法。

分支的一個常見問題是人們在沒有討論的情況下決定一種方法。當開啟拉取請求時，時間已經投資在可能次佳的解決方案上。審閱者會受到所選解決方案的影響，並發現更難建議替代方法。變更集越大，分支存在時間越長，這個問題就越嚴重。在開始之前與你的團隊交談，這樣你就可以獲得更好的想法並避免返工。

請記住，拉取請求並非展示或詢問的唯一方式。撥打電話或走到某人的辦公桌前。及早且經常展示你的工作。及早且經常請求協助和回饋。一起執行任務。

不開啟拉取請求也不是避免討論程式碼的理由。重要的是你的團隊仍然有良好的回饋文化，並互相討論你的想法和學習成果。

平衡

現在有三個選項 - 我應該更常選擇哪一個？

這取決於情況。我認為每個團隊在任何特定時間都會有自己的平衡點。

當你以既定的模式傳遞功能時，你將會執行更多「出貨」。當你對團隊有高度信任，並且大家共享相同的品質標準時，你將會執行更多「出貨」。

但如果你們還在互相認識，或你們都在做一些新的事情，那麼對話的需求就會更大，因此你會做更多「展示」和「詢問」。初階工程師可能會經常「展示」和「詢問」。資深工程師可能會大量「發布」，但偶爾會「展示」一個新技術或一個每個人都應該嘗試的重構。

有些團隊不會有太多彈性。某些產業受到高度管制，每個變更都需要一個核准或審查程序。有各種方式可以實作這一點，無論你是否分歧，這一點我不會在此深入探討。

我的團隊應該採用這種方法嗎？

你已經有了。

想想你的團隊如何運作，你會注意到你在發布/展示/詢問之間取得一些平衡。我見過的大多數團隊都屬於兩個區塊之一：「主要發布」或「主要詢問」。

結論

那麼，什麼是發布/展示/詢問？從根本上來說，它是兩件事

首先，一個技巧可以幫助您獲得兩全其美，合併您自己的拉取請求，而不必等待回饋，然後在回饋來時注意它。

其次，一種更具包容性、更動態的查看分支策略的方法。發布/展示/詢問提醒我們，每個團隊的方法都介於「總是發布」和「總是詢問」之間的某個連續體上。它鼓勵我們獨立思考每個變更，並問自己，我應該發布、展示還是詢問？