Day 2

持續集成(Continuous Integration：CI)

• 自動化代碼合併以及測試過程
• 在項目早期發現Bug,降低Bug修改成本
  • 各環節成本不同 => 開發,測試,交付,生產
• 自動執行測試
• 創建可於部署的交付件

持續集成環境技術架構

• Agent Pool
  • 服務器 TFS || 帳號VSTS 級別
• 代理隊列 Agent Queue
  • 團隊項目級別
• 代理Agent
  • 部署在用於執行持續集成的服務器或Client
  • 開源且免費的OS,Windows,Linux,Unix,macOS
  • 與J牌相同,可支持開源的所有環境,不同的是得依賴獨立一台TFS或一個VSTS帳號

    VSTS 默認的Agent Pools

• Default
• Hostedwindows server 2012r2,vs2010-15
• Hosted Visual Studio 2017windows server 2016,vs2017
• Hosted LinuxUbuntu
• Hosted macOS託管的macOS,preview中,針對移動開發有用
  VSTS-Agent
  DockerHub

創建構建定義(build-definition,New Build)

• 可以選擇模板
• 內置任務
• 編寫腳本
• 自行開發任務
• 保存自已的模板

構建任務

• 開箱就用
• 封裝好的腳本
• 接受參數輸入輸出

觸發器

• CI
• Scheduled

建構變數(PS時使用)

變數是為了控制Build Server 用於PowerShell

• 內置變數
• 用戶定義變量
• 密碼變量
  構建的過程不想給開發人員看到,就換成密文變量,建置時會變*********
有需要請自己查內建的變數表

Artifact

四級測試規則

• L4:生產環境中執行的測試
• L3:完整一桶內測試數據執行的測試
• L2:依賴當前部署單元運行的測試(UAT)
• L1:不依賴外部,代碼文件測試存在就可以
• 分為測試類型,測試環境,測試方式
• 後續上docs查

Lab 實作CI,昨日的MyHealthClinic

• 直接使用Dotnet core會Build failed
  新增bower,npm,gulp
  
  文件位置

持續部署(Continuous Delivery)

• 允許代碼備構建,將CI後的Artifact運行至測試或生產環境
• Artifact交付內容包含InfraAsCode和AppCode
• 部署到環境後可以執行L2-L4的自動與手動測試
• 生產or預生產環境建置

服務終結點

• Service Endpoint
• 部署過程中連接多種外部服務[雲端,容器,容器倉庫等等]
• 連接外部服務要受到控制,存取有權限認證
• EX:SSH,K8S,GitHub,Gitlab…等等儲存庫

Release定義

• 發布流水線
• 使用artifact作為起點
• 將多個環境按造邏輯組成流水線
• EX:Dev => QA1+QA2 => Prod ring1 => Prod ring2
  註:QA進行壓力或UAT或功能測試環境,流水線就是為了組裝不同環境以及人員流程的運轉
駐2:環境可測試性必須獨立,包含資料庫

Release審批(Post-Deployment Confitions)

• 允許人工介入流水線審批過程
  每個發布環境都可以設置審批,配合多團隊 EX:QA,Release
• 新增郵件通知
• 環境:部署前與部屬後
  

處理版本跟蹤環境配置

• 於設置變數於docker-compose-template.yml
• 設置過程變數
• 目的是為了處理不同環境的環境差異

持續交付

分支策略

• 保護master,控制進入master的程式碼質量
• 最少審閱人數量
• 評審意見狀態
• 自動添加審閱人
• 外部服務=>Status Policy
  • PR Status API允許外部服務[EX:第三方安全掃描,另外一個系統的流程等等]
• Work item連接
• Voting
• PR

PR工作流

• 人工代碼評審
• CI自動化檢查
• CD自動化部屬
  

CICD工作流

• 編碼工作流
• CICD工作流
• 監管log,分析
  

包含的工具鍊全景圖

測試管理

VSTS/TFS支持的測試類型和測試模型

• 持續測試
  • 單元測試
  • 功能測試
• 手工測試
  • 集成測試
  • UAT測試
• 探索測試
  • 集成測試
  • UAT測試
• 性能測試

單元測試VS集成測試

• 單元測試:僅保證程式測試
• 集成測試:一樣得跑單元測試,但接近用戶(EX:UI測試)

為何要做單元測試

• 減少Bug的機率
• 雖然要寫更多的編碼,但不需要再花時間測試整個專案,針對性的完成編碼
• 隔離運行測試,無需依賴外部(資料庫,網路,第三方系統等)
• 優化/重構你的代碼,完善代碼結構,重點是幫助開發人員思考可能會發生的情境,藉由測試承擔需求內容情境
• 跟91的TDD有異曲同工之妙

單元測試命名規範

利用命名 不要再多寫文檔

1

AccountTransfer_ValidateAccountBalance_InputBalanceIsMoreThanTransferAmount_ShouldSuccess AccountTransfer_ValidateAccountBalance_InputBalanceIsLowerThanTransferAmount_ShouldFail

Demo:針對WorkItem進行項目測試