azure
azure

[AZ-400] Development for enterprise DevOps

Structure your Git Repo

  • Monorepo or Multiple repos
    • Monorepo (ในหนังสือ Software Engineer @ Google แนะนำนะ-Allow teams working together on a system to go fastest.)
      • จุดเด่น เพราะเป็น Single source of truth แก้ไขต่างๆ อยู่ใน commit เดียวกัน / เห็นภาพรวม เกิด แชร์ code และ reuse ไม่มีเส้นแบ่งระหว่างทีม
      • จุดด้อย ต้องทำ Code Health ดีตลอด เพราะ ถ้าพลาดพังหมด
    • Multiple repos
      • จุดเด่น ทุกทีมสามารถแยกส่วนการจัดการได้เลย
      • จุดด้อย หากมีการแก้ไข Lib ต้องมีการแจ้งคุย ดูผลกระทบ และรอการ Build รวมถึงเอาไป Reference ในแต่ละ repo
  • Implement a change log - บอกการเปลี่ยนแปลงของ Code ในแต่ละ release มีหลายแบบ
    • Manual - เขียนกันเอง ลง Blog / Wiki
    • Automate - git log และ gitchangelog มันดูจาก Commit ต้องเขียนให้สื่อ
  • Knowledge Check: Structure your Git Repo

Manage Git branches and workflows

  • Explore branch workflow types - Common branch / Trunk-based development / Forking workflow
  • Explore feature branch workflow &
    • feature branch Code ที่กำลังพัฒนาออกจากเส้นหลัก main branch ที่ใช้เก็บ Code ที่ใช้งานบน Production
    • Trunk-based development (เค้า Recommend อันนี้เลย)
  • Explore Git branch model for continuous delivery Branch ต่างๆ
    • main branch - Code ที่ใช้งานบน Production (ready-to-release state)
    • feature branch - กำลังพัฒนาออกจากเส้นหลัก แตก Branch สั้นๆ ทำ Feature และ ควรกำหนด feature flags เปิด/ปิด การทำงาน ส่วน Pattern การตั้งชื่อประมาณนี้
      bugfix/description
      features/feature-name
      features/feature-area/feature-name
      hotfix/description
      users/username/description
    • Pull Request เพื่อให้เกิดการ review code ก่อนเข้า Main Branch
  • Explore GitHub flow & fork workflow
    • fork - gives every developer a server-side repository //เป็นการ Clone แหละ แต่ Server ทำให้
    • พอแก้ Code เสร็จค่อย Pull Request กลับไป
  • Lab3: Version control with Git in Azure repos
  • Knowledge Check: Manage Git branches and workflows

Collaborate with pull requests in Azure Repos

Ref: About pull request merges - GitHub Docs
  • Merge Strategies 
    • Merge - เอา Log ของ Branch ที่ กำลังจะ Merge เข้ามาต่อใน Branch หลัก
    • Squash Merge - ยุบ Merge Log ของ Branch ที่ กำลังจะ Merge ให้เหลือเพียง one commit for each merged branch
    • Cherry Pick - ตัด Code จาก Commit ที่สนใจมาใส่ Branch ปลายทางจะใช้ในเคสมี Branch release ของลูกค้า A แล้วปรากฏว่า branch ของลูกค้าอื่นๆมี Bug นี้ที่ต้องไปแก้ด้วย
    • 3-way merge - version control - Why is a 3-way merge advantageous over a 2-way merge? - Stack Overflow
  • Pull Requests
    • everyone shares a single repository, and topic branches are used to develop features and isolate changes.
    • Then code reviewed > great feedback
      Note: branches ไหนที่สำคัญให้กำหนด Policy ขึ้นมา branches policies เช่น pull requests + Guideline
  • Azure DevOps - Branch policies
    1. จำนวน Reviewer - ถ้ามีปัญหาว่าใครจะ Review มี Automatically included reviewers มากำหนด Policy ให้
    2. Link กับ Work Item หรือยัง จะตรวจสอบได้ว่าที่ส่ง Merge มา มาจาก Task ไหน
    3. code review comments
    4. ดูรูปแบบการ Merge เข้ามา

