[AZ-400] Design and implement a release strategy

มาถึง Part Continuous Deployment แล้วครับ แต่จริงแล้วหลาย Feature ถ้าลองใน Lab ของบทก่อนหน้า เราได้เล่นเรียบร้อยแล้วครับ

Introduction to continuous delivery

• ก่อนจะมี Continuous delivery (CD) ภาพจะเป็น ดังนี้ - Silo-based Development

• Continuous delivery (CD) is a set of processes, tools, and techniques for rapid, reliable, and continuous software development and delivery.
• Eight principles of continuous delivery
  • The process for releasing/deploying software must be repeatable and reliable.
  • Automate everything!
  • If something is difficult or painful, do it more often. - อะไรที่มันซับซ้อน พยายามทำให้บ่อยขึ้น เพื่อที่จะหา Pattern และปรับปรุงได้ โดยอาจจะเอา Tools มาช่วย / ทำ Script Shell ให้ทำแทน หรือ ปรับที่คน
  • Keep everything in source control.
  • Done means "released." - ปรับ Mindset มากกว่าจะแบบว่า ลองที่เครื่องตัวเอง Work ที่อื่นๆพัง ไม่ใช่นะ ถ้า Code Merge มันพร้อมส่งลูกค้า ดังนั้นต้องมาทำอะไรเพื่อบอกว่ามัน Work เช่น Unit Test / Intergration Test เป็นต้น
  • Build quality in! - ตอนที่ Automate Task ทำงาน มันจะวัด Metric ด้วย อาทิ เช่น
    • test - unit test coverage
    • code - code styling, rules violations, complexity
  • Everybody has responsibility for the release process.
  • Improve continuously. - มีตัว Feedback Loop - จาก Metric ที่เก็บตอนทำ CI/CD นี่แหละ

• Feature Release vs Technical Releases
  • Release (Feature Release) - package / container containing a versioned set of artifacts ที่เกิดจาก Pipeline เวลาพัฒนาควรออกแบบให้มี Feature Toggles - Feature Flag เปิดปิดการทำงานได้ เวลาที่มีเคสไฟไหม้จริงๆ เราจะได้ปิด Feature และแก้ไข Code hotfixed ได้
    Note: An artifact is a deployable component of your application โดยมีลักษณะ immutability (แก้ได้ยาก) และกำหนด Version โดยดู Guideline Semantic Versioning
  • Deployment (technical releases) - action of running the tasks for one stage, which results in a tested and deployed application
  • ใน Pipeline ควรแยก Stage ของ Feature Release / Technical Releases ให้ขาดออกจากกัน

• Knowledge check: Introduction to continuous delivery

Create a release pipeline

• Describe Azure DevOps release pipeline capabilities - Azure DevOps release pipeline แต่ละ Feature ทำอะไรได้ และใช้กับแบบ YAML / Classic Build และ Classic Release ได้ หรือไม่ได้

• Explore release pipelines - ภาพรวมเหมือน Build Pipeline Concept Pipeline / Job / Task เหมือนกัน
  • Artifacts มาได้หลายแหล่ง โดยมี Trigger ให้ทำ Continuous Deployment Trigger เมื่อ Package เข้ามา หรือทำ Schedule Trigger กำหนดเวลาไว้ และแบบสุดท้าย Manual Trigger
  • Stages - Release Strategy โดยมีทั้งส่วน Pre-Condition / Post-Condition ซึ่งมีงานเด่นๆ ที่ทำได้ เช่น
    • Flow Approval จาก Human ให้ทำงานต่อ เช่น Test Dev ผ่าน ส่งต่อให้ QA
    • หรือ Defined Gate - กำหนดเงื่อนไขต่างๆ ตรวจ Compliance หรือ สั่งให้ Azure Function มันทำงานที่เราต้องการก่อน เป็นต้น
