這是參與DevOps三天課程的筆記，概略的紀錄自己的心得！
Day 1
DevOps與Agile
DevOps講的是軟體開發與維運的管理，這其實是由最早的Software Engineering，一直到幾年前的Application Lifecycle Management，再到這幾年的DevOps。而DevOps與ALM或Software Engineering的最大差異在哪裡，其實就在DevOps承襲了Agile的觀念。
Agile的精神帶出了Scrum的開發方式，也由於Scrum開發方式是漸進式地提供軟體功能，快速頻繁的更新及佈署，當更新頻率由100天/次轉變為100次/天時，運作的機制及工具的需求都會大大的不同。
老師也帶出了微軟開發部⾨DevOps經驗談，當Visual Studio開發團隊將手上3700萬行的程式碼進行編譯時，一開始要花上6~8小時。所以在導入DevOps的概念後，首先垮的卻是工程團隊，因為無法應付這麼大量的編譯需求。
解釋架構的五個層次
- Value-一切的出發點，任何企業或是目標都要先確認Value是甚麼?Ex:Agile的Value
- Principles-由Value導引出Principles原則。Ex:Agile Principles
- Methods-有了原則，就可以帶出實踐該原則的方法論
- Practices-有了方法論，才會有實務上的實踐經驗
- Tools-每種實踐經驗，都有其對應的工具
可以用這樣的概念來解釋Agile，也可這樣分層方式去理解DevOps。網路上找到一篇文章What Is DevOps?，裡面就是使用這五個層次去解釋Agile及DevOps。
軟體開發與製造業的不同
軟體開發的過程是設計，而不是製造。WaterFlow是製造業的控管思維，所以套用在軟體開發上，反而不適用。
設計是一種漸進式的過程，達文西在畫「蒙娜麗莎的微笑」時，他的創作過程是由草稿開始，經歷塗塗改改，最後畫作才形成。
而非一開始就知道要畫什麼，一塊一塊的完成。
圖片來自於The Agile Mona Lisa
User Story
為什麼使用User Story而不是需求描述。User Story描述的是問題，但需求描述的是某人(PM或SA)面對問題的後抽象出的解決方案。UDAD強調的是團隊合作，以避免單一個人的需求錯誤。
相對於編寫好的User Story，產生和討論的過程更加重要。團隊建立統一的認知才是User Story的終極目標。
有兩個工具可以用來輔助建立User Story，都是建構在讓概念視覺化。 在探索問題時，可以使用Impact Mapping。這個工具會發散觀察及想法，以探索各種可能性及Solution。依序的使用四個問題：WHY, WHO, HOW, WHAT 來提供思考方向，當每個問題的解答寫出來後，整體概觀也就出來了。詳細的說明及建立方式，可以參考Ruddy老師的文章－看見的力量 – (II)影響地圖
以下是我們針對如何使一家電商公司三個月營業額倍增的Imapce Mapping
在這之後，可以使用User Story Map，讓我們想提供的Solution可以視覺化。這個工具其實會輔助我們先將欲提供的Solution分為三層-User Activities, User Tasks, User Stories，然後再依據優先順序切分出不同順序的Release。可以參考Ruddy老師的文章－看見的力量 – (III)使用者故事地圖
Day 2 - Scrum
Why Scrum Works?
Scrum的目標是在Agile的概念下，提供一套框架及規範做為團隊合作的標準。KanBan主要的目的是將工作狀態視覺化，一眼就可以看出瓶頸站及Pending的工作，藉此消除浪費，提高工作效率。
Scrum的產出是漸增的系統功能，之所以可以增進開發效率，可以類比為在生產線中，批量Size越小，整體的生產時間就越少，因為下一站的等候時間就越少。
課程中進行一個實驗，由６個人為一個團隊，工作任務是輪流將20個硬幣翻面。一開始的方式是20個硬幣全部翻完後，才交給下一個人，這是大批量的概念，花費時間約80秒。接下來是10個硬幣翻完後就交給下一個人，這是小批量的概念，花費時間約50秒。由這裡就可以看到，只是將批量Size縮小，就可以大幅減少整體花費時間。
老師有特別提到PM的觀念，在Scrum中，並沒有PM(專案經理)的角色。這是因為PM同時兼具使用者端(Product Owner)及開發團隊端(Scrum Master)的功能，而這兩個功能時常是相衝突的。以往的專案管理方式，是由PM自行消化及處理兩邊的衝突。也因此，PM的態度會大大的影響團隊的滿意度及使用者的滿意度 - 只能取其一。Scrum則是把這兩個角色分開，讓衝突攤在檯面上，由團隊自主解決，這是Scrum有辦法兼顧團隊的滿意度及使用者的滿意度的關鍵。
使用Future Branch
VSTS作為Scrum的工具，有一個很大的好處。就是可以自動建立連結各個User Story及Task之間的關係。這種資訊對於管理來說很有價值，可以在問題發生時，追蹤到問題的根源點。
VSTS可以使用Git作為Source Control，因此可以使用Git的特性，當有新功能需要開發時，可以依據功能別建立Branch。當開發完成後，可以在Pull Request的時候，使用VSTS的CI功能，在Merge時自動進行Build及測試。這樣的好處是，可以直接拿真正線上的版本進行測試，又不需要真實的佈署到Production環境。還可以設定Code Review及簽核程序，由資深人員進行Review，以及主管進行簽核後，新功能就會自動佈署到Production。
Testing
Testing無法產生好品質，Testing的產出只是產品的狀態。要有好品質，必須有一個流程來處理目前的狀態到好狀態的差異，然後重複執行這個流程
工具介紹-VSTS Testing-可以快速的錄製及建立Test Case，當發現Bug時，也可以一鍵建立bug到VSTS，並自動將測試過程及圖片附加到說明中。
工具介紹-Selenium-這是一個很方便的UI測試工具，可以用來產生對應的程式碼。也可以透過Nuget下載Selenium套件－Selenium WebDriver，裡面提供許多API以在UnitTest中寫程式進行實際的UI測試。
Day 3 - Docker
想要瞭解一個技術，必須先瞭解他要解決的問題。Docker想要解決的是在複雜多樣的硬體環境以及軟體架構下，系統部署的問題。
Docker的Solution取道於運輸業，他們把問題比擬於如何讓不同的運輸工具可以快速方便的載運不同的貨品。
運輸業的Solution是建立一個標準的貨櫃
所以Docker也建立一個Container的概念來作為佈署的一個單位，Docker可以讓任何的系統以及他所依賴的環境打包成一個獨立的、可攜帶性的、輕量級的Container，而這個Container可以快速的佈署在不同的硬體環境之下。
