LINE Corporation 於2023年10月1日成爲 LY Corporation。LY Corporation 的新部落格在這裏。LY Corporation Tech Blog

Blog


遇到大排長榮,怎麼發大財啊? @ Test Corner

介紹

嗨大家好,我是JJ Lai,是 LINE TODAY QA。很高興這次可以在 Test Corner 中與熊大一起跟各位共襄盛舉, 今天要跟大家分享的是 LINE TODAY 在 Release pipeline 方面遇到什麼問題, 如何改變, 以及如何改變?

介紹

QA 應該在哪裡?

這一張圖大家應該都很熟悉, 也是借用來當今天的主題想像一下

如果這一個河道代表的是release 的pipeline , 大家覺得QA應該在這張圖的哪裡?

是在這艘卡住的長榮上面?旁邊的挖土機?在旁邊看的人?

LINE TODAY QA

在過去 LINE TODAY QA 就會是這艘長榮的船一樣卡住了 release pipeline, 我們需要保留很多時間來做測試, 才能安心地讓貨出去

我們兩個禮拜的 sprint , 保留給 QA 的 code freeze 需要 3-4 天, 這說明了每一次的 release  QA 都需要 block 住 3-4 來做測試(低消), 這樣怎麼快得起來呢?

現在我們就像旁邊的那台小怪手,我們希望能打通 QA 是 release pipeline 中的 blocker, 頂著很大的壓力一直挖呀挖呀~希望能增加 release 的速度

未來我們會希望我們品質內建在要deliver 的產品上, 就順順隨著pipeline deliver 到客戶的手上

為什麼要改變? 我們看到了什麼?

這是 Google 2021 所發佈的 state of devops 報告

裡面有四個指標來判斷開發團隊的水準到哪裡, 等級也分成四個分別是 Elite , High Medium , low

這四個指標分別是

  1. release 的頻率 – elite 可以做到一天多次的 release
  2. Lead time for change – Code commit  進去之後多久可以 deploy 到 real 的環境上 Elite 可以在一小時內就可以上版
  3. Time to restore service -  當service 遇到問題時, 需要花多少時間讓 service back to normal – Elite  也是在一小時內可以完成
  4. Change failure rate – 有多少的比例是需要 hot fix 的 15 % 以內算是不錯的

各位可以評估看看自己的 service 大概在哪一個等級

不改變,可以嗎?

LINE TODAY 的等級大約介於high & medium 之間, 不改變真的可以嗎?

2018的 前面 elite High 加起來有55%

到了2021年前面這兩個 group 加起來有66%

尤其時 elite group 增長快速, 從 7% -> 26%  幾乎成長 20%

Medium group 快速的縮小 說明大家都在進步

我們與大神的距離

這報告裡面顯示四項指標 elite  vs low 的差距

幾百倍快的 release , 還能有更好的 quality 可以減少了1/3 hotfix

當你系統出問題的時候, 每分每秒都在噴錢

你和你的老闆絕對會希望能早一秒修復是一秒

但是快速是一種能力, 是要慢慢培養的

想像一下~你們行業的領先者快速的前進拉開與你差距

又或者你是行業龍頭~但是後面的競爭對手快速的追上來

不改變?真的可以嗎?所以我們開始想要朝著大神的領域邁進

為什麼要改變? - 你老闆的角度

從這一份報告指出 elite vs low group, 軟體產出的差距可以高達1.4 倍, business outcome 可以增加 1.8 倍

你老闆聽了這個不會心動嗎? 調整做事的方法就可以增加收益還高達1.8倍

為什麼要改變? - 產業大大的角度

接下來我們來看看產業大大怎麼看待改變這一件事

騰訊身為中國科技三大巨頭之一, 老闆馬化騰在2013 騰訊年會講到:「我們很怕, 稍微不注意,跟不上就會倒下, 巨人倒下時, 身上還是暖的…」

那是什麼事情讓馬化騰有這樣的感概呢? 是當年的 Nokia …當年也是如日中天, iphone 一出之後, 手機版圖快速的崩跌…. 真的大公司就不會倒嗎?

如果有人跟你說我們的公司很大, 我們很棒不需要改變…想想 nokia, 想想馬化騰說的話吧

為什麼要改變? - QA 的角度

