技術團隊開發與發版規範

迭代

1. 公司層面的迭代週期是 1 個月（跟 KPI、績效掛鉤），產研團隊將 1 個月劃分成兩個小迭代，月初由產品和技術共同制定本月的需求列表（其中產品需求主要由產品主導，技術協助評估，技術需求由技術團隊自己制定），這些計劃列表構成每個團隊和個人的月 KPI 指標，月末回顧完成率與完成質量，綜合考慮評估每個團隊和個人的 KPI 情況；
2. 月計劃列表中的需求項根據重要性分爲高、中、低級別，級別越高需要越優先完成，其佔團隊和個人 KPI 比例也越高；
3. 一個月分爲 S1 和 S2 兩個迭代，原則上每個迭代兩週，在需求和任務分配時會明確指定其所屬的迭代以及 deadline（提測、上線）。一般 S1 需求的提測時間（如果需要測試人員參與的話）在每月的 12 - 15 號，上線在 16 - 20 號。S2 需求提測一般在 18 - 24 號，上線在月末之前；

需求

1. 從需求類型上分爲產品需求和技術需求。產品需求由產品提出（需求來源：客服、運營、用戶），產品經理跟進；技術需求主要針對系統技術層面的優化，由技術人員提出、技術經理跟進；
2. 從需求接收方式上分爲迭代需求（計劃需求）和臨時需求（綠色通道需求）。迭代需求月初由產品、技術通過評審會議確定放入月迭代列表中，作爲產研團隊、小組以及個人月 KPI 的重要依據。臨時需求是月中由產品或其他需求方臨時提出的、緊急的（一般是走綠色通道的）需求，產研團隊根據目前任務飽和度決定是否要調整迭代需求列表（即劃掉某些優先級較低的需求）；
3. 未經評審的需求放在需求池裏面（主要是產品人員關注），評審通過並決定要在本月開發的放入發佈計劃裏面（設計、產品、研發、測試等都會關注）；
4. 需求評審：小的需求評審一般是產品 + 相關技術人員參與，中大型的需要技術經理、測試人員甚至包括產品總監、技術總監的參與。需求評審大體分爲產品評審和技術評審兩個環節，產品評審由產品人員內部進行，主要考察產品層面的可行性，產品評審通過後進入技術評審，至少要有一名技術人員參與，主要考察技術實現可行性；
5. 跨迭代的需求一般需要拆分成多個子需求，分迭代實現；
6. 需求要拆分成若干個任務分配到具體的責任人（策劃、設計、研發、測試）。其中技術任務由技術經理拆分並分配到技術人員（也可能是技術人員自己認領的）；
7. 技術任務分配原則：由技術經理和相關開發人員共同討論解決方案並評估工時（人天），一般技術經理會根據每個人的工時飽和度 + 熟悉度綜合考慮任務分配；

開發

1. 開發人員接收到任務後，自己根據實際情況 + 需求優先級安排開發；
2. 開發人員和需求處理人需及時變更相關任務和需求的狀態，確保需求能夠及時流轉；
3. 團隊在每日站會碰頭，每個人闡述自己昨日工作、今日計劃、整體進展。站會建議控制在 15 分鐘以內；
4. 針對每個需求，開發人員需要從 master 拉取獨立的分支開發，不可在同一個分支上開發多個需求，因爲這樣會導致多個需求相互影響，無法獨立發版；
5. 對同一個項目的同一個需求，不同的開發人員建議都使用同一個分支開發（如前後端人員），避免相互合併代碼的麻煩；
6. 創建開發分支：

	- git checkout master
	- git pull --rebase
	- git checkout -b feature-songlin-coupon-list
	- git push -u origin feature-songlin-coupon-list

1. 同一個需求涉及到多個開發者（甚至是跨團隊）時，需要有一個主負責人。主負責人負責協調大家進度，統一提測、上線事宜；
2. 當某個項目發佈生產併合併到 master 分支後，該項目的其他開發人員應當及時將 master 最新代碼合併到自己的開發分支；

提測

