頻繁交付已不是問題,真正的挑戰在於品質

DevOps Pipeline image from Microsoft

上面這張圖,是我在講 Azure DevOps 的時候,時常跟學員分享的Pipeline,裡面粗略的談到了CI/CD Pipeline及其前段(版控)與後段(持續監控)所涉及的相關技術,可以讓對於DevOps完全沒概念的學員得以稍微一窺究竟。

但每當我繼續問學員:『你現在知道有這些內容了,那…CI/CD的目的到底是什麼? 實現CI/CD對於企業來說究竟有何好處呢? 』學員突然被問到,有時一下子會無法立刻反應過來。

我繼續說到:『倘若,CI Pipeline的主要目的是為了實現持續整合,而實現持續整合的主要目的則是為了持續交付。那…為何需要頻繁交付呢?』

過去一年,你一定有上網預約疫苗的經驗,如果沒有,你大概也有上網登記五倍券還是某種OO券的經驗,再沒有,你疫情期間總有過上網購物吧。

倘若,你上網登記或購物時,網站突然有問題,或是購物車的金額計算不太正確,你通知了網站營運單位,他們也告知您會立刻著手處理,這時候的你,會希望網站多久可以更新或修復?

一小時? 一天? 還是一兩個月?

同學幾乎都跟我說:『立刻,不然我就換一家網站購物囉~』。

是啊,立刻。

既然我們都這麼要求其他人,那我們自己所建立起來的網站呢? 能不能經得起這樣的要求? 當我們的網站有問題,或是客戶提出新的需求時,我們能夠多快的將新功能或修正交付到用戶手上?

而且你知道的,緊急狀況下,往往兵荒馬亂,即便你知道程式碼在某個地方可能有錯,但這段程式碼最初不是你寫的,你敢立刻改嗎? 你怎麼知道不會改了這邊,就壞了另一邊? 你怎麼知道這個修正會不會引起其他額外的副作用? 有些時候,程式碼明明在你的電腦上是好的,但整合了團隊中其他人開發的程式碼之後,佈署到測試機上,就是無法運行,怎麼回事呢!?

就算開發人員真的把所有問題都在測試機上改好了,是不是還要經過QA的人工測試把關才能交付給客戶呢? 但測試需要時間啊,如何才能實現『立刻』將成品交付給客戶?

上面這些,都是CI/CD想幫助你解決的問題。

持續交付,聽來很容易。也確實,因為技術的進步,現在要快速的把更新後的成品佈署到正式機上讓用戶使用,也許真的也不難。但你有把握在『快速』的同時,還能保有高品質與安全性嗎? 你有勇氣讓開發人員把程式碼修改完之後,透過Pipeline『全自動』的直接上版到正式機上嗎?

從你收到bugs或需求,一直到交付到用戶手上的這一刻,你能夠多快呢? 你的交付頻率,可以達到一周數次甚至一天數次嗎?

沒有持續整合,就沒有頻繁交付

也是,一周數次或一天數次的高品質交付,在幾年前聽起來似乎有點不可思議,但現在市場上很多網站或是應用服務,正以這樣的速度在和你的產品競爭,而你心中理想的交付,想要多頻繁呢?

然而,頻繁交付不是問題,真正的挑戰其實在於品質

現在很多網站或軟體服務的廠商,更新bugs也是挺『頻繁』的。只是這個頻繁,完全是『人工』所堆積出來的。當碰到問題,要求工程師加班熬夜立刻解決,一旦改好程式碼,開發人員自己在電腦上隨便按兩下測試一下,接著就直接把成品手動複製貼上到正式機,然後就…祈禱不要再出問題。這也難怪綠色包裝的乖乖會成為長銷商品了。

吃燒餅哪有不掉芝麻的,有bugs在所難免,特別是高壓又加班的緊張環境下,品質肯定會大打折扣,但工程師就在這樣的輪迴下一天天的過著日子。是啊,大夥拚著新鮮的肝,快速地把一堆含有潛在問題的產品交付到用戶手中,然後再快速的修復bugs,然後再快速的收到用戶傳來的新bug,然後…就這樣日復一日、年復一年,你覺得很有趣嗎?

頻繁交付的基礎,是頻繁的程式碼整合

而且,我們必須要在CI Pipeline當中,設法加入各種快速的檢查,以確保持續維持著高品質的產出,前面提到的單元測試,就是其中之一。但單元測試只是基本,除了單元測試之外,我們還應該要做靜態程式碼掃描,還應該要做套件的安全性掃描,我們要讓團隊適當地做Code Review,並且對程式碼的品質有方法、有步驟的持續進行提升,這些都是持續整合要做的事情,都做到了,你『才』算是有了一個持續交付的基礎。

沒找到真正的需求,就沒有有價值的成果

是不是這樣就夠了,差不多,但還缺一個重點,就是『需求』。

軟體開發的一切都是從需求來的,如果我們對需求沒有好的管理,我們的快速交付只是徒勞,有點像是薛西弗斯那個巨大的石頭,我們只是一次又一次,一再一再的奮力把成品快速的交到用戶手上,但卻沒辦法讓用戶滿意 – 如果你忘了需求才是一切的核心。

而需求是得要被探索和釐清的,特別是這個快速變化的時代。時間有限、資源有限,當我們想要快速將成果交付到用戶手上的同時,我們必須和時間賽跑,如何能夠快速地將用戶最需要的功能,在第一時間『先』交付到用戶手上,然後『再』持續慢慢地補齊用戶想要的其他功能,如何在交付功能之後,持續的蒐集用戶的真實反饋,調整開發的優先順序,把用戶真正需要的功能先實做出來,這其實是一門藝術。困難,但必須。因為找到真正能幫用戶產生價值的需求,才是軟體開發一切的根本。

持續高品質、同時快速的交付,是近代軟體開發一個很大的挑戰。現在我們已經有相當好用的工具(像是Azure DevOps)來幫助我們,作為頻繁交付的基礎。如果你還沒有開始,那如何善用工具來實現高品質的持續交付與整合,是你今年肯定該面對的議題。

留言

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

使用Semantic Kernel 建立自然語言請假系統

精彩(且驚人)的Semantic Kernel入門範例

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...