• Explore Artifacts Sources
  • มาได้จากหลายที่
    • Build Artifacts - Build Pipeline / Azure Artifacts / Jenkins Artifacts 
    • Version Control Artifact - Code อย่าง GitHub, Azure Repo / Container Repository - ACR, Docker Hub เป็นต้น
    • มันมีหลายอันเลยนะ Release artifacts and artifact sources - Azure Pipelines
  • ถ้า Source เป็น network share containing หรือ มี Link เข้าถึงตรงจากภายนอกต้องระวังเรื่อง Security ด้วย
  • การจะเลือกว่าจะใช้ Artifacts Sources แหล่งไหนให้ดู
    • Traceability - มาจากไหน Commit อะไร ?
    • Auditability - ใครเคยแก้อะไร แล้วสั่ง deploy ?
  • Exercise - Select an artifact source
• Examine considerations for deployment to stages
  • release strategy consideration
    • target environment
    • System นั้น one team (ทำ release cadence frequently). / multiple teams (คุยกันให้เรียบร้อยดีกว่านะ)
    • Who are the users?
    • How long does it take to deploy?
    • Is there downtime?
  • stages - Strategy ของการ Deploy เช่น
    • มองในมุมของ DEV > TEST > PRODUCTION
    • หรือ Region ในการทยอย Deploy App ของเราก็ได้
  • Exercise - Set up stages
• Explore build and release tasks - มันมีแบบสำเร็จรูปให้เลือก แต่ถ้าไม่มีก็ทำ custom build and release tasks
• Explore release jobs
  • release job is executed by a build/release agent และตัว Agents ทำได้ทีละ Job นะ
  • ถ้า System เรามี 3 ส่วน backend .NET/ front end Angular/ iOS App เคสนี้ใช้ 3
  • three different types of jobs
    • Multi-configuration
    • Multi-agent - Run the same set of tasks on multiple agents using the specified number of agents.
    • None - Tasks will run on a single agent.
• Lab11: Configure Pipelines as Code with YAML
• Knowledge check: Create a release pipeline

Explore release recommendations

• Exercise - Select your delivery and deployment cadence - ตัวอย่างของ Trigger ใน Pipeline
• Explore release approvals
  • release approvals - อธิบายเสริมจากบทก่อน โดยก่อนที่จะทำต้องหาคำตอบก่อนว่า
    • จะใช้ไปทำอะไร ?
    • ใครต้องมา Approve
    • และเมื่อไหร่ควรใช้ Flow นี้
  • ตัวอย่าง Set up manual approvals
  • NOTE ถ้าต้องการให้มัน Auto และไม่ขัดกับการทำงานเดิม อาจจะต้องลองดู Feature อื่นๆ อย่าง Auto Approval + release gate จะได้ไม่ต้องรอคนมา Approve
• Explore release gates
  • ทำไมถึงต้องมี Auto Approval + release gates
    • ลดการ Meeting
    • ต้องการตรวจสอบว่า Change และ Incident ที่เกิดขึ้น กับ Code ไม่มีปัญหาค้าง
    • Notify users such as legal approval departments, auditors, or IT managers about a deployment
    • Security scan 
    • User experience ไม่แย่ลงจาก baseline เดิม วัดจาก product telemetry
    • Infra ที่ใช้งานปัจจุบันไม่มีปัญหาด้าน Compliance
  • release gates ที่ใช้ด้าน Quality อาทิ เช่น
    • ไม่มี blocker Issue เกิดขึ้นเพิ่ม
    • Code ที่เพิ่มเข้ามา Code Coverage 80% (เป็นตัวเลขที่ทำได้ยากเหมือนกันนะ 55) หรือไม่สร้าง technical debt เพิ่ม หรือไม่ได้มี Performance Issue ค้างอยู่
    • ตรวจสอบ dependency แล้วไม่เจอปัญหาด้าน License / vulnerabilities (ช่องโหว่)
    • Compliance checks - Are there work items linked to the release?
    • Compliance checks - Is the release started by someone else as the one who commits the code?
  • Ref: Control deployments by using approvals - Azure Pipelines
• Note: Stage - มี logical boundary check (pre/post condition) เพื่อ validate the pipeline
• Lab9: Control deployments using release gates (นับแปลกๆ Module ก่อนหน้าสุดที่ 8 กระโดดมา 11 แล้วกลับมา 9)
• Knowledge check: Explore release recommendations

