【台灣微軟講座】DevOps 在雲端 – Visual Studio Team Services 實戰秘笈

(3/30)DevOps 在雲端 – Visual Studio Team Services 實戰秘笈。

開場 Power of Developer - 劉念臻

 

軟體開發依舊是企業所需的第一名

.net 開發人員:26.1%

apple 開發人員:19.5%

java 開發人員:13.2%

Now every company is a software company(David Kirkpatrick)

無論是哪個行業的公司,現在都是軟體公司(以 FedEx 為例)

現今的公司必須運用軟體與科技,保持競爭力與快速回應客戶的需求

 

IoT Service are the real driver of value in IoT

互聯網的應用,硬體的完善後,真正能發會最大效益的是軟體服務

 

Now the developer is king(Eric Knorr)

開發人員所面對的資訊技術與環境(Cloud, Data, IoT, Lob, Social, Native, Managed, Web, Devices)

微軟所提供的開發工具與平台

  • 更創新:每三個月推出更新功能
  • 共開放:支持更多跨裝置開發
  • 更敏捷:端到端支持敏捷 DevOps

 

DevOps在雲端,如何在30分鐘實現高透明度專案管理 - 董大偉

 

VSTS + DevOps Liftcycle

  • DevOps的成功要素
  • 專案透明度包含?
  • 如何進行一個(高透明)專案
  • 如何實現自動化

 

DevOps的成功要素:透明度  自動化

 

透明度

  • 需求 / 反饋:需求明確,客戶給與反饋
  • 專案管理:專案進度,交付進度,目前工作由誰負責,每次修改是否有紀錄
  • 程式碼 / 技術:code 交接
  • 維運 / 系統狀況:系統還活嗎? 功能正常嗎?

用戶需求、專案工作狀況

系統狀況、進度 / 達成率

Bug & Feedback、專案風險

 

用戶需求,專案工作狀況

  • 不同的角度,看的結果也不同,用溝通取代文件
  • 專案最重要的是驗收,其他都是假的
  • 開發團隊與維運團隊一體
  • 精準的預測是可能的嗎?不可能,因為你沒有無限的資源(時間、人力),與穩定的需求
  • 我們歡迎需求變更,但不是鼓勵需求變更

 

系統狀況,進度 / 達成率

計畫驅動:甘特圖(water fall)

  • 成功的專案?與計畫越像越好
  • 時程與預估,會不會原本計畫就有錯? 會不會一開始的假設已經不成立? 會不會一開始的限制已經不存在?

目標導向:Scrum、Kanban

  • 並不是不重視規劃,而是執行計畫的同時,隨時回頭檢視你的目標,遵循計畫並非墨守成規,一成不變
  • 強調自適應性(Adaptive)

Do I really look like a guy with a plan?(黑暗騎士小丑)

他是有計畫的,但他不會拘泥於計畫,而是隨時去應變

專注目標,縮短回饋循環

如何專注目標?你得知道客戶要的是什麼(但很多時候,客戶根本不知道要做什麼?)

潛在可交付產品增量(increment),縮短回饋循環

迭代

在充滿變化的時代,預估不能幫你更容易實現目標,達成目標倚靠的是對現況與變化的掌握

敏捷開發透過迭代(iteration),來掌握與控制變化

必須隨時面對市場的改變,去修正計畫

利用迭代控制需求變更,管理需求的生命週期

迭代中掌握專案的現況(整體進度,與剩餘工作量)

 

Bug & Feedback,專案風險

有效率有組織的管理,Bug 與 Feedback

讓它們是可被記錄,並且自然融入你的開發流程

 

如何進行一個(高透明)專案

Scrum + VSTS

從原始需求,到工作單,串連到開發人員,程式碼異動紀錄,工作項狀態

開發流程,實現CD

 

Demo 建立一個健康管理系統

1. 建立 VSTS 專案

2. VS 建立新專案,並連接至 VSTS 專案(對應工作區域)

3. 新增需求工作項(PB)排優先序,為每一項 PB 產生 Task,給予時數

4. 建立一個 All Task 清單(query),可以在 VS 顯示這些工作項

5. 建立一個 Build Definitions,勾選 

8. commit 觸發,Build Definitions,自動建置,執行測試,trigger 信件通知結果

 

User Story

As <a type of user>

I want <some goal>,

so that <some reason>

 

Acceptance Criteria

細節。條列式的(驗收需要條件與標準)

 

自動化

好處, 實際可以兜得起來

減少人為疏失,人的特性(不精準,但富有創造力)

找出,避免瓶頸,減少浪費

 

數位儀表板

VSTS 首頁,專案檢視。

 

試用者反饋

 

結論

  • 建立unit 
  • 自動測試
  • 自動建置
  • 全面導入CI

 

快速因應市場競爭 - 雲端應用開發與測試 - 張韡、黃承皓

1. 規劃:敏捷專案管理

2. 開發測試:版本控管、測試管理、測試自動化

3.發行維運:CI/CD,持續上版

4.學習反饋:即時反饋 / 即時校正

 

協助開發人員,快速建立『開發/測試』機制

  • 開源:滿足對外對內的需求(提供更多服務 / 產品)
  • 節流:減少重工,人員的浪費(共用、自動化、好維護)
  • 提升效率:time to market 即時反應、解決問題

 

