軟件工程之美43講——以VS Code爲例,看大型開源項目是如何應用軟件工程的?

軟件工程之美43講——以VS Code爲例,看大型開源項目是如何應用軟件工程的?

VS Code 的開發迭代過程

從開發模式來說,VS Code 採用的是快速迭代的開發模式,每四周一個迭代。那麼這四周迭代的工作都是如何進行的呢?
第一週
每個版本的第一週,通常是起着承上啓下的作用,一方面要準備新版本,一方面還要對上一個版本的工作進行收尾。。
第二週和第三週
第二週和第三週主要工作就是按照計劃去開發,一部分是開發新功能,一部分是修復 Bug,所有的 Bug 都是通過 GitHub 的 Issue 來分配和跟蹤的。團隊成員每天還要先檢查一下分配給自己的 Issue,如果遇到線上版本緊急的 Bug,要優先修復。
第四周
VS Code 團隊把最後一週叫 End game,你可以理解爲測試周,因爲這一週只做測試和修復 Bug。這一週要測試所有新的 Feature 和驗證已經修復的 Bug,確保被修復。同時還要更新文檔和寫 Release Notes。測試完成後就發佈預發佈版本,這個預發佈版本會先邀請一部分人使用,比如說微軟內部員工、熱心網友。

VS Code 團隊的角色和分工

從角色上來說,除了開發,還有主要有兩種角色:Inbox Tracker和Endgame Master。這兩種角色在每個迭代的時候是輪值的,每個人都有機會去擔任這兩個角色。
Inbox Tracker
Inbox Tracker 的主要任務就是收集、驗證、跟蹤 Bug。所以 VS Code 團隊寫了一個機器人叫VSCodeBot,可以幫助對 Issue 先自動處理,打標籤或回覆,然後 Inbox Tracker 再對剩下的 Issue 進行人工處理。Inbox Tracker 要檢查新提交的 Issue 是不是一個真正的 Bug,如果是提問,建議到 StackOverflow 去問,如果是 Bug,打上 Bug 的標籤,並指派給相應模塊的負責人。
Endgame Master
Endgame Master 要組織管理整個迭代的測試和發佈工作。Endgame Master 在每個迭代測試之前,根據迭代的開發計劃制定相應的測試計劃,生成 Check List,確保每一個新的功能都有在 Check List 中列出來。Endgame Master 工作就是將這些測試項分配給團隊成員。最後整個測試計劃會作爲一條 GitHub Issue 發出來給大家審查。比如說這是某一個月的Endgame 計劃。團隊的日常溝通是通過 Slack,在測試期間,Endgame Master 需要每天把當前測試進展同步給所有人,比如說總共有多少需要測試的項,哪些已經驗證通過,哪些還沒驗證。

VS Code 的各個階段

VS Code 的需求收集和版本計劃

  1. VS Code 的需求收集和版本計劃
    需求來源
  • 一部分是團隊內部產生的
  • 一部分是從社區收集的,比如 GitHub、Twitter、StackOverflow 的反饋。

VS Code 每半年或一年會對下一個階段做一個Roadmap,規劃下一個半年或一年的計劃,並公佈在 GitHub 的 WIKI 上,這樣用戶可以及時瞭解 VS Code 的發展,還可以根據 Roadmap 上的內容提出自己的意見。大的 RoadMap 確定後,就是基於大的 RoadMap 制定每個迭代具體的開發計劃了。
版本迭代

  • 當前迭代:當前正在開發中的 Milestone;
  • On Deck:下一個迭代對應的 Milestone;
  • Backlog:還沒開始,表示未來要做的;
  • Recovery:已經完成的迭代,但是可能要打一些補丁。
  1. VS Code 的設計和開發

VS Code 的開發流程也是用的GitHub Flow,要開發一個新功能或者修復一個 Bug,都創建一個新的分支,開發完成之後提交 PR。

  • PR 合併之前,必須要有核心成員的代碼審查通過,並且要確保所有的自動化測試通過。你也可以在 VSCode 的Pull requests中看到所有提交的 PR,去看看這些 PR 是怎麼被 Review 的,每個 PR 的自動化測試的結果是什麼樣的。
  • VS Code 對自動化測試代碼也是非常重視,在實現功能代碼的時候,還要加上自動化測試代碼。VS Code 的CI(持續集成)用的是微軟自己的 Azure DevOps,每一次提交代碼到 GitHub,CI 都會運行單元測試和集成測試代碼,對 Windows/Linux/macOS 三個操作系統分別運行測試。
  1. VS Code 的測試

前面提到了,迭代的最後一週是 End game,這一週就是專門用來測試的,並且有輪值的 Endgame Master 負責整個測試過程的組織。具體測試的時候,大家就是遵循 Endgame Master 制定好的測試計劃,各自按照 Check List 逐一去檢查驗證,確保所有的新功能都通過了測試,標記爲修復的 Bug 真的被修復了。對於驗證通過的 Bug,在對應的 Issue 上打上 verified 的標籤。在人工測試結束後,Endgame Master 就需要跑冒煙測試,確保這個迭代的改動不會導致嚴重的 Bug 發生。如果你的團隊也沒有專職測試,可以學習 VS Code 這樣的做法:留出專門的測試階段,事先制定出詳細的測試計劃,把所有要測試的項都通過測試跟蹤工具跟蹤起來,開發人員按照測試計劃逐一測試。

  1. VS Code 的發佈流程
  • 創建 release 分支,比如說 release/1.10 ,後面的預發佈版本和正式版本包括補丁版本都將從這個 release 分支發佈。
  • 如果在創建 release 分支後發現了新的 Bug,那麼對 Bug 修復的代碼,要同時合併到 master 和 release 分支。每一次對 Release 的代碼有任何改動,都需要重新測試。
  • 每次 Release 代碼修改後,都會發佈一個新的預發佈版本,邀請大約兩萬的內部用戶進行試用,然後看反饋,試用 24 小時後沒有什麼問題就可以準備發佈正式版本。
  • 發佈正式版本之前,還要做的一件事,就是 Endgame master 要寫 Release Notes,也就是你每次升級 VS Code 後看到的更新說明,詳細說明這個版本新增了哪些功能,修復了哪些 Bug。
  • 除此之外,VS Code 每天都會將最新的代碼編譯一個最新的版本供內部測試,這個版本跟我們使用的穩定版 Logo 顏色不一樣,是綠色的 Logo。

VS Code 使用的工具

  • VS Code 使用的工具VS Code 的源代碼管理工具: GitHub,整個開發流程也完全是基於 GitHub 來進行的。它的任務跟蹤系統是用的 GitHub 的 Issue 系統,用來收集需求、跟蹤 Bug。通過標記不同的 Label 來區分Issue 的類型和狀態,比如 bug 表示 Bug,feature-request 表示功能請求,debt 表示技術債務。通過 Issue 的 Milestone 來標註版本。
  • VS Code 的持續集成工具:微軟的Azure Pipelines。
  • VS Code 的文檔: GitHub 的 WIKI 系統,一部分是它網站的博客系統。WIKI 主要是日常項目開發、維護的操作說明,博客上更多的是一些技術分享。另外 VS Code 團隊還自己開發了一些小工具,比如說幫助對 Issue 進行自動處理回覆的 GitHub 機器人 VSCodeBot。通過這些工具的使用,基本上就可以滿足像 VS Code 這樣一個項目的日常運作.
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章