這個 scuum team 水很深
- 用 devops 的觀念迫使每個人都要做測試
- 有3X個 team，每個 team 都有不同的 pipeline
- install/ upgrade automation
- test case development
- innovation automation
- 提供指導給 feature team ==> cool ，這是 test team 強大的觀點
- 版本不斷更新
- OS一堆
- test 一直fail
so we made lift => 動態去做測試
- 收到ticket
- 建環境
- ... 最後跑測試結果
- create environment 不順，要更順一點
==> 每個 VM 都要有一個 clean snapshot
- VM OS 只有一個，每次只能 run 一個test。其他就被卡住了
- 要同時 test 1.0, 2.0, 3.0 都要依序跑完...
- 中間 fail，後面全卡死
- 假如升 java 版本，每個版本都要升
- 自建 DSAF
- 為什麼換掉 因為很多 flaky tests
- 做一個把關，做 PR 前要跑過 500次 test，500 小時，要跑很久，48 小時內沒有 fail 才能進 master
500 次是算出來的， 500次大概是 0.005 的 fialure rate。
至少能保證有一定的穩定性。
- 推廣後，同樣的 test 知識，整個公司就好，大家都有同樣的知識base。
- 統一平台 test 的數據就能統計 �- 還是承認其他的測試工具
- install once, solve evenywhere
-
鎖 repo
-
先核心 team 來處理、各3位出來，先一起 code review。彼此開 100 條出去。(naming, coding style)
-
這個慘的狀況，經過好幾個 sprint 後，慢慢會收斂的、慢慢會有共識了
-
接著一個 team、一個team 拉進來，a team 帶 b team
-
Pull
- 有建立了好工具，就可以吸引人進來
-
Push
- 依賴的 old service 停掉
- manager 重視
- 最有影響力的就是 code review
- 要求 review time < 1hour
- reviewer 有權利拒絕 or 拆開
- retry 會得到 retry 的 flameGraph。看到哪個 stack 佔做多時間。
看到瓶頸，就會有人去想解法改善
- 也是有幫助的，講者推薦
- 我們想要的文化是，能不能多拿點資料出來。
- 證據
- pipeline 上百個，有1,2個 fail.. ，久了你就跳過它了
- 就是切 2 維資料
- Grafana =>> webhook 很好用，客製 alert
- influxDB
- Prometheus
- Jenkins
- Elas.. Search
- detail data 不收，只收 overview。user 要看 detail 再倒回去 test env 看 log
- SQL，追求統一、結構的資料
- cli，大家都好處理
- Platform name => Mapping table on Mothra(我們這邊的 mapping table，我這邊認定、統一)
- 用 ML 來預測這次 code change 可能需要哪些測試
data => commit data or code coverage, test 結果等等資料來訓練