CODING 如何使用 CODING 研發管理系統來開發 CODING 2.0

• 2019 年 10 月 4 日
• 筆記

之前我們分享過《如何使用 CODING 研發管理系統開發 CODING》的文章，時過境遷，現在 CODING 研發管理系統已經上線了如持續集成、缺陷管理、測試管理等 DevOps 中的重要功能，並增加了對 SVN 的支援。藉此機會我們以自身的研發流程為例，來展示一下 How CODING uses CODING to build CODING 2.0。

企業級一站式軟體研發協作平台

CODING 現在的團隊有 100 多人，分布在全球各地（深圳、北京、成都、西雅圖等），均使用 CODING 研發管理系統作為雲端協作平台。在 CODING，不僅研發相關的團隊使用 CODING 來進行研發管理，市場、運營、行政的部門也同樣使用 CODING 進行任務分配與追蹤、文件分享等日常工作。

同時通過 CODING 的企業微信/微信小程式，還能實現隨時隨地同步與協同任務，小程式可以直接查看任務詳情、評論任務，還能實現程式碼合併（MR）等功能，真正做到 Coding Anytime Anywhere。

CODING 研發管理系統是基於項目進行的，我們依據組織架構建立了相關項目並使用【成員管理】添加相應部門的人員。通過項目這種扁平化的管理形式，幫助企業加快反應速度，提高自身敏捷性。

下周即將上線的 CODING 許可權管理功能，可以幫助項目管理員方便地根據項目成員角色來分配相應的許可權，減少誤操作帶來的安全隱患。同時支援自定義用戶組，增加研發管理的靈活性。

Push Everything Review Everything CI Everything

workflow

CODING 研發部門的工作流都是在項目內進行：我們使用任務功能來管理需求，使用文件來保存產品原型，使用程式碼功能進行開發，使用持續集成來進行自動化測試，使用缺陷管理來收集回饋，同時還使用 wiki 模組對知識進行儲存與共享。通過在任務中添加關注者的方式來方便相關同事隨時 follow 和 review 任務動態。

CODING 強大的任務系統支援標籤、跨項目引用、版本控制等多項功能，並會實時記錄用戶的每一次操作。同時 CODING 需求管理功能也即將上線，將在任務系統之外為用戶提供更細分更場景化的使用方式。

產品

CODING 的產品經理在正常的產品功能排期之外，會定期在缺陷管理中查看用戶的使用回饋並對相關問題的修復進行排期。

當產品經理研究決定我們要實現某一個功能/修復缺陷時，會以任務的形式發布該需求。但是在發布需求之前有幾件事情需要先做。

給任務定性

產品經理會把任務放入「需求回饋池」看板，並給任務定性：

• 純技術問題（含純技術 Bug），則指派給研發負責人進行跟進。
• 純設計問題，則指派給設計負責人進行跟進。
• （真）產品問題，則準備與發任務的源頭溝通分析此問題。

問題分析

• 偽需求，或者回饋方理解有誤，則直接在相關任務中回復，並關閉任務即可。
• 真需求，則完善對應的背景資訊，並將任務拖入「已分析需求池」。
• Bug 類，可以內部請測試人員來嘗試復現此問題。如果可復現，則給此任務打上「Bug 池」、「已確認」標籤，並拖入「已分析需求池」。

分析完需求後即可創建任務，如該任務涉及大型產品改動，則會由相應產品經理撰寫完整的產品說明文檔和必要的原型圖等文件；方案完成之後，產品經理會根據任務的緊急程度給任務設定優先順序，方便後續設計和開發的同事更方便的安排工作。

在產品設計過程中，我們使用 CODING 的文件管理功能對產品進行原型管理和版本管理。

功能開發完成後，產品經理還會配合研發進行 Staging 環境的驗收。如在 Staging 環境中發現問題，則需要與發布負責人協商回退或是重新發版，成功完成驗收則通知運維上生產環節。

開發

在產品經理完成原型圖和產品說明後，便會把任務移交給研發負責人，進行評估和排期，完成排期後研發負責人會根據任務情況安排里程碑。

開發人員開始基於自己的里程碑任務進行開發，其後的程式碼評審也是通過項目內提交 MR （合併請求）進行的。

CODING 使用了 Feature Branch Workflow，即團隊成員共用一個私有項目倉庫進行管理協作，開發者在各自的 feature-branch 中進行開發。

Code Review

開發完成後通過提交 Merge Request 進行程式碼評審，通過程式碼評審後 merge 進入 master 分支（master 分支是可部署到 staging/生產環境的分支）。

持續集成

當開發人員 push 程式碼時，將會自動觸發已設置好的持續集成，CODING 的持續集成會自動編譯並測試該 commit。CODING 持續集成支援在任意階段觸發並支援 cvm 模式。

當測試通過後，我們會更新程式碼到 Staging 環境。

測試

更新 Staging 的程式碼後，測試人員開始進行相關測試。現在 CODING 的測試管理功能由 18 年收購的專業測試工具飛蛾（ FEIE.WORK）承載，已實現了企業帳號打通，可直接在測試管理中點擊跳轉到飛蛾的工作介面。

接到測試任務後，測試的同時會先在飛蛾中制定相應的測試計劃。

制定好測試計劃後，即可開始編寫相關測試用例並開始執行測試計劃。

Staging 環境測試無問題後，該功能會以 Feature Flags（內部測試新功能）的形式發布其到生產環境，通知相關的產品或設計人員開啟 Feature Flags 進行內部 Review，如果存在問題或缺陷，我們會新建一個任務進行產品回饋，確保功能及設計細節的正確性。

運營 產品正式上線後，CODING 的運營同事會開始收集用戶回饋，通過各個渠道回饋的問題都會在 CODING 缺陷管理功能中以創建缺陷的方式進行歸納。

運營會定期將收集來的缺陷進行分析，將 Bug 類的缺陷轉給產品經理進行排期。如在生產環節發現重大 Bug 則會立即和產品經理溝通並通知運維，協商回退版本或者臨時修復。

市場

在確認功能順利上線後，產品經理會在 CODING Wiki 中更新 Roadmap，提示功能已經上線。方便市場部進行 Campaign 的計劃。

市場部的同事使用 CODING 任務管理中的討論功能，可以實時討論和跟蹤項目進度。

讓開發更簡單

工欲善其事，必先利其器，在現在數字化的商業環境中，企業對於軟體的依賴已經達到了前所未有的高度。如何選擇一套適合中國軟體研發團隊的開發工具和高效的研發流程，以解放開發人員的效能，打造更好的產品，已經成為每個企業必須要思考的問題。逆水行舟，不進則退，我們自身使用 CODING 進行開發，旨在不斷完善 CODING 的功能，優化提升 CODING 的使用體驗，讓 CODING 成為最適合中國式敏捷的研發管理系統，真正做到讓中國的軟體研發團隊開發更簡單！

同時我們也歡迎各種回饋，如果你有任何需求或建議，請不要忘了提交給我們 :D