Skip to main content

Trunk-Based development guideline

Với mục tiêu release tính năng, bugfix, improve trải nghiệm cho người dùng càng sớm càng tốt nhằm mục đích tăng giá trị sản phẩm, tăng độ hài lòng của khách hàng. Team development AVADA Development nhận thấy cần thống nhất lại một guideline chung về việc commit, quản lí branching trong team sao cho phù hợp nhất với mục tiêu của team.

Một mục đích nữa bài viết này là để giúp mọi người trong team nắm được trên gọi của Git Versioning Model mà mình đang làm, và đang áp dụng là gì, để có thể theo dõi và tìm hiểu thêm xu hướng trong cộng động khi có những thay đổi mới về quy chuẩn, về các strategy mới xuất hiện.

Trước này chúng ta phát triển tính năng và commit như thế nào?​

Trước đây, khi phát triển một tính năng mới cho sản phẩm, một tính năng mới thường mất nhiều thời gian, 1 sprint có thể lên đến một tháng. Cùng lúc đó nhiều sprint chạy cùng một lúc. Team đã giữ 1 nhánh là develop và mỗi sprint kết thúc. Mọi người sẽ lại phải merge vào develop sau đó từ develop merge về master. Việc này trước nay khá ổn và phù hợp với giai đoạn đầu của dự án. Tuy nhiên, quy thời gian, nó bộc lộ một số nhược điểm.

  • Có một nhánh develop bị outdated với codebase ở production
  • Thời gian release tính năng lâu, người dùng phải đợi.
  • 1 tính năng lớn mất thời gian dài review
  • Phải merge nhiều tính năng vào với nhau rồi mới cùng release ⇒ Release lớn, dễ lỗi.

Việc brancing và commit như trên được gọi là GitFlow đây là một Git branching model đã phát triển khá mạnh nhiều năm trước, nhưng tới những năm gần đây nó đang mất dần sự phổ biến và nhường chỗ lại cho Trunk-Based Model.

Trunk-based là gì?​

Trunk-based là một dạng best practice mà dev sẽ liên tục, thường xuyên merge các commit nhỏ, tính năng nhỏ vào nhánh chính (củ thể đây là master hoặc trunk). Trunk-based development mong đợi dev tạo ra các nhánh nhỏ, thời gian tồn tại ngắn được tách ra từ master so với việc tạo 1 nhánh từ develop có thời gian tồn tại lâu, nhiều commit và nhiều code. Khi codebase ngày càng phức tạp, nhiều tính năng, việc release nhỏ, liên tục sẽ giảm thiểu đau đầu cho cả dev, test và reviewer khi lượng code được đưa lên production nhỏ, dễ quản lí, dễ debug nếu lỗi phát sinh.

Gitflow vs Trunk Based​

Với Gitflow, sẽ tồn tại nhiều nhánh tồn tại thời gian dài, và sẽ không merge vào master nếu tính năng chưa tính là hoàn thành, thậm chí là còn đợi merge với các tính năng khác. Thường thì với luồng Gitflow sẽ có các nhánh develop , hotfix riêng, ở team mình hiện tại cũng chỉ giữ nhánh develop thôi.

Còn đối với Trunk-based thì tập trung và trunk hay nhánh master là nguồn tách nhánh chính để mọi tính năng, hotfix, improvement sẽ luôn luôn được tách ra từ master, không đợi các tính năng khác đang phải triển phải xong mới release vì cứ không có confict với master thì tức là an toàn và đủ điều kiện deploy lên production.

Áp dụng Trunk Based​

Để phù hợp với mục tiêu mới của team là đưa tính năng, bugfix, improvement tới người dùng càng sớm càng tốt, sẽ có một số điều cần áp dụng trong team như sau:

  • Mỗi khi có tính năng, task mới mọi người cần tách ra từ master để đảm bảo cập nhật mới nhất và có thể sẵn sàng merge lại vào master ít conflict nhất có thể
  • Chủ động chọn các tính năng có thời gian development ngắn hơn, chia nhỏ task hơn để có thể go live từng phần lên càng sớm càng tốt để tăng giá trị mang lại cho khách hàng.
  • Một khi đã xong tính năng, làm sang tính năng khác thì tạo nhánh mới, không dev thêm tính năng mới, chưa đủ điều kiện release vào nhánh đã hoàn thành. Để tránh trường hợp khi muốn go live tính năng, bị vướng vào phần code đang code dở.
  • Các nhánh sẽ theo cứ pháp như sau: type/name Ở đây type là feature , hotfix , improve, bugfix theo sau bởi tên tính năng. Ở đây feature cho tính năng mới. hotfix cho những lỗi cần sửa gấp. bugfix là những vấn đề cần sửa nhưng không quá gấp. improve để dành cho những phần cải thiện trải nhiệm nhưng không phải lỗi.

Đi đâu từ đây​

Mục tiêu cao nhất của Trunk-based development là hướng đến Continuous Delivery và Continuous Deployment. Đây là mục tiêu và nhiều phần mềm theo đuổi khi tạo ra 1 sản phẩm được update liên tục, tự động. Mọi bugfix, improvement được hệ thống CI/CD kiểm duyệt, test tự động, và deploy tự động. Nhận định và tình hình hiện tại team có thể còn rất xa với tương lai trên.

Tuy nhiên, việc đầu tiên ta có thể làm đó là có thể Continuous Delivery và Continuous Deployment không chạy máy móc tự động, nhưng con người vẫn có thể làm và quan trọng nhất vẫn là mang được giá trị mới tới cho người dùng càng sớm càng tốt. Và đương nhiên vẫn cố gắng để hoàn thiện và hướng đến 1 hệ thống CI/CD hoàn chỉnh trong tương lai không xa

Avada Flow làm việc​

Video:

Tham khảo​

Mọi người có thể tham khảo thêm bài viết bên Atlassian để có những góc nhìn khác:

Reference: https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development