微軟 DevOps day 2015 速記

快速記一下今天聽老師們聊 DevOps 的心得，詳細錄影等 channel9 了。
軟體開發跟 flamenco 的共通點是，都需要每種東西都學一點，都很混雜。
謝謝微軟精心準備這些課程，謝謝公司讓我去聽。

http://blogs.msdn.com/b/msdntaiwan/archive/2015/11/24/devopsday2015.aspx


某講師: "人都是求安穩，抗拒改變的，你沒事說要引進新方法，一定會遭遇阻力。
所以一個企業要引進新方法最好的時機，就是遇到問題的時候，公司快垮掉的時候。大家不知道該怎麼解決問題了，只好試試看新方法來解決問題。
(講師突然很快速的把錄音中的麥克風關掉)
於是我們看到，微軟這幾年轉型 agile 搞得非常成功啊…"



 時    間                                                   主   題
09:30 - 10:20
                               微軟研發團隊 DevOps 轉型的實踐與經驗
                            微軟大中華區開發工具高級產品經理  胡德民


 1. 你看這幾年電子商務已經搶奪了傳統產業的生意了。2008 年我剛去北京，冷得要命，一下飛機趕快去那個什麼店買電暖爐。
 現在呢，誰還去實體商店買！都用掏寶，京東在線什麼的。
 最近中國的雙十一購物節剛過，掏寶一天交易多少多少億，銀聯應該樂死了吧？錯，這完全沒有銀聯的事情。掏寶直接跟商店（銀行？）結帳了，完全被掏寶賺走。
大家掏寶剩下來的錢放在「餘額寶」，掏寶就可以直接開銀行了。

 2. 傳統產業，不管是零售業或是銀行，都想要搞 IT 服務，可是這件事情無法外包。
 你傳統產業不能把電子商務用「專案」形式外包出去，你得把把它當作你的主要服務。不能想說不就做個網站吧？有什麼難的？
 如果這不難，你的外包商就直接自己做這個服務啦，還輪得到你零售業做喔？
 所以這年頭，電子商務已經變成很多企業的主要業務了，說到底，每一家公司都是軟體業。

 3. 我們為了 web development 弄了 visual studio code, 那是大神 Erich Gamma 弄的…

10:20 - 11:10
                             中國互聯網大潮下企業的 DevOps 轉型挑戰
                                     微軟大中華區社群技術總監  徐磊

(我只記得他這段講，visual studio team 一個 sprint 花 3 weeks. build 一次要花六到八小時。
他講得不錯，可以認真看一下他在 channel 9 錄影。
下午還有講。)



11:10 - 12:00
                           推動臺灣企業研發實力升級的 DevOps 新思維
                                    微軟大中華區特聘技術顧問 李智樺

我覺得大家剛剛兩場都沒有笑，表情很苦的樣子，所以我特地寫了這個「笑」字。
剛剛這兩場中間為什麼都沒有休息？這樣效率會比較好嗎？還是比較「敏捷」？
其實我有一點小小抱怨：我已經連續四周的週末，因為社群活動而犧牲掉爬山了。我覺得這樣非常不好，這是違反敏捷精神的，雖然說社群是很有熱情…
我剛剛聽了前面兩場，有一些心得回饋，我就寫了這些便利貼，我一個一個講。
我上班一天要寫一百多張便利貼。
（講完便利貼之後）
結果都在回應前面兩位的內容，我自己的投影片白準備了…
徐磊在大陸的實戰經驗豐富，大家如果已經有買了我那本書，下午可以去聽徐磊講。


13:30 - 14:30
微軟 DevOps 開發平台架構的最新進化
台灣微軟技術支援經理  邱英瑞
(沒聽到，好像要 demo App Insight, 某種號稱比 google analytics 更好的東西，可以用來紀錄 desktop client 的按鈕點擊，並且在後台呈現漂亮的報表。)

推動 DevOps 轉型的成功要素
微軟大中華區特聘技術顧問  董大偉

如果各位什麼都記不得，拜託各位就記住三件事情：
「敏捷」、「自動化」、「透明化」。

工具是用來「用」的，不是用來「學」的。


企業測試團隊的
DevOps 組織規劃實務
微軟大中華區開發技術專家  莊俊乾
(講實際操作，他的口音讓我睡著了。)


15:50 - 16:10休息
教戰守策：中國企業大型研發團隊
DevOps 轉型的平台功能規劃
微軟大中華區社群技術總監  徐磊

身為軟體工程師，不要太介意「寫出 bug」這件事情。你寫程式一定會產生 bug.
我們應該介意的是「產生的 bug 數量超出預期」這件事情，如果都還在控制範圍之內，不嚴重，那就是 priority low.
那要怎麼知道這件事情？就要靠資訊透明。靠 crash dump report. 靠 unit test result. 靠 code coverage.
你們看這張圖表，顯示隨著時間增加， check-in 不斷增加，unit test failure 增加，code coverage 減少，這表明大家這段時間在趕工，
品質已經下降了。

早上 Ruddy 老師說我漏講了一個例子：各位你們知道哪種汽車品牌被專業評鑑為「品質最佳」的汽車嗎？這可不是我亂說的。
BMW? Ford? 錯，是 Toyota 豐田.
Toyota 的車子就像是，可以大概在免費保固的里程跟年限剛剛過一點點的時候，就很準確的壞掉。
他的品質是很穩定的、可預期的。
所以我們講到 Scrum 裡面的 "Definition of Done"，就是「跟客戶約定好的品質標準」。
品質永遠不夠好啊！如果品質的標準不先訂好，那麼大家都加班加不完。