閒聊-你敢不敢幫請假的同事編譯程式上線?

前幾天,參與的專案遇到緊急狀況,剛改版的系統有一段邏輯因正式台資料與預期不同而出錯,需要緊急換版,負責的同事因故無法即刻救援,改派我代打上陣。有一段時間沒參與,我對最新開發進度有點脫節,本次代打任務形同開發團隊的一次臨時抽考。

在我的開發機器開啟Visual Studio,先從TFS版控抓回最新的程式碼版本(Get Latest Version),檢視問題程式的修改歷史(View History),使用版本比對(Compare)功能找出本次修改位置,與PM確定規格後修正程式重新簽入(Check In),再利用先前設好的建置定義(Build Definition)由TFS Build Service抓取修改後程式碼編譯並部署到驗收測試環境,確認問題修復後由OP將程式上到正式台,危機解除,通過隨堂測驗!(下圖為TFS常用版控功能的示意)

任務完成後內心升起小小成就感:寫了十幾年專案,一路學習更完善的原始碼管理(雖然沒有很積極,而且多是同事主推,我拿香跟著拜 :P),終於有這麼一天-當事人不在,專案其他成員都也敢放膽修改程式上版,不擔心版本錯亂!

想到一項有趣但中肯的原始碼版本管控水準衡量指標:「你敢不敢幫請假的同事編譯專案上線?」

依我的觀點,要實現的關鍵有二:程式碼永遠只從版控取最新版本、編譯上版作業一律由自動程序執行。

前者是目標,後者為手段。每次上線建置一律由版控系統抓最新版,可避免上線程式混入某人硬碟才有的特有版本。不能精準掌握線上系統的原始碼版本,意味著不保證下次還能編譯出一模一樣的程式。「上次明明修過的Bug,換版後又冒出來」、「Bug修好了,上個月加的新功能卻消失了」… 一直是開發團隊的惡夢。

解決這個問題要從「禁止使用來路不明程式碼編譯上線」做起,任何時候,要上線的程式只能來自版控系統最新版本,只要不是從版控抓的就叫「來路不明」,防堵「要靠某人電腦D糟才能編譯正確版本」的危機。

即便所有程式碼都進版控,只要編譯過程允許人為介入,還是可能產生疏漏,因此要做到「編譯上版作業一律由自動程序負責」。人工操作常隱含陷阱,像是編譯前忘記抓最新版、編譯出錯時為求省事靠手動排除。前者會造成版本錯亂,後者讓其他人無法重新編譯出相同結果,都很惱人。要徹底解決這個問題,「人類閃開,讓機器來」-使用自動化編譯程序,程序一律由版控取回最新版編譯後再部署到測試或正式主機,不需要任何人為介入。若遇上編譯失敗或結果不正確,只能靠修改版控裡的程式碼克服。如此,才能確保任何人啟動自動編譯部署的結果都相同。

整理一些執行要點:

  1. 版控!版控!版控!
    不管是你是用VSS、TFS或是Git/Github,都好,確認所有重要專案都有進版控,少了這一步,其餘免談。版控系統確保所有人的開發成果都被彙整妥善保管,必要時可以追溯修改軌跡,甚至能改變所有的錯,讓我從頭改過…
    另外,一旦開始依賴版控,別忘了為版控系統規劃備份機制,省得天有不測風雲,所有努力化為青煙。
  2. 不要Check In任何還不打算上線的程式碼
    程式碼一旦Check In,就會被編譯進要上線的版本,但實務上不可能等到程式全部改好測完才Check In,開發過程三不五時要Check In才好保留軌跡。針對較複雜的修改或新功能開發,可在版控切出Branch並行開發,完成後再Merge回線上版本,在Branch裡即可自由Check In/Check Out,不必擔心影響正式系統。
    還有一種做法是一開始就Branch出開發版跟上線版,開發人員永遠Check In進開發版,要上線時再逐一列舉項目Merge回上線版。這種做法更嚴謹,隔離性更佳,但每次上線要詳列更動項目,手續較為繁瑣。
  3. 貫徹「編譯上線工作一律由機器執行」
    前面提到編譯上線不交給人工處理,才能貫徹「永遠使用版控的最新版,誰來執行都得到相同結果」,也不會出現「忘記Get Latest Version」這類失誤(某中年程序員慚愧低頭 orz)。要執行自動編譯上線程序,我們過去用過CruiseControl.NET,現在則逐步改用TFS Build Service。開Visual Studio人人都會編譯,改成自動程序時要改用MSBuild,雖然不難,但仍需要花點時間學習。

當然,在軟體工程領域,這一步之後還有更美妙的境界-整合自動測試,每次編譯後先跑測試,驗證功能無誤後再上線。到此境界,不要說替同事編譯上線,就連保全大哥、茶水間阿姨、林志玲、陳妍希… 人人可以幫系統上線不擔心出亂子,很美吧!而我們離那塊流著奶與蜜之地,仍有西天取經般的距離。

有很長一段時間,每次編譯上線都提心吊膽版本錯亂,到今天進步到「膽大包天敢代替同事上程式」,能達此境界老骨頭內心已十分有感,也祝福大家早日走到這一步。

歡迎推文分享:
Published 11 May 2016 08:05 AM 由 Jeffrey
Filed under:
Views: 7,923



意見

# 陳小風 said on 10 May, 2016 09:39 PM

我們在關於第2點的作法是,使用 Git 搭配 Git flow,讓每次的新功能都是獨立的 Feature Branch,加上如果 Commit 都有綁定好工作項目,在發送 Pull-Request 時就會自動將所有的工作項目整理起來一目了然,如果有使用到最新的 Release Management,連這次 CI 上線的工作都寫的清清楚楚,不需要花太多的時間人工整理這些資訊喔!

# Jeffrey said on 11 May, 2016 08:18 AM

to 小風,事前功夫做足,事後手續就會簡化,學習了,感謝分享。

# franma said on 12 May, 2016 01:15 PM

善用擱置讓你更開心 :)

你的看法呢?

(必要的) 
(必要的) 
(選擇性的)
(必要的) 
(提醒: 因快取機制,您的留言幾分鐘後才會顯示在網站,請耐心稍候)

5 + 3 =

搜尋

Go

<May 2016>
SunMonTueWedThuFriSat
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234
 
RSS
創用 CC 授權條款
【廣告】
twMVC
最新回應

Tags 分類檢視
關於作者

一個醉心技術又酷愛分享的Coding魔人,十年的IT職場生涯,寫過系統、管過專案, 也帶過團隊,最後還是無怨無悔地選擇了技術鑽研這條路,近年來則以做一個"有為的中年人"自許。

文章典藏
其他功能

這個部落格


Syndication