Identify technical debt

  • เน้นส่วนของ Code Review ตอนทำ Pull Request และ
  • Code Quality -
    • Reliability - probability that a system will run without failure วัดจาก mean time between failures (MTBF)
    • Maintainability
    • Testability - size and complexity (วัดจาก cyclomatic complexity) of the software can impact testability //Refactor Code ให้เขียนง่ายจะดีที่สุด
    • Portability - Same SWใน Enviroment ต่างกันทำงานได้เหมือนกัน อาจจะใช้ coding standard (ส่วนตัวมองว่ามันช่วยได้หลายมุมเลย)
    • Reusability - พยายามทำให้ Code มัน modularity / loose coupling characteristics.
  • Code Quality metrics - ถ้า Common เช่น
    • Failed builds percentage - Overall, what percentage of builds are failing?
    • Bug bounce percentage - What percentage of customer or bug tickets are reopened?
  • Technical Debt - หนี้ทางเทคนิค เราเขียน Code ที่ไม่ตรงตาม Standard แล้ว ตอนแรกอาจจะใช้เวลา Fixed 1-2 ชั่วโมง แต่ถ้าปล่อยไปนานๆ อาจจะใช้เวลานานมากกว่านั้น
    • Handle: Technical Debt
    • คหสต คนที่ทำ Technical Debt มักไม่ได้กลับมาแก้เอง ส่วนมากไม่อยู่และ
  • Knowledge Check: Identify technical debt

Explore Git hooks

  • Git Hooks = กลุ่มคำสั่งที่ Git จะเรียก ก่อนหรือหลัง event ใด เช่น commit, push เป็นต้น
  • Practical use cases - notification / check pre-condition ก่อน merge (เช่น ตรวจว่าไม่มี hardcode secret ลงไปใน Code) / ตรวจ Lint เป็นต้น
  • Implement Git hooks - น่าสนใจ เอามาลองกับ GitLab
  • นอกจากฝั่ง Client ตัว Azure Repos มี hook ฝั่ง server ด้วย
  • Knowledge Check: Explore Git hooks

Plan foster inner source

  • Inner source = "internal open source" open-source software development inside your firewall
    • ลด Silo ลงทุกคนมีโอกาสได้เห็น Code หมด เช่น ทีม Visual Studio คิดว่าบั๊กมันเกิดจาก Windows ก็ไป Fork Code แก้ แล้ว Pull Request (PR) กลับไปให้ทีม Windows Review และ Merge เข้า
  • The forking workflow (ถ้า Dev ที่ทำงานร่วมกันน้อย 2-5 คน อาจจะไม่จำเป็นต้องใช้ Flow Fork
    • Create a fork.
    • Clone it locally.
    • Make your changes locally and push them to a branch.
    • Create and complete a PR to upstream.
    • Sync your fork to the latest from upstream.
  • Azure DevOps จะมี Flow นี้อยู่นะตามรูปเลย

Manage Git repositories

  • Work with large repositories
    • large repositories มาจาก Long history / Large binary files
    • Workaround โดยใช้ Shallow clone
      git clone --depth [depth] [clone-url]
    • Azure มี Tools VFS for Git / Scalar มาจัดการไฟล์ใหญ่
  • Purge repository data
    • git filter-repo tool - rewriting history
    • BFG Repo-Cleaner - deleting or "fixing" content in repositories
  • Manage releases with GitHub Repo - ดูจาก tags + commit มาสร้าง
  • Automate release notes with GitHub
  • Knowledge Check: Manage Git repositories

Reference

Discover more from naiwaen@DebuggingSoft

Subscribe to get the latest posts sent to your email.

Tags

Related Posts