Coding 如何使用 Coding 開發 Coding

01-29

Coding Anytime Anywhere

Coding 團隊有 70 多人，分布在全國各地（深圳，北京，上海，成都），我們使用 Coding 作為雲端辦公室，以雲端協作的方式管理事務，文件等，我們的日常工作（包括但不限於產品，研發，市場）都是在其上完成的。Coding 的全平台支持讓大家可以隨時隨地進行同步與協作，我們一直在踐行「Coding Anytime Anywhere」。

我們使用 Coding 團隊功能管理團隊成員和私有項目，只需要在 Coding 創建一個團隊，選擇遷入私有項目並添加人員，即可完成對成員，團隊與項目的管理。（項目內也可以設置不同成員的許可權）

Push Everytime，Review Everything

Coding 的工作流（從需求到產品原型到開發）都是在項目內進行的：我們使用討論和任務功能管理需求，使用文件功能管理產品原型，使用代碼功能進行開發，這也便於每個人隨時 Follow 或 Review 任務，文件和代碼。

需求

我們使用 Coding 的公開項目討論功能收集用戶反饋，提煉核心需求並定期 Review 進行取捨。

為什麼要 Review 產品需求？

軟體缺陷並不只是在開發階段才產生，需求和設計階段同樣可能會產生缺陷。

產品

當產品研究決定我們要實現某功能時，我們會以任務形式發布該需求，然後進行技術評審（如果是重大新功能還需要進行設計評審），評審完成且結果為肯定時我們會繼續細化（修改）該任務，進行產品設計及排期。

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

開發

Coding 的開發方式，更像是一個大型的開源項目協作。當需求及產品原型以任務形式確定後，開發人員就開始基於自己的功能分支進行開發，其後的代碼評審是也是通過項目內提交 MR （合併請求）進行的。

我們使用了 Feature Branch Workflow，即團隊成員共用一個私有項目倉庫進行管理協作，開發者在各自的 feature-branch 中進行開發，開發完成後通過提交 Merge Request 進行代碼評審，通過代碼評審後 merge 進入 master 分支（ master 分支是可部署到 staging/生產環境的分支）。

工作流（Workflow），是對工作流程及其各操作步驟之間業務規則的抽象、概括描述。合理選擇並使用一套工作流可以讓技術團隊開發更高效，更簡單！
Workflow 沒有銀彈，如果你的：

生產環境有多個版本，需要持續支持舊版本的軟體服務如操作系統，自定義應用程序等，可使用 Gitflow

生產環境只有一個版本，如網站，網路服務等，可使用 Feature Branch Workflow

生產環境只有一個版本但軟體很複雜，需要 CI/CD 後才能進入生產環境的如 Gmail，Twitter 等，可使用 Gitlab-flow

測試與上線

當開發人員 push 代碼後會觸發 Webhook，我們的 Jenkins 會自動編譯並測試該 commit。

你的部署工具應該支持你部署分支是很重要的。一旦你確認你的性能沒有波動，沒有穩定性問題，功能可用性在預期內，你就可以 merge 它了。這麼做的原因不是為了確保事情可行，而是防止事情不可行。當其出錯時，你的解決方案應該是單調，直接且無壓力的：重新部署 master 分支即可。就是這樣，你回到了「沒問題」的狀態。——《如何部署軟體》

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

如果經測試新功能確認沒問題後，我們會開放該 Feature Flags，將該功能開放給全體用戶。

結語

Coding 始終認為開發工具應該足夠簡單，開發人員的生產力應該被解放出來，我們使用 Coding 這個開發工具進行開發，旨在不斷優化提升 Coding 的體驗，讓開發更簡單。當然，如果你有任何需求或建議，請不要忘了提交給我們；）

Happy Coding!

感謝 @summer ，@rexskz 對本文進行了 Review 並提出修改意見；感謝 @tankxu 設計的圖片（How Coding uses Coding to build Coding）。