第二天在開場致詞時，iThome 電腦報總編輯吳其勳提到，這天會比較 focus 在工具與技能，因為這場研討會可以報名單天的場次，所以他也略提了前一天的議程，包括：直井久和先生的經驗分享中，不僅是導入 CI/CD 會遇到流程面的問題，可能根本在 CI server 就出問題了，應如何解決；趨勢科技提到怎麼做大量資料的轉移。
iThome 新聞主編王宏仁則想強調 DevOps 是 IT 人的新技能、新文化。1998 年，是世紀末最大的流星雨，當時王主編在天文所工作，將流星以數位攝影拍攝後，要分析流星的位置。當時最大的障礙是，raw data 一張照片就是數百 mega bytes，當時的主流硬碟約 40GB，而網路頻寬也不及現在，要如何將美國夏威夷觀測的硬碟資料傳回臺灣？就成為彼時的技術瓶頸。雖然有為了跨國傳輸拉了專線，但傳完大概要一週，當時最快速的傳輸工具是：DHL 航空快遞！有時解決問題，選定的工具技術新舊不是重點，重點是如何挑選能夠解決當下的主要問題。
開場也再次回顧了前一天有提到的 2014 年 DevOps 大調查，幾乎都是 DevOps 從業人員來參與填寫，增添了這份報告的可信度。可以從中發現反而是非資訊科技業的公司、小公司，會大量導入 DevOps 相關技術，尤其是金融業，常常會走在技術的最前端。有興趣看報告的人可以到 puppet labs 看看：
進正題囉！
【DevOps in the Cloud：Google 雲端平臺 Developer Advocate -- Ian Lewis】
- Ian's Twitter: https://twitter.com/IanMLewis
- Ian's Speaker Deck: https://speakerdeck.com/ianlewis
- Ian's Google Plus: https://plus.google.com/+IanLewis-hoge
企業必須變得更敏捷、快速、有效率，所以要找對的工具。他放了一張諷刺漫畫，內容是原始人以人力拉著貨往前進，後頭的人拿輪子出來想要建議拉著貨的人為貨箱裝上輪子，但推貨的人卻回頭說：「不用了，我們太忙了！」正是目前導入時常見的迷思：太忙了，沒時間導入使用對的工具。
這場我覺得沒有特別提到什麼概念，總之就是要選用對的產品、更敏捷的因應問題，主要就是談 Google 的雲端平台如何解決問題。
〖演講後的 Q&A〗
- Q: 在 DevOps 的工具選用上，虛擬化或是 container 比較好？
A: 對 Google Cloud 而言，container 是個比較好的選擇。 - Q: 怎麼把 application 轉移到 container 上？有建議的最佳做法嗎？
A: 坦白說這沒有明確的答案。
（備註：因為搞不懂 container 是什麼，上網找了一下，從這篇《DevOps: 快速的佈署測試與上線環境 (Docker + Puppet + Vagrant)》看起來，container 相對於 VM 的映象檔，似乎是一個比較小的 package？）
【廚師與伺服器 (Dancing with Chef)：趨勢科技資深工程師蔡宗城】
系統管理者一天會面到各種問題：例如 OpenSSL 又被發現新的弱點，要把所有的 patch 上到 server 上；需求來得又快又急，要把 build 上到 server 上；台灣時間到了夜半，美國的 user 卻很活躍，網路服務出問題，就被挖起來加機器；web service 時好時壞，檢查後才發現是手動修改了 config 後，忘記重開機器⋯⋯
這一場的目的就是讓大家舒適愉快的面對工作～
過去我們都是參考手冊去人工作業建機器，但是可能在操作過程中漏了步驟、或是文件本身就不完全，以至於每個人做出來的機器都不一樣。理想的狀況應該是把它寫成 script，該開的資料夾、該做的設定，都由 script 一鍵完成。
在 chef 裡，有 cookbook 的概念，裡頭會定義以下的東西：
- Recipe: resouce 在何時產生
- Template: 過去 config 都是寫死的，現在可以用程式動態去產生 config 內容
- Attribute: 細節的設定
（現場有 live demo 但是我好想建議講師不要冒險啊～雖然大家每次都笑說 live demo 才是真男人但是幾乎每個場子裡 live demo 都會掛啊啊啊，而且後來果不其然的因為網路問題而掛了 XD）
過程中講者也分享他維護的經驗：AWS CloudFormation 不容易 debug，Stackoverflow 反而比 AWS 的官方文件還可靠（因為 AWS 更新頻繁，官方文件很容易就過時了）。
Chef server 一定要灌在 Linux 上，chef client 則是跨平台的，Linus & Windows 皆可。
〖演講後的 Q&A〗
- Q: 為什麼要用 CHEF 不用別的？
A: 當時都有 survey Puppet, Ansible，CHEF 目前放在一百多台 server 上運作，都跑得很好；但是跨平台表現，CHEF 在 Linux 表現比較好，啟動很快就會啟動好，但是 Windows 大概要花三分鐘時間啟動，時間上差三倍，啟好以後兩邊執行後續 script 的速度倒是一樣。
【Yahoo行動App開發在持續整合與持續交付的經驗分享：Yahoo 亞太區產品研發工程部軟體工程師李卿澄】
- Website http://qcl.github.io/
- blog http://blog.qcl.tw/
- slideshare http://www.slideshare.net/qingchenglitw
導入持續交付 (CD, Continuous Delivery) 是希望能夠短時間提交高品質的產品，透過自動化，讓品質更安全穩定。在 Yahoo，程式碼提交 (commit) 之後，一路到上正式環境 (production) 都不會有人為介入的空間。（中間的測試也都是自動化的）
如果在測試過程裡，發現測試無法通過，會停下手邊開發的工作，儘快修復該版本的修正，才繼續寫新功能。儘量立即處理錯誤。
在 Yahoo 有個 dashboard，可以讓大家即時看到是否有錯誤發生，不過通常大家雖然會把瀏覽器停在 dashboard 畫面上，但專心開發時，並不會注意 mail 或 dashboard。所以就像前一天天應百怡的分享，會在各 team 擺一個實體的燈具，只要有問題就會立即亮出特殊色的燈號，所有路過的人都會看到。
- Continuous Delivery pipeline
- Commit Stage: 確保程式可以 build
- Acceptance Test Stage: 確認新 feature 不會讓舊 feature 壞掉之類的
- Non-functional Testing
在提交程式碼之前 (Pre Commit)，有些事要先搞定：
- 在本機要先確認過可以 compile 通過
- 在本機做好 unit test 等種種測試
Pull commit 之後，要做 code review，人工檢驗程式碼是否合乎 quality，也不要沒有做過 code review 就直接 merge 程式碼到 code base 裡。
除了人工的 code review，也會透過 CI 等機制做簡單的測試，確保程式可以正常 build、也可以通過基本的自動化測試，以避免少量的錯漏字（例如 JSON 裡中間的元素少打一個逗點，或特殊的註解文字造成後續都被註解掉）。
確認程式的健康度：
- 測試的涵蓋率
- 檢查有無重複的 code
- 檢查錯誤的數量
也會做 Smoke Test，確認 APP 打開有沒有 crash，透過 UI automation 來測試是否程式反應與表現如預期。
Non-functional Testing
- 做一些 UI 之外的事，例如穩定性或效能測試
- 效能測試由 Monkey Test 來做測試，請花果山的猴子們隨便亂玩一下：寫一支 script 隨機滑動
實務上要注意一些例外的情況可能會讓測試沒有執行到，以 iOS 為例，打開飛航模式後，沒有網路，所有與網路有關的功能都不能 work；從上面滑下來的通知中心，也會讓操作跳出要測試的 APP。到最後，仍然會有需要人工測試介入的部分，譬如說金流之類的內容需要人工來輸入驗證。
〖演講後的 Q&A〗
- Q: 程式 commit 到 version control 之後，可以自動觸發測試嗎？
A: 會把新的 unit test 放進Jenkins 裡
（備註：因為我個人對 Yahoo 的 APP 相關議題有興趣，所以找到賽拉維之前講的這個：《當網頁遇上原生 APP》，一併收起來。 :)）
【Ansible實戰：Top-down觀點 (Practical Ansible: A Top-down Introduction)：Gogolook 架構師葉秉哲】
這場是唯一一場在一開始就告訴大家簡報檔放在網路上的！已噴淚～（而且我覺得簡報放在 slideshare 或是 speakerdeck，比放在 dropbox, google doc 或是網站空間好得多了，因為這樣要整理成文章的話比較好嵌入啊⋯⋯我自己其實不太喜歡一直要另開視窗去讀東西，不方便捲回來比對前後文章）
為了讓大家可以跟上來、也可以回家自己玩，葉大有做 ansible 的 lab：https://github.com/william-Yeh/practical-ansible
ansible 是個功能多、輕巧、好擴充的組態管理工具，用了三年覺得很好用，在現場 demo 給大家看。lab 的內容就是昨天的架構來實做：先收 http / https request，Load Balance 是 HA proxy，然後後端會有 node.js 處理，再丟到 redis 做 database 處理。除了 Application server 用 Ubuntu 14.04，前面的 load balance、後端的 database 都用 CetOS 7.1。
DEMO 流程計畫是這樣來（但後來時間不夠所以有些就帶過了）：
- 先用牛刀殺雞，讓大家感受 ansible 的重要觀念
- 規劃
- 部署
- 組態的測試（確保部署上去沒問題）
某個 service 掛掉的時候，通常我們會 ssh 進去重啟服務，最笨的做法就是一台一台連，進階一點會用 sshx 一口氣對多台操作，透過 ansible 可以更輕鬆完成這樣的操控。只要主機有開 SSH、有 Python 2.5 以上版本，就可以透過 ansible 操控。
透過 ansible 也可以管理雲端主機，先將主機分群（標上 tag or label），到時候就很容易管理。ansible 新版可以 pull，寫在 cron job 就可以讓 ansible 定時去 pulling。
Ansible Galaxy 可以想成是 Ansible 裡的 github，裡面充滿了別人寫好的指令，需要的時候可以直接在 playbook 裡設定，不用自己慢慢試慢慢學。
Continuous Delivery 這本書裡的第十章，有提到 Rolling Back Deployments and Zero-Downtime Releases，上版遇到有問題時可以順暢的退版，可以運用 Ansible 來實現這樣的部署。（備註："Continuous Delivery" 有中文版欸，後來得寬科技的陳正瑋有介紹這本，提到中文版是簡體翻繁體的，如果覺得翻不好還是建議買原文 kindle 版，不到 10 元美金。）
Ansible 還可以支援其他更新情境：
- blue-green deployment: 假設十台機器裡，有特定幾台想要放新版程式、其他台都維持在舊版
- rolling upgrade: 滾動式的更新，一次做一台、做成功了再做下一台。在 playbook 裡加上 serial: 1，就可以一次對一台主機執行腳本，有任何一台有問題就會停止（心臟夠大顆、機器又很多的時候，也可以一次十台十台的做）
Test kitchen 可以用來模擬測試組態。
（備註：講者另外在其他活動有講過《安裝 Nginx 的 101 種方法／Ansible 簡介》，我之後想來研究一下 Nginx⋯⋯）
【從DevOps觀念看Web前端開發測試先行：資深架構工程師戚務漢】
- Caesar’s bog: http://blog.caesarchi.com/
- Caesar’s slideshare: http://www.slideshare.net/clonncd
沒有做測試的佈署，就像是在裸奔，沒有任何的防備與預先規劃，上線後可能會遇到種種問題。測試有做比沒做好（先不考慮涵蓋率），上線之前要有「測試先行」的概念。
有時大家的 BDD 不是行為驅動開發 (behavior driven development)，而是 Boss Driven Development（老闆驅動開發），我們希望所有的流程架構都自動化，而不是老闆或主管來驅動測試。
將前端拆解開來，用了再多的 framework / library，其實元素也就是 HTML + CSS + JavaScript，再依架構應該可以把這些元素從這三個構面看待：
- convention: 所有人的 code 應該都長得一樣才對 e.g. 透過 JSCS 來驗證 JavaScript，HTML 會使用 jade (採用縮排與斷行產製 HTML，會符合標準格式，不會再有忘記結尾的 tag、或屬性多了或少了雙引號) ；SaSS 來處理 CSS。再在 git 做版控時加入 ghooks & precommit-hook 等 validate plugin，讓 local 端只能上傳格式正確、完整正確的 code
- controller: 指 user interface，將 web components 拆解成 UI event & logic function 兩個構面，logic function 可以使用 mocha 或 chai 這些 testing framework，讓程式獲得驗證。Angular 用的測試前端是 Karma、後端是 Jasmine。
- compresser: 通常會用 gulp / grunt 來處理，把前面的驗證都再測試一次。
UI event 的測試，Caesar 推薦用 Phantom JS 這個架構來測，它不必開 browser 就能測試。
Protractor 可以拿來驗證，UI test 則用 Selenium HQ。
雖然需求一直改，但是前端常會被改動的是物件的位置與外觀，通常 data / behavior 不會變，例如登入模組，可能會被改變按紐與輸入框的顏色，但帳號值、帳號驗證等通常不變，因此可以把測試抽出來處理。
每個單元的測試應該儘可能小（先求有再求好），不必設想所有的可能性，一樣一樣來。
作為一個工程師最好是
- 要做測試
- 分享好的概念
- 建立 jenkins server
- 準時交差
- 洗老闆的腦
Google 了一下發現講者在前陣子有在別的研討會談團隊經營。
【在DevOps叢林裡的小隊游擊戰術 (The Survival Guide for Small Team in DevOps Jungle)：得寬科技DevOps Engineer陳正瑋】
- 陳正瑋的個人網站: http://chengweichen.com/
- 陳正璋的 slideshare: http://www.slideshare.net/warfan
剛入行時什麼都要處理，經驗過各式各樣的問題處理，連電鍋不會熱都要去處理。曾經在工作上遇過董事長還會要資訊人員 survey 長輩可以用的手機⋯⋯標準的有電的地方就是資訊人的事。 XD
得寬科技 (The Qwan technology) 是以網站建置為主業，為部落客建置過購物平台、社群網站分享內容的功能、珠寶的工廠後台等。得寬科技只有四五個人，不是大公司，但卻有一位專職的 DevOps Engineer，是因為導入 DevOps 可以讓這樣的小公司更有效率的運作。
進入叢林應該要有個生存手冊，懂得如何野外求生，導入 DevOps 也應該要有一些基本認知：
- Lean: Lean Enterprise
- Agile
- Continuous Integration (CI)
- Continuous Delivery (CD)
講者推薦閱讀 The IT Revolution DevOps Guide。他認為 DevOps 對公司的好處是：即使 DevOps Engineer 人在這裡分享，但因為公司裡每個人的技能略有重複，即使 DevOps Engineer 不在，仍能無後顧之憂。
選擇 DevOps 工具時會從幾個角度選擇：
- 符合需求（不會因為 docker 很潮就選 docker XD）
- 學習成本（要花多久時間才能學會？要多久才能教會其他同事？）
- 設計邏輯
- 價格
- 售後服務
- 商業支援（工具是否能長治久安的維護下去）
- 教學資源
- 有無熱絡的社群
- 生態系
他們參考 "Continous Delivery" 一書的目錄來調整了得寬科技的流程。
- version control 用 git & bitbucket
- 上線用到 Packer
- 組態管理也用到 Ansible
【不只自動化而且更敏捷的Android開發工具Gradle（A Productive Android Development with Gradle）：HTC 技術副理邱炫儒】
講者出版過《CI (Continuous integration) 關鍵技術：使用 Jenkins》，這場要介紹 Gradle。
開始講之前先看了一段 NetScape 要 release source code 作為 Mozilla 開源專案的記錄片。
從 Mozilla 的例子鑑古知今，在軟體交付中可能會遇到一些問題，使用 Gradle 這樣的 CI 工具可以解決一些問題。
- convention 1: 消除溝通的嫌隙
套用最近流行的一句話惹毛 XXX 的 pattern，一句話惹毛 DevOps:「我電腦沒這個問題呀！」build 失敗 / 被發 issue，但是 developer 卻表示在開發階段沒有遇到這樣的問題。Gradle 希望能夠作為設定的中控管理，讓 IDE、測試環境、正式環境等都能儘可能接近，避免在不同主機上會出現不同的狀況。 - convention 2: product flavor and multiple APK
Product Flavor 是 Gradle 上客製化 APK 的功能，讓開發階段的程式能夠接近實際的狀態，像 versionCode，如果由人工維護就很混亂，可以透過設定讓 Gradle 自動產製（計算 versionCode 的動作也可以放在 Jenkins 裡做） - convention 3: 有條不紊的程式碼管理
Gradle 的目的是要建立可重複且可靠的流程，所以在 souce control 階段，產出的暫存檔與執行檔就不應該放到版控裡，應該編輯忽略清單 (ignore) 來略過這些檔案，讓程式碼佈署到其他主機也能直接編譯執行。
Gradle 管理套件的相依性，預設會假設套件都是向前相容的，當遇到相同套件時會選最新版本的為主，但這個 policy 也可以關掉，只要一有版本不相同的同名套件就讓 build failed。可以設定 CI，若有違背架構原則就讓建置失敗，例如，規範不可以有版本相依套件等。
【Chef與Devops技能：Chef 全球傳教士 Michael Ducy】
這場的重點就是 live demo，所以先簡單介紹 Chef 可以做哪些調整，接下來就直接進 live demo 了。
- Food Critic，可以用來測試 cookbook 的設定是否正確
- RuboCop
- ChefSpec，模擬 Chef
- Test Kitchen，模擬 chef 用
小結這兩日的我個人心得：
- 這一場辦在平常日，我覺得對象應該是上班族，可是官方網站把議程內容放在特殊 port，我看了一下，不只是我啊，別的公司果然也被擋了；還有便當有點讓我想回去辦公室好好上班XD
- 活動有收費，所以當 live demo 卡住又沒有備案而任由時間空轉時，我忍不住會好奇現場有多少人瞬間打開問卷填不滿意？XD
- 私以為這個活動的設計比較適合 MIS / OP。不知道是不是我懂的太少，覺得這些東西在分工清楚的架構下，developer 好像都不太有機會碰？
〖相關連結〗
- Teddy 的心得文：《參加DevOps 2015 Day 2》
- 趁亂推一下當天在現場休息時間發呆時刷 twitter 時看到的好文：vinta 的《你都去哪裡看技術文章？》
留言列表
Dear Baby (6)