每到出版本build load的日子，PL/PM總是緊張兮兮，實在是因為常常狀況會很多，要不是RD來不及解不完bug，就是build load會fail，也可能版本出來了，但是一開機就當機，想罵人還不知道要罵誰，得先想辦法找出兇手才行。
其實build load時不只是PL/PM緊張，RD的壓力也很大，因為build load時間就是deadline，RD要在deadline前解完bug上code。Build load的時間一般都會安排在大半夜，因為這樣一大早VT就可以拿到新的版本好展開一整天的工作，所以常見一堆RD加班到大半夜趕著在build load前上code，也造成build load前一二個小時會有大量上code的情形。如果build load時間到了，卻還沒來得及解完bug上code，那project delay的大帽子很可能就會扣到自己頭上，頭髮又不知道要掉幾根白幾根了。前公司會每天用mail highlight bug和bug owner，build load前更是會列出MUST Fix的bug。RD通常還可以忍受每天被highlight，但是最怕的就是好不容易解完手上明天凌晨要build load的MUST Fix bug，正在開心地吃晚上便當時收到mail，發現自己突然又多了幾筆MUST Fix的bug，掙扎著是要當做沒看到，還是咬著牙吞口水認了。若在星期五，那跟女朋友的約會又要泡湯了。
負責build load的SCM(Software Control Management)也很忙碌，要改版本和release的內容設定，重大project可能還會先來一次pre-build看看有沒有問題。如果不小心有多個project同時要build load，還得協調一下先後次序，看誰的priority高。然後一大早出門上班前先檢查一下半夜build load的結果是成功還是失敗。還好大部份SCM的工作都是可自動化的，不然多個project一起來時，靠人也是很容易出錯的。
一旦software load build好了，VT就會接手測試的工作，當然先做基本的Sanity Test。原則上Sanity Test的test cases都是很基本重要的，如果出現fail的case表示這一版的load是不能用的，因為最基本的品質都過不了，VT是不會也不應該繼續測試的。PL/PM要先解完Sanity Test fail的bug後，再重build一版。當Sanity Test pass時，VT才進入Full Functional Test或Free User Trial Test，之後就進入VT發bug、RD解bug和build load的循環，直到VT認為這一版達到release或MP的品質為止。
隨著bug的持續收斂，project愈後期應該會愈穩定，但也因為離project的deadline愈近，大家對時間的量化單位也愈來愈小，從一週到一天，一天到半天(台灣的RD一天有三個半天，上午、下午和晚上），半天到小時，在時間壓力愈大的情況下就愈容易出錯，PL要有夠強的心臟才不會慌亂，而要有夠強的心臟則靠平時的準備。以出版本來說，主要角色就是PL/PM、RD、SCM和VT，而PL/PM是要確定build load前後每個角色負責的工作能夠做好，版本才能成功的release。列一下一般PL/PM應該要做的事：
１、決定build load的時間，並告知所有人
重點不只是build load的時間，還有什麼時候通知大家build load時間。要build load前一天才跟大家說明天要build load，就跟之前提到RD build load前才收到MUST Fix的bug一樣，會讓人措手不及。如果PL/PM對project是有計劃的，會很清楚下一次合理可預期的build load時間是在什麼時候，甚至release這一個版本時同時就公告下一版build load的時間。
想要準確預測下一版build load的時間需要掌握幾點：
A. SCM build load的時間
前公司之前build load的時間需要花5個小時，如果在白天做build load，那幾乎一天就不 見了，所以大都安排在半夜。當然後來改善build load的機制和流程，以分散式build load 縮短build load時間到1~2個小時。Project後期是以小時為時間單位的，所以SCM build load的時間是不可忽略的。而且SCM是跟其他project共用的資源，要確定你的project build load時間不會跟比你priority高的project衝突。
B. VT測試的時間
包含Sanity Test和Full Functional Test的時間，這個相對簡單，只需要問VT就可以得到答 案。只是VT也是共用的資源，一樣要確認跟其他project衝突的問題，確保你的VT資源 不會被搶走。如果有可能被搶走，那就是project的risk了。
C. RD debug的時間
這個需要一些過去的經驗值當參考，而且每一輪測試的bug數量和難度也不一樣。一般 來說第一次Full Test的bug數會比較多，但是大多是表面UI和Flow上的bug，難度較低。 再來的Full Test bug數會減少，但是難度較高，大多是Interrupt或系統類的問題，很多甚 至是很難重現複製的。前期大量的RD投入，因為bug門檻低是可以加快debug的速度， 但是後期的bug需要高度專業的RD，這時反而像System Team的RD資源會吃緊。而過去 project在相同階段時RD需要的debug人力和時間也是重要可參考的數據。除了參考過去 經驗之外，更直接的是在bug review時，多問一下RD認為bug的困難度和複雜度有多 高，有信心花多少時間可以解掉bug，累積統計一下所有的bug，可以得到更準確的數 字。
當然你也可以不用上面這種正推的方式，而是從project schedule的deadline反推，例如進 Verification Test階段後，只剩一個月的時間，而至少要做二次Full Functional Test，可以 一次分得二個星期，扣掉SCM和VT的時間，就是RD debug的時間。而反推的風險是時 間是強壓式的，如果debug時間還有可為，那考驗的是PL/PM的project management能 力，如果debug時間讓大家都覺得根本不可能，那會打擊士氣，甚至有些RD會有放棄的 想法，對project就很危險了。拿出＜老闆說＞的尚方寶劍可能有用，但是如果已經拿出 來太多次了，大家對你的能力產生懷疑時，這把劍也會鈍了的。
上面的說法感覺RD要等VT都跑完測試後，才會收到bug report，debug才會開始，在實 務上不見得一定如此。如果是委外或使用客戶的VT資源，有可能會因為對方的作業規 定出現這樣的情形，不然以自己公司內部的VT來說，VT是可以每發現一筆bug就回報 一筆bug的（PR系統），當然RD就可以馬上開始debug。也就是說，VT的測試時間和 RD debug的時間是會重疊的，也許只有半天或一天的落差（PL可以請VT一發現bug就 馬上回報，不要等測試到一個段落才整理回報，如果可以縮短落差的時間），換句話 說實際上RD debug的時間是（原本的RD debug時間＋VT測試的時間－bug開始回報的時 間落差）。PL/PM有沒有覺得debug的時間突然多出來不少呢。
Build load的時間決定了，就要儘早發出公告通知到所有人，包括PL/PM、SCM、VT、RD、Function team manager和老闆。讓大家都知道你的build load時間，如果有其他project衝突時也有時間可以協調。
２、定義bug的priority和MUST Fix
時間有限，想更有效率的集中RD火力在有價值的bug上，PL需要定出bug的priority。一般VT在回報bug時就會以VT的角度設定bug的priority或是severity，而且在review bug時也可以重新視實際狀況調整priority。如果bug數量太多，RD無法解完所有的bug時，為了有效集中RD的火力，設定MUST Fix的bug範圍就有必要和意義。
在挑選MUST Fix的bug時，以重點式挑選為主，會當機的、會block其他功能測試的、Key feature的bug等，應該都是重要且嚴重的MUST Fix。當然最好是可以跟VT一起review挑選，VT會有自己的經驗直覺，可以發現外表看似一般的bug可能背後是有嚴重的問題。
Must Fix要注意的是，千萬不要太多，太多的MUST Fix就是沒有MUST Fix，差不多佔bug數的30%左右或抓一個要努力才解得完的數量是比較合理的。如果經常發生MUST Fix的bug每次都解不完，卻每次都還是可以build load，久了RD就會認為MUST Fix只是參考而已。反之每次MUST Fix都有解完，順利build load，大家對project就會很有信心，士氣可以維持在高漲狀態。
３、注意有問題的bug和RD
在review bug時就會知道有哪些是有問題的bug，有問題的bug是指有技術難度、跨多部門、嚴重卻很難複製、需依賴外部資源（例如實驗室、國外protocol網路環境）等需要較多資源或時間才可能解決的問題，這些往往不是RD個人自己可以處理，需要PL介入協助才行。
有問題的RD指的是身上掛bug數太多的、loading太重的RD（如太多bug都需要system team RD幫忙分析的）和平時狀況就很多的RD。PL要多關心這類型的RD狀況，要想辦法提供協助。
PL/PM要緊盯這些問題，因為大部份所謂的意外，都是從這些地方產生的。
４、事先協調SCM和VT的資源和時間
SCM和VT是共用的資源，需要事協調好避免衝突。尤其是VT，VT資源如果有衝突，往往都是好幾天的影響，先確定好VT的時間後再決定build load的時間是比較好的方式，也可以做較好的安排。
５、建立daily build機制和測試值日生
Daily build是一個每天自動化build load的機制，時間也通常安排在凌晨，所以一大早RD值日生就可以檢查build load是否成功，並做一個小時左右簡單基本的測試（可以有自動化測試和精簡版的Sanity Test），發個mail出來通知大家daily build是否正常，有問題的請owner儘快處理。
如果認真看待重視Daily build，它可以帶來很多好處：
Ａ、每天都有一個check point，檢視軟體的品質，不用等到official build load時才知道build fail的問題。
Ｂ、幫助RD debug，因為有daily build存在，RD可以快速夾擊出是bug是從什麼時候開始出現，可以快速找出是哪一個check in的code產生的side effect。RD也可以有一個經過系統整合的版本來驗證自己昨天解的bug是否正常，避免自己local環境造成的盲點。
Ｃ、提早發現問題，會build fail、log有warning或測試有問題，都可以提早發現，提早處理。
Ｄ、軟體穩定度的指標，從一個星期daily build fail的次數也可以看出來軟體的穩定度和RD對軟體品質的要求程度。從fail的次數愈來愈多或愈來愈少，也可以感覺出來品質穩定的趨勢。而如果造成daily build fail的RD是慣犯，那也是有問題的RD，需要多加注意。
Ｅ、要求RD重視上code品質，daily build fail會影響很多人的工作，重視daily build也是在要求RD對品質要有更嚴格的把關。當大家對品質有基本要求的共識時，那麼official build也就跟daily build一樣，只是換個名稱而已。
Ｆ、大家輪流當值日生，也是讓大家習慣維護daily build品質的責任，自然也可以提高大家對品質的要求。
然而daily build畢竟是累積了一天上code的量才build一次，平時可能一天只有幾十次上code，但在build load前一天可能會有幾百次的上code，daily build還是有不足的地方。較好的做法是每次RD上code，都可以build一個版本，並做自動測試。前公司的VM系統可以做到RD不能直接上code，而是在要求上code時，系統會先整合RD要上的code，build出一個版本，該版本通過自動化測試之後，RD才會拿到可以上code的權限（token），然後才能真正上code。這種透過機制來對品質把關有個缺點，就是上code需要等待build load和測試的時間，效率上雖然慢了點，但是為了保障品質還是很值得的。
６、必要時lock files，只check in重要的bug
通常是在靠近出貨前的版本對穩定度的要求會高於解bug的數量，這時候可以對RD上code的權限有所限制，例如只允許解某些特定的bug可以上code、或經過嚴格review和測試之後才可以上code。
７、RD先做好基本測試再送給VT做Sanity
因為一般Sanity Test fail時VT會退回版本不做後續的測試，這一來一回其實已經浪費不少時間，而且VT的資源可能就被其他project給佔用了，對project schedule影響很大。所以在版本出來時可以先行做RD版的Sanity Test，能cover愈多VT版的Sanity Test愈好，但又不至於佔用太多時間。VT Sanity如果有自動化測試的部份，基本上可以在RD端建立相同環境先跑一次，在跑自動化的同時再做人工的基本測試，如果時間控制在一到二個小時左右，應該是可以接受的。如果不幸有fail的case還可以馬上處理，再儘快重build一版，那delay的時間也許還可控制在半天左右，也還是比被VT退版好得多。
在這些看似平常的日常工作上多用心一點，相信PL/PM就不會再害怕版本build不出來了!
沒有留言:
張貼留言