Provision and test environments

• Provision and configure target environments
  • Target Environments (resources) เป็นไปเตรียม Script ให้ Pipeline มาช่วย Provision Resource ต่างๆ อย่าง Cloud Azure มี Arm Template / CLI โดย Target Environments แบ่งได้ ดังนี้
    • On-premises servers - PowerShell Desired State Configuration (DSC), / Puppet / Chef
    • Clusters
    • Infrastructure as a Service (IaaS) - Azure VM
    • Platform as a Service (PaaS) - AKS / Azure SQL หรือจะเป็น Functions as a Service (FaaS) - Azure Function
  • Service connections - ช่องทางให้ pipeline เข้าถึง resources ผ่าน Service Principal
  • Exercise - Set up service connections
• Configure automated integration and functional test automation - Training | Microsoft Learn >> เขียนเพิ่ม
• Understand Shift-left - Pushing Quality Upstream (พยายามทำให้เรียบร้อยจาก Step ก่อนหน้า)
  • L0 - In-Memory Unit Test
  • L1 - ต่อกับ Text File หรือ SQL
  • L2 - functional tests บาง Service อาจจทำ Stub มาช่วย Mock
  • L3 - integration tests that run against production

• Set up and run availability tests - Training | Microsoft Learn >> เขียนเพิ่ม
• Explore Azure Load Testing - Training | Microsoft Learn >> เขียนเพิ่ม
• Lab12: Set up and run functional tests - Training
• Knowledge check: Provision and test environments

Manage and modularize tasks and templates

• Task Groups
  • encapsulate a sequence of tasks, already defined in a build or a release pipeline, into a single reusable task //อารมณ์เหมือน Function กลาง เอาไปใช้กับ Build / Release Pipeline ก็ได้
  • Exercise - create and manage task groups
  • จากรูปด้านล่างจะรวม Task Backup WebSite กับ Run Script มาเป็น Task Group เดียวกัน

• Variables in release pipelines
  • Predefined variables - ค่าที่มาจาก agent / context เช่น Path ของ Agent / Build Number /
  • Release pipeline variables - ทุก Task ใน Pipeline เห็นค่าเดียวกัน
  • Stage variables - stage-level variable ทุก Task ใน Stage เห็น
  • Variable groups - แชร์ในหลาย builds / release pipelines เช่น
    • username / password FTP Server
    • Connection String
    • geolocation หรือ setting เฉพาะ App เป็นต้น
  • Normal (เห็นหมดใน Log) and secret variables (ถ้า Mark ไว้ มันจะซ่อนจาก Log)
    • Note: ตอน Run Pipeline ตัว Agent เห็น variables แต่ถ้า pipeline has finished, the values will be cleared.
• Exercise - create and manage variable groups
• Knowledge check: Manage and modularize tasks and templates

Automate inspection of health

• Automate inspection of health
  • เราอยากรู้อะไรจากการ Build + Deploy เช่น
    • ภาพรวมของทุก Build / resource ที่ใช้
    • release ที่ผ่านมามัน pass หรือ fail
    • Quality ของ release เป็นอย่างไร Unit Test / Coverage / Security เป็นต้น
  • Azure มีอะไรช่วยเราบ้าง
    • Release gates - automatic collection of health signals from external services
    • Events > subscriptions - แจ้งตาม Event Type > and notifications (Email) - asynchronous actions
    • Service hooks - ใช้กับ Third Party กับ Azure DevOps เช่น จาก Trello / Slack / MatterMost ถ้าในไทยแบบ Line Notify
      Use-Case: ยกตัวอย่าง เช่น เวลามี Pull Request ให้แจ้งใน Slack เป็นต้น
      Note: Build-In Service Hook Support
      Exercise: Set up service hooks to monitor the pipeline
• Event + Notification ควรกำหนดแบบไหน เอาอะไรมาตัดสินใจ ?
  • Alerts - กำหนดดี ต้องระวังไม่งั้น มันเตือนจนน่ารำคาญ
  • Target Audience - ใครต้องมาสนใจ กำหนด query and filter mechanisms ได้
  • Delivery Mechanism - ทางไหน mail / slack / line