1. 某個需求的所有方面都開發完成並自測/聯調通過後，由需求主開發負責人統一寫提測郵件；
2. 提測郵件內容：
   • 標題：【提測申請】需求名稱
   • 收件人：測試組
   • 抄送人：研發組、相關產品人員
   • 正文：
     1. 概括說明本需求內容；
     2. 對應的需求鏈接；
     3. 項目（git 和中文名稱）、分支；
     4. 開發、產品人員列表；
     5. 需測試的功能點提示列表（特別是隱藏功能點）；
     6. 其他注意事項說明；
3. 提測後，主開發負責人需要及時變更需求狀態，改爲“已提測”，相關開發人員需要及時變更自己的任務狀態；
4. 提測後，相關開發人員可着手處理其他任務，但需要及時關注測試動態，對於測試提出的 bug，需第一時間解決，或者跟測試溝通緊急度來協商解決時間。原則上，應當在一天內解決。不可因 bug 長時間未得到解決而影響測試進度進而影響整個項目進度；
5. 測試人員測試通過後，會回測試通過郵件，開發人員收到此郵件後，需及時準備預發佈；

預發佈

1. 主開發負責人收到測試通過郵件後，需及時準備預發佈事宜。
2. 從最新的 master 分支拉取 release 分支：

	- git checkout master
	- git pull --rebase
	- git checkout -b release-20200313.01 # 如果當天已經有其他發版了，就接着往後編號，創建的分支不可與已有分支衝突
	- git merge --no-ff feature-songlin-coupon-list # 合併自己的開發分支
	- git push -u origin release-20200313.01 # 推送到遠程倉庫

3. 在提測郵件的基礎上寫預發佈郵件：

   • 標題：【預發佈申請】需求名稱
   • 收件人：運維組
   • 抄送人：測試組、研發組、相關產品人員
   • 正文：
     • 告知運維，測試已完成，申請發佈預發佈
     • 項目：項目名稱（git 倉庫名稱）
     • 分支：release-20200313.01
     • commit: 308d0bf831acb149a0dc5e348f83cef25adafd0a（目前我們採用分支發版策略，沒有使用 tag 策略，所以同時要提供 commit）
     • 以上“項目、分支、commit”，如果涉及多個項目，按照發版順序依次列出
     • SQL 語句（如果有。如果很多，需要以附件提供。需提示 SQL 執行風險）
     • 其他事項說明
   • 例如：

   hi，運維：
   測試通過，麻煩發佈到預發佈環境驗證。

   1.財務結算系統（負責人：張三）
   分支：release-20200313.01
   版本：e4371a569affe13862561b7aa3d5b939c9216aa7

   2.券系統（負責人：李四）
   分支：release-20200313.02
   版本：9aca2d369826fd294b77fc23499d43654525212f

4. 運維發佈後，由測試人員測試。

生產

1. 測試人員在預發佈測試通過後，會回覆測試通過郵件；
2. 主開發人員收到測試通過郵件後，需及時編寫上線申請郵件：
   • 標題：【上線申請】需求名稱
   • 收件人：運維組
   • 抄送人：測試組、研發組、架構組、相關產品人員、其他利益關係人（如運營）
   • 正文：
     • 告知運維，預發佈測試完成，申請上生產環境，自評發佈風險（低、中、高）
     • 如果相對於預發佈環境的 commit 有變動，則要重新在此說明（原則上不允許）
     • SQL。如果很多，則以附件提供。評估 SQL 執行風險
     • 如果有多個項目，說明發版順序
     • 回滾方案
     • 其他注意事項說明
3. 上線申請郵件需要技術經理審批，高風險發版需要研發總監審批。技術經理需要審覈分支代碼（如是否 master 最新代碼、是否有明顯的錯誤等）、發版流程、SQL、發版是否衝突，並評估發版風險，給出發版時間建議。一般低風險可以在白天非高峯期發佈，中、高風險需要在晚上 11 點以後發佈；
4. 上線後，開發和測試人員需及時驗證，並密切關注外部反饋，有問題及時回滾；
5. 上線成功後，由各項目負責人將發版的 release 分支代碼合併到 master，並在羣裏告知團隊成員；

附

參照Git 分支管理實踐