研發團隊眼中的 Bitbucket

研發視角

在介紹了Bitbucket 的一些功能後，我們來看看如何利用Bitbucket 落實實際工作場景。

由於Bitbucket 是一個代碼託管平台，其主要的使用者是技術類研發人員。無論是開發軟件代碼、編寫測試腳本、搭建運維工具，還是撰寫研發文檔，都可以充分利用Bitbucket 所提供的功能。

讓我們從研發視角出發，探討如何使用Bitbucket。

代碼評審

我至今記得剛入行的時候，見到一位研發工程師在進行代碼評審，雖然當時我還不太理解他在做的工作的重要性。因為當時的我還沒有接觸過任何版本控制工具，只是被那個花花綠綠的界面吸引了。

我們曾有一個客戶，他們為企業內部提供信息技術支持，他們的領導非常明白代碼評審的重要性。因此，他們一開始就向我們詢問在Bitbucket 中如何進行代碼評審。由於代碼評審只是一種行為，並沒有固定的標準，所以我們進一步了解了他們對代碼評審的理解以及他們在代碼評審過程中想要實現什麼樣的協同工作。

對此，客戶給出了明確的需求場景：在提交代碼合併請求後，首先要保證流水線能夠成功執行，且靜態代碼掃描（使用SonarQube）的質量達到標準，然後才允許評審人員同意合併。在代碼審查過程中，評審員可以添加註釋和任務，這裡的任務並不需要通過Jira 進行跟踪，而是起到備忘清單的作用。

這是一個相對常見的代碼審查功能需求，只是由於客戶之前沒有使用過Bitbucket，所以他們不確定這些功能是否能在Bitbucket 上有效實現。

客戶的研發團隊規模不大，在提交代碼合併請求時，他們完全可以自主選擇審查人員。但這樣的無腦操作會讓用戶覺得有些“傻”，所以工具人學堂的顧問告知可以在Bitbucket 中配置默認的審查人員，並設定了必須至少有一個評審員進行評審的規則。

由於客戶期望代碼評審的一個前提是流水線必須被執行成功，所以我們在Bitbucket 中將Bamboo 的流水線關聯過來。這樣一來，在進行代碼評審時，評審員可以直接看到對應的流水線執行結果。此外，只需要在Bitbucket 代碼庫的左側點擊Builds 菜單按鈕，就可以瀏覽所有該流水線分支的執行情況，用戶不需要跳轉到Bamboo 就能瀏覽到結果。

對於靜態代碼掃描質量達標這一審查前提，實際上是通過Bamboo 流水線執行來獲得結果的。雖然在Bamboo 流水線的設計中，我們已經將使用質量門的結果作為流水線成功與否的判斷條件（也就是說，如果流水線執行成功，則掃描結果一定是達標的），但客戶仍希望在Bitbucket 上能有一個顯眼的標識。為此，工具人學堂的顧問推薦了一個插件—— Include Code Quality for Bitbucket。

這個插件的作用是在Bitbucket 的流水線記錄上生成一個顯眼的Sonar 報告質量狀態，同時，該插件還能提供一些額外的功能，比如在瀏覽代碼庫內容時，頁面上也會展示Sonar 報告的數據。這樣，客戶就可以更直觀地看到代碼質量的信息，從而更好地關注代碼質量。

分支管理的策略與實踐

在版本控制的世界裡，分支管理的策略是項目成功與否的關鍵因素之一。許多團隊試圖尋找可藉鑑的最佳實踐，但在Git Flow、GitHub Flow 以及GitLab Flow 這三個普遍被接受的工作流程中，沒有一個能夠成為所有項目的萬能鑰匙。更別說在各種定制化的工作流中尋找一種通用的解決方案了。

以某個SaaS 服務商團隊為例，他們在初期的階段，採取的是接近於Scrum 的方法論，分支管理相對簡單。我對此深表讚賞，因為在項目初期，團隊規模較小，產品的快速上線以解決實際問題是至關重要的。然而，隨著他們的研發人員擴張至兩位數，以及軟件模塊數量的增加，原有的簡單的主從分支結構已經無法滿足日常的協作需求，更別說在之後引入了CI/CD 流水線。在方法論上，他們堅持利用Sprint 進行推進，但實際上，他們關注的重點已經不再像是單純的Scrum 了。團隊成員的能力增長無法跟上團隊規模的擴張，導致他們難以過渡到LeSS 框架，最終他們選擇採用了一些SAFe 框架的理念。

在這樣的背景下，他們選擇GitLab Flow 作為參考的方向。然而，由於戰略選擇的原因，他們開始提供私有化部署服務，這使得發布/上線的場景變得越發複雜。

雖然工具人學堂的顧問盡可能地簡化了工作流，但最終，我們不得不面對多版本維護的現實問題。在早期，他們仍保留了環境分支的習慣，這使得他們必須經歷一段思維轉換期。

在Bitbucket 平台上，我們為他們定義了分支的前綴，使得每個分支都能遵守特定的規則，方便匹配到自動化流水線的觸發。同時，這也有助於提前確定組織需要的分支名稱格式，從而保持分支管理的規範和一致。

需求管理的協同與集成

作為研發人員，他們的主戰場往往是代碼，因此，Bitbucket 提供的環境相比於Jira 更為直接且有利。然而，正因為Bitbucket 和Atlassian 生態系統的緊密集成，它能夠輕鬆地與Jira、Confluence、Bamboo 等工具協同工作，實現了全面的項目管理和協作流程。這是Bitbucket 在其官網中大力宣傳並以此為傲的一項能力。

借助Bitbucket，研發人員可以在其用戶界面中直接與Jira 進行交互，無需跳轉到Jira 平台去查閱需求任務。這種無縫的集成，使得我們在管理代碼的同時，能夠清晰地理解需求的來源和目標。

對於研發管理者來說，這種集成也同樣帶來了便利。他們不僅可以在Jira 界面上查看關於某個Jira 事務相關的代碼提交列表，更可以直接從Jira 事務創建分支，無需在兩個平台之間切換。在創建分支的過程中，系統會自動附帶參數，使得事務與分支之間建立了直接聯繫。這種強關聯性大大提高了項目管理的效率，也保證了需求管理的準確性和實時性。

缺陷追踪的深度集成與透明化

同樣，Bitbucket 也為缺陷追踪提供了強大的助力。與需求任務一樣，我們可以方便地將缺陷與Bitbucket 的每次提交產生強關聯。除了在代碼提交時的備註，使得每次提交與缺陷記錄保持關聯外，我們還可以直接在缺陷記錄上點擊按鈕，一鍵生成相應的分支。

Bitbucket 與Jira 的深度集成，使得缺陷追踪變得前所未有的輕鬆。開發者可以直接在Bitbucket 中查看和更新與代碼相關的缺陷問題，同時在Jira 中也可以查看到與缺陷相關的代碼提交和拉取請求信息。這種雙向的透明度，讓整個團隊在開發過程中都能看到問題的來源，當前的狀態，以及解決的進度。這樣的流程不僅保持了團隊的高效，更提高了代碼質量和項目的穩定性。

在這種工作模式下，缺陷追踪和分支管理相互輝映，形成了一種有序且高效的推進機制。每一個缺陷都被當作一個單獨的任務來處理，每一個任務都有明確的歸屬和進度。這種透明度和效率，是Bitbucket 與Atlassian 生態系統深度集成帶來的獨特優勢。