• Notification - มีแบบไหนบ้าง ?
  • Azure DevOps notifications
  • GitHub notifications
• How to measure quality of your release process
  • เน้นดู Process นะ มันจะมอง Release gates แต่ภายมันจะกว้างขึ้นมาอีกนิด ตัว Release gates มันสะท้อน Process แต่จริงๆมันวัด Quality ของ Code / Artifact / Security ด้วย
  • ถ้า Process มัน Fail บ่นๆ ต้องมาดูว่ามัน Dependency อะไร ในช่วงเวลาที่สนใจไหม
  • หรือ มีการแก้ไขตลอดแสดงว่ามีปัญหา //คหสต เคสหลังตอบยาก บางที่ประชุมเงียบ แล้วไปบ่นลับหลังกัน
  • ปกติเราจะดูจาก Dashboard ให้มัน Visualize ขึ้นมา อย่าง Jenkins มีภาพของสถานะในแต่ละ Stage // Azure ก็ทำได้นะ
• Release notes and documentation
  • มันมาจากไหน ?
    • Document store - เขียนเอกสารประกอบ พวก Word/Excel แต่จุดด้อย ไม่มี Link กับ Release เลย
    • Wiki - เขียน และทำ Link เชื่อม ออกจาก Manual นิดนึง รูปแบบที่นิยาม Markdown
    • In the codebase - อยู่กับ Code เลยเป็น living document แบบนึง + Unit Test
    • In a work item ตัว Tracker ช่วยให้ เรียกว่าเอา Wiki + In the codebase = doc แล้ว Auto ระดับนึง เช่น
      • Generate Release Notes Build Task.
      • Wiki Updater Tasks.
      • Atlassian Confluence.
      • Azure DevOps Wiki.
  • functional vs technical documentation
    • functional - describing the product afterward, like manuals or help files
    • technical - ทำ design phase is done ว่าทำไหม ถึงมี Logic / Flow แบบนี้ ?
• Considerations for choosing release management tools
  • Artifacts and artifact source -
    • Source Control systems ใช้ Git / SVN
    • รวม artifact ไหม
    • ใช้ build อะไรได้ java / msbuild … / รองรับ Container ไหม ?
  • Triggers and schedules
  • Approvals and gates
    • workflow with approvers
    • manual / automatic approval ?
  • Stages
  • Build and release tasks - ตัว Task มันเขียนมา reused ได้ไหม ใช้ได้ทุก Platform / Provider ไหม ?
  • Traceability, auditability, and security
  • อื่นๆ
    • ทั้งหมดมานี่ มี API ให้เชื่อมไหม ?
    • ต่อ AD องค์กรได้ไหม ?
    • four-eyes principle
    • Link requirements / tracker ระบบอื่นๆได้ไหม
• Common release management tools
  • GitHub Actions
  • Azure Pipelines
  • Jenkins
  • Circle CI
  • GitLab Pipelines
  • Atlassian Bamboo
• Lab 10: Examine considerations for choosing release management tools
• Knowledge check: Automate inspection of health

อื่นๆ

- Azure DevOps Intregation

• Azure ITSMC (IT Service Management Connector) ตัวเชื่อมกับ Enterprise ต่างๆได้
  • ServiceNow เป็น Platform สำหรับจัดการ Technical Workflow สำหรับ ITMS / ITOM (Operation) / ITBM (Business)
  • BMC
  • เวลาใช้งานเรียกใช้งาน IT Service Management Connector จาก Azure Market Place ได้เลย

- Chef & Puppet

• Chef
  - main component: Chef Server / Chef Client / Chef Workstation
  - open-source integrated product เช่น Habitat / InSpec
• Puppet
  - core-components: Master / Agent / Facts
  - Puppet Program (PP) elements Manifest file: Class / Resource / Module

Reference

• AZ-400: Design and implement a release strategy - Training | Microsoft Learn
• 8 Key Continuous Delivery Principles | Atlassian
• 8 Principles of Continuous Delivery - DZone DevOps