微軟軟件研發(fā)方法論及軟件開發(fā)平臺(tái)的構(gòu)建(編輯修改稿)
2025-02-12 14:11 本頁面
【文章內(nèi)容簡介】 沒有設(shè)計(jì)就不要寫產(chǎn)品代碼 即使是一個(gè)人的項(xiàng)目也要遵守這個(gè)好規(guī)則 對團(tuán)隊(duì)項(xiàng)目來說則是必須的 功能集是由微軟 Program Managers來負(fù)責(zé)的 負(fù)責(zé)寫每個(gè)功能的設(shè)計(jì)規(guī)格 ,開發(fā)和測試給反饋 一個(gè)好設(shè)計(jì)規(guī)格有如下特點(diǎn) : 清楚地說明功能的目標(biāo)和非目標(biāo) 清楚地說明客戶和合作伙伴怎樣來用這個(gè)功能 準(zhǔn)確地說明功能的對象模式和架構(gòu)設(shè)計(jì) 足夠清楚地讓分開的開發(fā)、測試、文檔、本地化團(tuán)隊(duì) 一起來完成 編寫代碼 對源代碼樹的任何改動(dòng)在提交前都要由別的開發(fā)工程師來做代碼審核 開發(fā)者負(fù)責(zé)對實(shí)現(xiàn)的功能進(jìn)行提交測試 現(xiàn)趨向于開發(fā)者寫的單元測試達(dá)不到 60% blocklevel codecoverage 不能提交功能代碼 代碼提交前所有的提交測試都要運(yùn)行，通過率要 100% (23 小時(shí)的過程 ) 工具：提交排隊(duì)系統(tǒng)來運(yùn)行提交測試 提交排隊(duì)系統(tǒng)在每次成功提交后會(huì)給團(tuán)隊(duì)發(fā)“Checkin mail” 電郵，信中總結(jié)修改了什么代碼、解決的漏洞、修改的文件 Unit Testing 單元（ unit）測試 源代碼樹的結(jié)構(gòu) Main Source Branch Feature Branch Team1 Branch Team2 Branch Feature Branch Feature Branch Feature Branch Feature Branch Feature Branch 產(chǎn)生每日構(gòu)建 Daily Builds 每天都要產(chǎn)生一個(gè)產(chǎn)品的新構(gòu)建 “build” 中央 build lab 為全 division (~2800 人 )做 daily build Build 流程 : Build 團(tuán)隊(duì)同步源代碼樹 (~半夜 ) 開始端到端的 build (~4:00am) Build 完成 (~1:00pm) 做 BVT (Build Verification Tests) 來驗(yàn)證 build 是否正常 (~4:00pm) 從 BFD那里拿到 hotfixes 然后 rebuild BVT 失敗的地方 重復(fù) hotfix/BVT 周期直到 build 沒有問題 169。 2023 Microsoft 每天都有 Build報(bào)告 測試 測試團(tuán)隊(duì)是由開發(fā)人員組成的，他們負(fù)責(zé)設(shè)計(jì)測試計(jì)劃、寫自動(dòng)測試、建立測試基礎(chǔ)設(shè)施 著重于提高質(zhì)量、防止退化、能夠快速分析不同的 builds和它的變異以及各語言版 VS2023測試狀況： 102,000 功能測試用例 Test Cases 505,000 功能測試
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號-1