2015年12月7日 星期一

微軟 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",就是「跟客戶約定好的品質標準」。
品質永遠不夠好啊!如果品質的標準不先訂好,那麼大家都加班加不完。