DevOps Day 心得

website 大會共筆

Day 1 下午

hackmd

有看的行程

DevOps Overview - 陳正瑋（艦長）[13:20 ~ 14:00]
在 DevOps 的路上測試該怎麼進行 - David Ko 敏捷三叔公 [14:20 ~ 15:00]
Mastering incident communications - Kat Gaines [15:20 ~ 16:00]
DevOps 的高階工程實踐 - David Tung [16:20 ~ 17:00]

DevOps OverView

共筆官網

內容：

DevOps 現況

大家不談定義，一個DevOps 各自表述
目前大家的理解
devops 的歷史演變、定義
定義很多，10個人有11個定義
devops的層級
- 金字塔，由上往下
  - 價值觀
  - 工作原則
  - 實踐方法
  - CI/CD
  - 工具
XXXOps 巳成為的潮流

DevOps 起源

DevOps 原先只是在2009年時，在DevOpsDays 提出的hashtag
「DevOps源自於技術社群的互動交流，隨著各方人馬加入，才成為Buzzword」

DevOps 定義

各個企業、社群都有自的定義
- 共合點是「DevOps是文化」
以下為講師的見解
- 狹義: 打造一個流程(pipeline)，來協助IT更快的交付產品。
- 廣義: 是一場文化運動，由IT轉型改善的運動、帶動更多的改變。
DevOps 重視交付價值
沒有公認標準，但各方定義都很類似

DevOps 核心精神

原先有Dev, Ops 兩個團隊，Release後才交付給Ops，中間有一道牆。隨著組織發展越來越厚，要打破這個牆。
有 C(Customer),B(business),D(Deveploment),O(Operations)
目標不同:市場快速變化(CB)、產品需求快速變化(BD)、安全可靠(O)
角色如何溝通？
- Agile 敏捷快速使C,B溝通
- DevOps 使 D,O 溝通
順暢的交付有用的價值

總結與回顧

部署多快、多多次是指標，但不是目標，快速交付才是目標
- murmur:不過以我們公司的產品為例，不確定大家對快速交付的定義有沒有相同
思考價值從何而來?
- 軟體工程的價值在哪?要交付產品價值，只有dev重要嗎?
消除浪費、持續改善、讓價值交付最大化，克服 Silos 之間的一切摩擦
- silos: 公司橫向的溝通障礙
不只是DevOps而是調適性(Adaptability)
無需白紙黑字的定義，保持開放的態度
DevOps 並不是一場百米賽跑，而是一趟長久的遠程，並非一時說想要就能夠立即有成效

心得：

這個講座真的是很棒的初入devops。我覺得對做過一點devops工作後的人，特別有幫助，重新認知一些東西的定義跟現狀。有一個特別的部分是，可以感受到 ops ↔ dev 的gap，google提出的 SRE 這的部分是密不可分的，不能把 dev, ops分開談，或者說都很重要，如果變成某邊(Dev,Ops,Biz)太多的話，就會失衡。需求太重也是。

另外，Devops overview 這場的開頭，就是 dev ops 的合作，所以提到需要從公司的文化開始改 -> 形成原則 -> 接下來才是工具，我覺得現在公司缺乏的就是從文化上的改變

回頭再看一次，不需要定義是指對DevOps的，如果要執行時，仍然要有定義的原則、規定，這樣才可以有效的執行。要有可以測量的metrics和正確執行的政策，不然，就只是說說，喊喊數位轉型的口號。

在 DevOps 的路上測試該怎麼進行 - David Ko 敏捷三叔公

共筆官網

內容： (這場共筆超多，可以看看)

在快速交付的情況下，測試要怎麼進行？

要有QA，他們可以慢一個sprint
或是進行一個 harden sprint 增強 product

產品開發流程趨勢

新技術的接受度高:Cloud, AI
商業要滿足的三種人
- 客戶：
  - 問題可即時反應
  - 更快獲得解法
- 投資者：訂閱制
  - 黏著度更高
  - 收入可預測
- 員工：
  - 了解客戶用法
  - 不用衛護舊版
流程的目標
善用資料、幫助客戶成功

對測試所帶來的影響

迭代的交付(scurm-like)
沒空寫自動化測試
- 迭代時間短，只夠開發完程式
迭代越多、回關測試越多(regressio test, integration test)
測試環境組合變多
換手遊戲
- 只是名字換、工作不變、並不互相協作
- 測試人員合併回開發人員…
沒有全局觀
- 需求探索->開發->維運
- SA/PM談需求，需求黑洞
- 交給開發人員時，工具又不同
- 導致溝通中間破裂

新興測試流程

SCRUM開發流程
sprint內的開發、測試流程
- 開發開發程式時，測試人員就生成測試(e2e)
sprint之間的開發
- 下一個迭代在完成上一個迭代的automation test
測試階段與活動
- 跟人命、金錢非常相關的
- sprint demo: sprints in the begin fouces on developing and demoing
- Hardening Sprint: strengthen the product
端到端的實踐

關鍵的測試策略

整體原則
- 團隊負責>QA負責
- 持續測試>最後測試

團隊負責

團隊人員的技藝
- 基礎的知識要廣（環境）
- 獨門技藝要深
- new: 一門技藝不夠
要學/做你不會的
- QA做看看dev
- dev要測試看看有用的個案
母雞帶小雞
- 資深：80%手動，20%自動：擅長做測試
- 資遣測試、開發人員：80%自動，20%手動：擅長寫程式

持續測試

善用靜態測試（測試左移，unit test）
QA的職責不是測試到很多bug
安排安東繩機制
- 安東繩=CI pipeline + 紅色警戒 + 紀律
不太可能用測試來把關，一定要越往前執行
自動化策略
- 把測試自動化視為軟體開發
- 迭代進行
- 有層次、價值導向
自動化的代價在啟動和維護
母雞帶小雞：功力強的開發雛版，功力弱的增加個案
要追求開始，而非追求完美
不再多、要準和正確

如何開始第一步持續整合：CI一定要開始，每日至少兩次實例化需求:及早對需求有共識、讓不同角色加入討論探索測試：用較少時間、可找較多bug

心得

沒空寫自動化測試，完全是我們團隊目前的困境….，測試在需求很重的時候的，完全會被團隊忽略，先出功能再說，在SCURM估點的時候也常常不會把寫自動化的工算進去。

但後續出問題的時候(因為趕功能必定發生)，所以肯定又會提到要把測試左移，要大家趕快回頭補unit test，回頭的時候才補測試會花更多effort，原因是測試的情境可能忘記了，且重新補很花時間。這種狀況發生時，通常還會伴隨老闆要求繼續開發新功能，而忽略寫測試要花的時間。

目前我覺得最好的解法是，大家要對寫多少測試有共識，從老闆到團隊的人中，可以在一開始就把寫測試的effort計算進去才是好的方法，開發時就寫好單元測試。當然後續補救總比沒有好，前面沒有寫不代表就不補上了，如果是接手前人的code搞不好還可以從中學(清)習(理)。intergration test 的部分則是根據團隊的合作會有大幅度的差異，這部分就需要大家各自跟合作的夥伴協調。

QA是另一項，我們的團隊因為轉型成 DevOps 減少的QA的人員，也因為還在磨合適應新的工作型態，導致沒有QA的角色，最後變成自己上線測試(真的是一人一條龍)，聽完這個分享，讓我覺得應該還是要有這個角色的人，在PM <-> Dev <-> User 的過程中間先做好QA，確定功能皆正常。即使沒有這個人也應該把QA算在開發流程當中，大家都跟著流程走

(last edit 10/29)