The Cygnus space freighter moments after its release from the Canadarm2 robotic arm
The Cygnus space freighter moments after its release from the Canadarm2 robotic arm by NASA Johnson is licensed under CC-BY-NC-ND 2.0

[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 ให้ขาดออกจากกัน
Ref: Understand releases and deployments in Azure Pipelines - Azure Pipelines

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 ของเราก็ได้
  • 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

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 - มีแบบไหนบ้าง ?
  • 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 ระดับนึง เช่น
    • 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
  • 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

Discover more from naiwaen@DebuggingSoft

Subscribe to get the latest posts sent to your email.

Tags

Related Posts