接下來我們從QA的角度來看看為什麼需要改變? – 這是今天最重要的投影片

這個三個圈圈的圖大家都應該不陌生, QA本質應該是追求品質要把產品顧好,  但是以往到QA手上的東西都需要花一點時間, 也就是要等, 那是不是把另一個圈圈也固定住了…就是便宜

當我們可以做到又快又好, 是不是可以拿著這張圖跟老闆看, 不用講什麼你老闆就會懂了~希望我老闆也有聽到這一段

Waterfall Pipeline

接著我們來談談可以怎麼改變

這是大家比較習以為常的工作模式,  接近 waterfall pipeline

每個角色都有各自的pipeline, 都是人為去判定是否能給下一棒, 有一定的標準嗎?

如果需要簽 release workflow  手真的不會抖嗎?簽下去代表我要負責任

有很多的人為決策在裡面, 有人從中介入就有等待的問提, 有等待就會有人來關心為什麼卡在這邊啊?有關心就會有壓力…這東西能不早點出啊

One Pipeline

One pipeline 的概念就是 去除人為的決策等待因素在裡面

如果code commit 進去之後, 自動地跑過dev unit, QA automation, security test  之後只要是綠燈就讓他一路的推倒release , 可以給 user 使用了

SDLC 2.0

要做到這一件事每個角色都升級, 所以他用2.0 來標記

各個角色都在講更廣泛的自動化, 當然要做到這件事也是需要其他角色的配合,不是QA自己就能改變的

但是QA可以是帶領推動改變的人,  這樣就會很有價值

Key Factors

想要做到這一點的關鍵技術就是 release train 加上 feature toggle

Release train 顧名思義就是跟火車時刻表一樣…時間到了就發車, 錯過就下一班吧

如果你說台鐵時刻表都在誤點噎….恩~那我們以高鐵為例好了

在這個 sprint 做的東西不管有沒有做完都用 feature toggle 包起來, 跑過所有 automation 檢查就這樣 deliver 出去到 real 的環境上了

每一個 feature 都有他對應的 toggle

大家一定會問, 那QA的 feature test 呢?

如果新功能 toggle 在 real 環境 default 都是關起來的, QA 可以在任何時候在 beta, rc 甚至 test in production , 做完該做的測試之後再打real toggle 打開

而且你測完一個功能就可以打開一個 toggle, 部分功能就可以先去市場試水溫, 不用等整包一起出去

How to do - Goal

剛剛講的是key factor , 如果完整要做的事還有很多

借用 DevOps release cycle stage 可以分別填上幾項可以做的事

最困難的地方是什麼?

面對改變最難的不是方法,
而是知道“不知道”。 最重要的是讓大家先有問題意識

讓不知不覺的狀態中醒過來,  這也是為什麼我前面花了那麼大的篇幅跟大家解說改變的重要

方法有千百種都可行, 最難的跟團隊溝通“改變”, 我花了數十個小時跟團隊溝通未來的走向和方法, 慢慢才取得的支持和共識

我希望帶領團隊思考的方向是為什麼我們要這麼做, 怎麼樣可以改善我們平常的工作流程, 而不是老闆說要這樣做, 你們就給我做

經過不斷地溝通才能讓大家知道改變的精神跟前進的方向, 如果遇到之前沒有想過的問題, 他們也會用這種方式來思考,member 就可以自己找出答案了

這樣前進才會快速, 大家也才會有所成長

How to do – Magic Matrix

最左邊是我們的目標, 再來是目前的狀態

我們就先從QA內部開始討論, 問題可以是   你現在的工作模式有遇到什麼困難, 你覺得哪些可以更好, 可以怎麼做?

為了要滿足未來的方向, 有哪一些東西是可以在QA內部獨立完成的, 有哪一些需要其他單位幫忙的

你就會知道哪些東西可以先做, 等做到有一些結果的時候可以可以打下一關了, 我們想要往哪個方向前進, 也做了一些改變,  接下來需要你們的幫忙,  我們可以來討論一下該怎麼合作

一步一步地擴大影響圈, 如果你沒有這樣做只會得到一個答案….要改變的東西太多了, 我們只好改天了

No Code Freeze? 變快是否就要犧牲品質

