[AZ-400] Implement a secure continuous deployment using Azure Pipelines

Introduction to deployment patterns

• Explore microservices architecture
  • Traditional เป็น monolith - รวมทุกอย่างทั้งหมด ส่วนใหญ่ทำแบบ multi-layer architecture: UI / SERVICE (Business) / DATA
  • Now เป็น microservice - แบ่ง monolith ตาม one specific function. พอแยกออกมาแล้วการสื่อสารจะเป็นแบบ asynchronous โดย implement ด้วย queues / events.
    • Key: autonomous, independently deployable, scalable software component.
    • Microservice: If you built them correctly, you could deploy new microservice versions without impacting other parts of the system.
• Examine classical deployment patterns
  • Traditional: Dev > Test > staging stage (UAT) > production (Big Bang release - แก้เยอะกระทบทุก User //เจอความฉิบหายทั่วๆกัน 55)
• Understand modern deployment patterns
  • some features can only be tested in production. //Test On Production แบบที่ผมชอบบ่น แต่รอบนี้ไม่ได้ Big Bang บางส่วนเท่านั้น นึกถึง K8S ที่มี App Deploy 3 ตัว และอัพ Ver ใหม่ไป 1 แล้ว โยก Traffic ไป
  • สำหรับเทคนิคอื่นๆก็มี ดังนี้
    • Blue-green deployments - Azure App Service - deployment slots
    • Canary releases. - Blue-green + Feature toggles + Azure Traffic Manager - weighted round-robin routing method.
    • Dark launching. - เหมือน Canary releases. อารมณ์แบบ Parallel Run ทำทั้งแบบเดิม และใหม่คู่กัน แต่จะยึด Result จากของเดิมก่อน
    • A/B testing.
    • Progressive exposure / ring-based deployment. เหมือน Canary release แต่จะไปนับจากกลุ่มผู้ใช้แทน Canaries (เหยื่อ) > Early Adopters > Users (ใช้จริงแล้ว) ต้องนึกภาพ Windows Update ที่มีจัดกลุ่ม Insider Ring
    • Feature toggles - Azure App Configuration - Feature Manager.
• Knowledge check : Introduction to deployment patterns
• สรุปเทคนิคทั้งหมด โดยคุณ alex xu

Implement blue-green deployment and feature toggles

• What is blue-green deployment?
  • A technique that reduces risk and downtime by running two identical (เหมือนกัน) environments
  • Azure App Service - deployment slots ทำเรื่องนี้ โดยการ Swap จะค่อยเป็นค่อยไป โยก Traffic มาอีกตัวใหม่
  • ที่ควรระวัง เรื่อง DB Schema เพราะถอยไม่ได้แล้ว ตัว Application / Architecture ต้อง Support ด้วย //ระวังเรื่องลบ + constraint ใน Field ใหม่ที่เพิ่ม
  • Exercise - set up a blue–green deployment
  • ใน AzureDevOps สั่ง App Service ได้ โดยใช้ CLI

Az webapp deployment slot swap -g $(ResourceGroupName) -n $(WebsiteName) --slot Staging --target-slot production

• Introduction to feature toggles
  • เขียน Code เพื่อเปิด/ปิด feature
  • คำอื่นๆ feature flippers, feature flags, feature switches, conditional features
  • การเปิด Feature มี Guideline ดังนี้
    • Segment of users
    • randomly selected percentage of
    • all users at the same time

• feature toggles กับ Technical Debt
  • เวลาใส่ IF มาเพิ่ม มันเพิ่ม Technical debt เพราะมันเพิ่มค่า Cyclomatic Complexity ขึ้น อันนี้ในแง่ของ Software Engineering ส่วนภาษาคน-ทำให้ Code มันซับซ้อน และอ่านยาก แถมส่งเสริม Code Duplication อีก (ก็มันมี IF-ELSE อ่านะ)
  • Idea of a toggle is that it's short-lived //เอาจริงๆอยู่ยืนยง เคยมี Feature นึง Market ไม่ขาย ไม่บอก Dev แล้วก่อนจะส่งบอกให้เอาออก ตัว Feature Flag ผมก็ใส่ลงไปนะ ตอนปี 2016 ปัจจุบันยังอยู่ 5555
  • Martin Fowler แบ่งกลุ่ม toggles โดยให้ตั้งคำถามกับมัน ดังนี้
    • how long a toggle should be in your codebase
    • how dynamic the toggle needs to be
• Knowledge check: Implement blue-green deployment and feature toggles

Implement canary releases and dark launching

• Explore canary releases
  • canary ศัพท์นี้มาจากการทำเหมืองแร่ที่มันมีข้อจำกัดด้านอากาศ และมีแก๊สพิษเลยเอานกคีรีบูน (canary) เข้าไปด้วย ถ้านกมีเกิดตายขึ้นมาก่อนจะเป็นสัญญาณเตือนให้อพยพคนงานออกมา
  • กลับมาในมุมของ Sofware บ้าง canary releases คือ identify potential problems (หาปัญหาที่อาจจะพบใน Feature ใหม่) without exposing all your end users to the issue at once. (โดยที่ไม่กระทบกับทุกคน) การทำแบบนี้จะได้ประโยชน์
    • new feature only to a minimal subset of users.
    • potential performance
    • scalability problems
  • พอรู้แล้ว เราจะได้ตัดสินว่าจะไปต่อ หรือ roll back
  • จะใช้ canary release - มันเป็น high tolerance for issues.
• การ Implement canary releases จะใช้ 3 ส่วน
  1. deployment slots.
  2. feature toggles
  3. traffic routing - ต่าง deployment slots ที่ใช่ใน Blue-Green เพราะ อันนั้นจะ Swap (100%) แต่อันนี้จะทยอยโยก Traffic โดยใช้ Azure Traffic Manager
     • Traffic Manager - เราอาจจะ Set ตาม / Weighted ให้ทุก Pod (V1) รับ Load เท่ากัน หรือ Percent / Performance / Geographic / Multivalue / Subnet
     • ดูเพิ่มเติม Examine Traffic Manager | Microsoft Learn
• dark launching Implement เหมือน Canary releases.
  • อารมณ์แบบ Parallel Run ทำทั้งแบบเดิม และใหม่คู่กัน โดยที่ user ไม่รู้ (นี่เราแอบทำ dark lunching มานานเหรอเนี่ย 555) แต่จะยึด Result จากของเดิมก่อน
  • เมื่อได้ข้อมูลมากพอ จะถอดของเดิมออกแบบเงียบๆไป
• สรุป canary releases / dark launching ต่างกันยังไง ?
  • You are looking to assess users' responses to new features in your frontend (dark launching) rather than testing the performance of the backend (canary releases)
• Knowledge check: Implement canary releases and dark launching

Implement A/B testing and progressive exposure deployment

• What is A/B testing?
  • A/B testing (split testing / bucket testing) -เอา web หรือ app 2 version มาสุ่มให้ user ทดสอบ และใช้ statistical analysis มาตรวจสอบว่าแบบไหนดีกว่า ได้ conversion goal.
  • NOTE ใน CI/CD ยังไม่นับ A B Testing นะ

• Progressive exposure / ring-based deployment
  • ring = stages ใน DevOps Flow โดยวงที่ขยายใหญ่ขึ้นหมายถึงจำนวน Impact User ในรอบนั้นๆ จาก
    • Canaries - หนูลองยา
    • Early Adopters - ลองหลัง Canaries เละไปก่อน และ Fixed มาและ
    • Users - ได้ใช้ทุกคน
• Exercise - Ring-based deployment
• Knowledge check: Implement A/B testing and progressive exposure deployment
• Implement A/B testing and progressive exposure deployment - Training | Microsoft Learn

Integrate with identity management systems

• Integrate GitHub with single sign-on (SSO)
  • เชื่อม identity provider กับ GitHub at the organization level โดยใช้ SAML / SCIM
  • ดูเพิ่ม Integrate GitHub with single sign-on (SSO)
• Explore service principals
  • DevOps Project นิยมใช้กัน
  • ใช้ Service principal ต้องรู้ TenantID / ApplicationID / Client Secret. ก่อนใช้
• service principals มีกี่แบบ
  • Application - can then be granted permissions within services and resources that trust Azure Active Directory.
  • Managed Identity - ไม่ต้องให้ Credential ของตัวเองไป อย่าง เช่น Azure Data Factory จะเชื่อมกับ Azure SQL ถ้าเมื่อก่อนต้องให้ SQL Authentication (User/Pass) ต้องนี้ใช้ Identity ได้ โดยมี 2 แบบ
    • System-assigned - It's the types of identities described above. Many, but not all, services expose these identities. 1 / 1
    • User-assigned - you can create a managed identity as an Azure resource. It can then be assigned to one or more instances of a service.
  • Legacy - มีก่อน App Registration
• Knowledge check : Integrate with identity management systems

Manage application configuration data

• application configuration คือ ที่เก็บการตั้งค่าของ Application อาทิ เช่น DB Connection String / UI Theme Skin / Secret เป็นต้น
• application configuration (use case)
  • เดิม : 1 Config ต่อ 1 Application Instance ทำให้ดูยาก และฝังไปกับ Source Code เลย
  • ปัจจุบัน: 1 Config ใช้กับ n Application Instance หรือ หลายที่ต่างกัน App แต่มีปัญหาอีกแหละ ว่าต้องไปเอา Config ไปแปะให้ทุก App / Maintain ยาก แต่ก็มี Tool อย่าง chef / puppet มาช่วย
• separation of concerns - จาก application configuration (use case) เราสามารถแบ่งความรับผิดชอบได้ ดังนี้
  • Configuration custodian - คนสร้าง config
    • It includes CRUD on keys
    • ensuring the security of secrets
    • regeneration of keys and tokens
    • defining configuration settings such as Log levels for each environment.
  • Configuration consumer - คนใช้งาน config เช่น Dev / QA มาแก้ DB Connection ไปเครื่องตัวเองทดสอบ
  • Configuration store - ปกติเก็บลง File คู่กับ App แต่ถ้าเป็น App แบบ distributed application ตัว Config ควรจะ Share ข้าม Environment ต่างได้ แต่ไม่ได้จัดการ Credential
  • Secret store - จัดการ Credential

• Understand external configuration store patterns จาก application configuration (use case) + separation of concerns ตามรูปด้านบน The implementation
  • Authorize users' access to protect configuration data
  • Flexible multiple configuration version อาจจะมองในมุมของ development/ staging / production เป็นต้น
  • ตัว Configuration หลักเก็บลง Cloud Storage หรือ Database ก็ได้ และตอน App มาเรียกใช้ อาจจะมี Local Cache เพื่อให้ distributed application มาหาก่อน
• external configuration store patterns ใน Azure -
  • Azure App Configuration
  • Azure Key Vault 
• Introduction to Azure App Configuration
  • จัดการ Config ได้ทั้งของ App และ Feature Flag ก็อยู่ในนี้
  • รองรับ .NET Framework / .NET Core / Spring / Other (REST API)
  • การจัดการ Config เป็น Key & Value Pair มันจะคล้ายใน [AZ-204]: Implement secure cloud solutions - Implement Azure App Configuration
  • More Detail: Examine Key-value pairs
• Integrate Azure Key Vault with Azure Pipelines
  • จัดการส่วน Secret ที่ตัว Azure App Configuration ไม่ได้จัดการ เช่น Connection strings / Passwords / Certificates / Tokens เป็นต้น
  • มันจะคล้ายใน [AZ-204]: Implement secure cloud solutions - Implement Azure Key Vault (Key benefits of using Azure Key Vault)
  • More Detail: Manage secrets, tokens and certificates

• Examine DevOps inner and outer loop
  • store configuration and secrets together, it violates our separation of concern principle
  • inner - งาน Dev หมดเลย Code + Test
  • outer - งาน Ops จัดการ Config CI/CD พวก Config / Secrets ต่างๆ ทาง Ops เตรียมไว้ให้ Dev ได้ Dev แค่เอา Connection String ไปใช้เป็นต้น
  • แล้วงานเรา มันมั่วทั้ง inner + outer เลย 5555
• Lab13: Integrate Azure Key Vault with Azure DevOps
• Knowledge check: Manage application configuration data

Reference

• AZ-400: Implement a secure continuous deployment using Azure Pipelines - Training | Microsoft Learn