從更廣的視角看待 Bitbucket

更廣的視角

隨著中國軟件從業人員能力的整體提升，現在已經不僅僅是開發工程師才會使用到版本控制工具。無論是測試工程師，還是運維交付人員，都會有不少高效的自動化設計與輔助工具；甚至，越來越多的非技術人員也開始利用版本控制工具輔助自己的工作。

雖然Bitbucket 在設計初期並未針對這些人員，但是，當大家發現其實Bitbucket 具有足夠的靈活性和強大的功能，能適應各種不同的工作場景。越來越多的人開始發現並利用這類工具的妙用，代碼託管平台自然受到了廣泛的歡迎和使用。

例如，測試工程師可以使用Bitbucket 來管理測試腳本的版本，並通過與Jira 等工具的集成，方便地追踪和管理測試任務。運維交付人員可以利用Bitbucket 來維護和管理配置文件，通過自動化流水線實現配置的快速部署和更新。非技術人員，如項目經理，產品經理等，也可以利用Bitbucket 來管理文檔，追踪文檔的更改歷史，方便地進行版本比較和回滾。

所以，無論你的角色是什麼，無論你的工作內容是什麼，Bitbucket 都可能成為你的得力助手，幫助你提高工作效率，確保工作質量。

持續集成與自動化測試：向Bitbucket 與Bamboo 的組合看齊

過去，持續集成主要是一些CI/CD 工具的領域，比如Jenkins、Bamboo 等。如今，無論是GitHub 還是GitLab 都已經內置了流水線功能，儘管仍需要額外部署Runner 以支持流水線服務。對於Bitbucket 本地版本，由於原本就支持自家生態產品Bamboo 的集成，因此在該方面並沒有過多改動。

Bitbucket Cloud 版支持雲端的流水線，其使用方式與GitHub 和GitLab 十分相似，都是一個隨軟件代碼一同存放的yml 文件，雖然這種方式有利也有弊。一方面，它意味著軟件開發的同事需要來編輯這個流水線配置/模版文件，或者是需要一個負責流水線工作的成員擁有這些軟件代碼倉庫的權限，這在企業內部，可能會產生一些權限劃分的問題。但另一方面，這種方式對於小型、敏捷的團隊卻十分友好，尤其是那些研發人員能夠全棧工作的團隊，他們可以僅通過在代碼庫中編寫代碼的方式就完成一系列的工作，極大地提高了工作效率。

工具人學堂的顧問曾接觸過一個創業團隊，他們在使用yml 文件作為自動化集成方式時，遇到了一些混亂的狀況。由於團隊中並不是每個人都能全棧工作，因此他們在使用這種方式時，總是無法規範和統一流水線，也無法集中化管理和查看，自動化測試更是成了持續集成之外的存在。

實際上，許多團隊都期望流水線是一條從頭到尾的線，即代碼提交、編譯、單元測試、掃描、構建發布、集成測試、部署上線。然而，真實情況並非如此。例如只看構建發布、集成測試、部署上線這三個步驟，他們並不是順序完成的，而是存在一種交叉關係。如果涉及到多服務、多代碼庫、多環境，持續集成的關係圖譜將會復雜得難以描述。

因此，工具人學堂的顧問建議他們嘗試把持續集成從代碼庫中獨立出來，交給Bamboo 這樣的CI/CD 工具進行統一維護。同時，自動化測試代碼也可以保存在Bitbucket 的一個獨立代碼庫中，以便與軟件產品代碼庫進行更靈活的交互。這樣不僅可以解決他們目前面臨的問題，也能在更大程度上提升他們的工作效率和項目管理的清晰度。

部署模板及工具：從混亂到有序的轉變

運維或測試人員經常會使用一些自研的小工具，這些工具的使用效果通常優於市場上的通用產品，這是因為這些工具針對特定的工作場景進行了優化。因此，如果你在工作中編寫了一些有用的小工具，不妨將它們推送到Bitbucket 這樣的平台上。這樣一來，你可以與同事分享這些工具，二來，別人可能會對你的工具提出改進意見，這對於你的成長來說是非常有價值的。

我接觸過一個剛剛轉向Kubernetes 的團隊，他們編寫了很多部署YAML 文件，每個環境都有各自的文件集。在初期，這種方式並沒有造成太大的困擾，但隨著部署環境的增多和產品版本的迭代，他們發現維護這些文件變得越來越麻煩。每次產品發布，他們都需要對每個環境的眾多YAML 部署文件進行逐行檢查和修改。

這並不是因為該團隊的技術實力不足，而是因為他們剛剛轉向Kubernetes，對於Kubernetes 的應用場景還不夠了解，因此在交付方式上的思路也相對不夠靈活。

在這個時候，工具人學堂的顧問鼓勵他們的交付工程師把這些YAML 文件拿出來進行分析，並勇於向開發團隊提出需求，然後提取出可以使用部署變量的地方，並將YAML 部署文件提取為YAML 部署模板，然後在Bitbucket 上進行管理和發布。

最後，交付工程師只需要維護一套部署模板，然後使用他們自己編寫的渲染工具，結合環境信息生成部署文件並部署到不同的環境。沒過多久，他們就把這個工具也集成到了交付代碼庫，成為了部署發布產出物的組成部分。

這種方式與開發軟件的過程非常類似，不僅大大減輕了交付工程師在部署上線方面的工作負擔，而且因為使用了Bitbucket 這樣的版本控制託管平台，使得每次產品迭代導致的部署模板變更都能夠被追踪和查證。甚至，部署模板的發布過程也引入了開發工程師和測試工程師的代碼評審環節。

文檔管理：Markdown 的優勢

一般來說，我們會建議將各類文檔放在Confluence 上，但大多數程序員本能地對寫文檔有所抗拒，然而他們卻可以接受在代碼庫中使用Markdown 寫一些文字。

有一個需要直接面對終端客戶的研發團隊，他們的公共知識庫中的內容幾乎涵蓋了開發、測試、運維各個角色。他們嘗試使用Confluence 來編寫文檔，但發現由於每個人對Confluence 的掌握程度不同，導致文檔的格式都無法統一，工程師們也不習慣在一個在線的富文本編輯器中編寫文檔。

簡潔而實用的Markdown 最終成為他們的選擇，並且他們選擇在Bitbucket 中進行管理和維護。雖然從美觀度上來說，Markdown 不如Confluence 的富文本頁面，但這使得所有的角色都能夠持續地輸出文檔。

這種方法並不適用於每一個團隊，但對於小型的研發團隊，他們的人力和資源都有限，因此，他們可以嘗試在Bitbucket 這樣的代碼託管平台上寫文檔。通過這種方式，他們可以節省資源，同時也可以提高團隊的效率。