品質是QA存在的價值

Devops 的四大指標裡面除了快之外, 還要減少hotfix的數量

想一想code freeze 之後QA做了哪些事?

RT & ET ? 從 ET 做完之後到上線前還有再測試嗎? 

從最後一次測試到上線放置了多久的時間?  2 days ?

RT 沒有不見,只是被 auto 取代了, ET 的時間比以前更多了 → 這樣應該要比之前更有信心?

如果新功能都是被 toggle 完整包覆並 deploy 到 Real 上, 之後 QA 可以在 beta / rc 打開 toggle 進行 functional test and ET, 測到有信心再打開 Toggle (Real)

測試的時間反而更多,想測多久就側多久....

如何增加Pipeline 的信心?

你們對你們的pipeline 有信心嗎?

跑過automation 亮綠燈就敢直接推上real 嗎?

如果不行, 理由是什麼?

  • 是更多的 unit test 嗎?
  • 更多的 Test case ?
  • 還是更多的 auto test?

這些我們都寫很多, 但問起來最後還是沒有信心

我們也花了很多時間在找答案,  大家也可以找找你們的答案

我們認為有些重要的 case 沒有被變成 auto, 那怎麼去取得大家的共識呢?

為什麼要寫AC (Acceptance Criteria) ?

之前網路上的熱門話題

低消一杯飲料 大家怎麼解讀呢?

  1. 是每人低消一杯飲料
  2. 還是只要多點一杯飲料的錢?
  3. 還是一桌低消一杯飲料?
  4. 開水可以嗎?
  5. 小孩怎麼算?

這些問題就是大家的認知不一樣, 各自用自己的方法去解讀了

這在軟體工程很容易看到, 也是我們極力想要解決的問題

想要工作的有效率, 就是要一次把事情做對

為什麼要寫AC就是想要解決這件事, 搭配實例化需求的方式

讓所有的角色對Task 的認知都是一至的, 我們也可以把 AC 轉成Automation, 確保這個是每個人都在意的點, 而且認知一樣

這樣才會整個,測試 automation ,以至於pipeline  才會有信心

大神說

在 LINE 的組織裡面有來自各個專業的大神, 除了很多之外人也都非常的好

在溝通的過程一定會遇到一些阻力, 我們家的斑馬大神就會鼓勵我說

如果你的 idea 沒有引起很大的爭論,  那你的 idea 就不是什麼偉大的東西

跟我一起想辦法說服其他人, 可以跟這些大神們工作, 真的很幸福

結尾

我在年輕懷疑人生的時候, 流浪到了一片蘭嶼的海洋

當地耆老告訴我一件事情讓我印象非常深刻, 我想在這邊跟大家分享

蘭嶼人每天都在跟大海中生存, 常常會遇到不知名的海流把人帶往他處

老人告訴我, 遇到海流不要怕, 第一件事就是看清楚海流要到你去哪裡? 如果恰巧方向跟你想去的地方一樣,  你該做的事只有讓自己好好待在這海流上, 不用太費力就能到你要去的地方

如果方向不是你想要的, 你就飄著飄著慢慢離開這個海流, 再往你的方向前進

千萬不要直接朝著逆著海流的方向死命的游, 結果只會有一種….就是你筋疲力盡的沈到海底被帶走…..

希望大家會喜歡今天的分享,  如果喜歡今天的主題的話~請幫按讚分享喔~並留言敲碗後續的分享, 如果反應熱烈的話~我們會考慮下次再來分享實際改變的心得

我是JJ 感謝大家的參與

最後,如果對於加入 LINE 大家庭有興趣的各位,歡迎參考以下:

活動小結

立即加入「LINE 開發者官方社群」官方帳號,就能收到第一手 Meetup 活動,或與開發者計畫有關的最新消息的推播通知。▼

「LINE 開發者官方社群」官方帳號 ID:@line_tw_dev

關於「LINE 開發社群計畫」

LINE 於 2019 年開始在台灣啟動「LINE 開發社群計畫」,將長期投入人力與資源在台灣舉辦對內對外、線上線下的開發者社群聚會、徵才日、開發者大會等,已經舉辦 30 場以上的活動。歡迎讀者們能夠持續回來察看最新的狀況。詳情請看: