Coding 如何使用 Coding 開發 Coding

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）