Dev & Test in the cloud(Azure Dev / Test Lab)

挑戰:自建軟/硬體,時間的成本上升

建立 Dev Test Lab

管控支出(Preview)

 

Azue Load Testing

測試環境的資源非常有限

1. 錄製腳本

2. 設定測試情境

3. 雲端負壓測試

 

Unit Testing, Intellitest(自動產生 Unit Testing)

VSTS 探勘測試新工具

Exploratory Testing 

 

省時省力不停機 - 發行管理與持續部署 - 陳小風

什麼是持續整合?

軟體品質,自動化部署

Release Management

產品發行週期

DevOps 實踐之道

 

持續整合

曾經遇到這些狀況

  • 程式碼無法建置
  • 裝機器要花好幾天
  • 修一個 小小的bug 其他程式就壞了
  • 一定要 OOO 在才能建置最新版本
  • 上線時總是少了什麼

沒有萬靈丹

  • 人都會犯錯
  • 程式都會有 Bug
  • 只能滿足想到的情境
  • 使用流程降低問題
  • 盡可能降低意外發生的狀況

解決方法

  • 單元測試、code review、程式碼掃描、整合測試
  • 以上的動作,都要自動化

什麼是 CI(Continuous Intergration)

  • 把 Routing 的工作交給自動化
  • 持續、反覆、不斷進行
  • 維持軟體品質
  • 降低交接 / 訓練門檻
  • 產生報表
  • 像呼吸一樣自然

導入成本很高?

  • 在第一次需要花費時間設定、修復錯誤
  • 省下之後一百次、五年的時間
  • 對一般開發人員沒有任何影響
  • 自動部署到對應的環境
  • 自動進行測試、軟體品質檢查

VSTS 

  • 客製化的環境
  • 多平台、多語言
  • 支援測試
  • 持續整合
  • 容易擴充

 

定義自己的建置流程

持續整合

指定你的 Bridge 觸發 Build

需求、測試、開發、建置

 

Agent Pool

自建 Agent 在地端,可以分配到地端做建置(不僅限於 C#)

支援第三方整合

小結

  • 自動化工作
  • 有效產出
  • 養成文化

 

軟體品質與自動化部屬

讓程式碼可靠

  • 簽入程式觸發
  • 追蹤品質
  • 產生報告
  • 提前發現問題

維持水準

改善依據

  • 將抽象轉換成數據
  • 測試涵蓋率
  • 找出潛在問題

DashBoard

支援軟體品質工具:SonarQube

持續部署

  • 將程式發行至對應環境
  • 發行後自動通知
  • 工程師專注在開發
  • 不會有人為疏失

彈性的部屬選擇,與Azure 完美整合

小結

  • 節省時間
  • 專注在開發上

 

Release Management

發行流程

  • Dev(Developer) 
  • Test(QA) 
  • Stage(穩定測試機) 
  • Producation(正式機)

簽核機制

  • 完成階段
  • 通知相關人員
  • 確認工作完成
  • 測試驗收
  • 往下推進

為什麼需要簽核?

  • 降低錯誤發生機率
  • double check
  • 通知相關人員
  • 商業邏輯檢查
  • 安全性

小結

  • 客製化流程
  • 簽核機制
  • SOP

 

產品發行週期

功能分支開發

  • Master - 獨立部署環境
  • Feature - 獨立部署環境

Canary Release 跨國開發(不會馬上發行至全部使用者,先針對部分)

  • Asia - stage 0 production
  • Asia - stage 1 production
  • US - stage 2 production
  • Europe - stage 3 production

小結

  • 並行開發:master brige, feature brige
  • 循序部署
  • 有效管理

 

Devops 實踐之道

1. 計畫 2. 開發測試 3. 部署 4. 監控 + 學習

CI、CD、RM

 

DevOps 文化

讓使用者用很少的 loading 做到往後的開發與維護

  • 從簡單開始
  • 持續改善 / 持續交付
  • 養成良好的開發習慣
  • 提前發現問題

 

DevOps 幫助

  • 縮短循環時間
  • 最佳化資源
  • 改善品質與可靠度

 

學習與反饋 - 全方位掌握應用程式健康度 - 陳晴

大綱

  • Application Insights 初探
  • 效能監控分析
  • HockeyApp 初探
  • 整合 VSTS 與 Slack
  • 結論

打造一個成功的 App?好難

如果不能量化某些事情,你就不能理解它,如果不能理解它,你就不能控制它,如果你不控制它,你就不能改進它

 

什麼是 Application Insights?

  • 遙測收集不同階層的資料
  • 遙測資料收集、處理及儲存在雲端 Application Insights 服務
  • 取得應用程式 360度全方位健九包含可用性、效能及使用行為

 

什麼是 HockeyApp ?

  • Beta Distribution:上傳 builds 版本,通知使用者,直接在行動裝置上安裝
  • Crash Reporting:整合 cash report 收集 stack traces
  • User Fdeedback:從 email 或 web 表格蒐集分析使用者操作行為與回饋

 

遙測資料的來源

  • Outside-in 監測
  • 觀察使用者行為
  • 開發人員追蹤事件
  • 觀察應用程式行為

 

整合至 Power BI

 

原生支援以及 Open Source SDKs