Trang web này đã được dịch bằng máy để thuận tiện cho bạn. Chúng tôi không thể đảm bảo tính chính xác hoặc độ tin cậy của nội dung được dịch. Nếu bạn có thắc mắc về tính chính xác của nội dung được dịch, vui lòng tham khảo phiên bản tiếng Anh chính thức của trang web.
Quy trình làm việc nhánh tác vụ là gì?
Mô hình rất đơn giản: Bạn tạo một nhánh mới để làm việc cho mỗi tác vụ mới trong trình theo dõi vấn đề của mình. Các nhánh tác vụ phù hợp nhất để làm việc với Unity Version Control vì nó có thể dễ dàng xử lý hàng nghìn nhánh. Quy trình làm việc này không bắt buộc, và cuối cùng, bạn phải đánh giá quy trình làm việc nào là tốt nhất cho tổ chức của mình.
Lợi ích chính
Phát triển song song
Quy trình nhánh tác vụ được thiết kế để tạo điều kiện thuận lợi hơn cho việc phát triển song song so với các phương pháp truyền thống, vốn có thể chỉ sử dụng một nhánh. Với mỗi tác vụ trong một nhánh riêng, bạn luôn sẵn sàng phát hành từ nhánh chính.
Nội dung luôn được kiểm soát
Thông thường, các nhà phát triển cẩn thận về việc cam kết các thay đổi, điều này có thể giữ các thay đổi bên ngoài kiểm soát nguồn quá lâu. Các quy trình làm việc nhánh tác vụ cho phép kiểm tra thường xuyên, vì vậy bạn luôn có thể xem toàn bộ lịch sử thay đổi trong hệ thống.
Giữ nhánh chính sạch sẽ
Tổ chức nhánh chính là một trong những mục tiêu của phương pháp nhánh-theo-nhiệm vụ. Kiểm soát cẩn thận mọi thứ đi vào nhánh chính có nghĩa là không có cách dễ dàng nào để làm hỏng bản dựng một cách vô tình, vì các lỗi mới được cô lập trong nhánh tác vụ.
Các bước chính của quy trình làm việc nhánh tác vụ
Trong tinh thần DevOps, quy trình làm việc này có thể rút ngắn thời gian chu kỳ tác vụ và đưa nội dung mới vào sản xuất càng sớm càng tốt. Triển khai phần mềm gốc trong thói quen hàng ngày của bạn.
Nhiệm vụ và nhánh nhiệm vụ
Quy trình bắt đầu bằng một tác vụ trong trình theo dõi sự cố hoặc hệ thống quản lý dự án của bạn: Jira, Bugzilla, Mantis, OnTime, hoặc giải pháp nội bộ của bạn. Điều quan trọng ở đây là mọi thứ bạn làm đều phải có một nhiệm vụ liên quan. Không quan trọng đó là một phần của tính năng mới hay sửa lỗi – hãy tạo một nhiệm vụ cho nó.
Tiếp theo, bạn tạo một nhánh cho tác vụ đó.
Chúng tôi đề xuất một quy ước đặt tên nhánh đơn giản: Một tiền tố ("task" trong ví dụ) theo sau là số nhiệm vụ trong trình theo dõi sự cố. Điều này giúp bạn duy trì khả năng truy xuất nguồn gốc đầy đủ các thay đổi.
Phát triển
Làm việc trên nhánh tác vụ và thực hiện nhiều lần checkin nhất có thể. Giải thích từng bước trong phần bình luận để cung cấp sự rõ ràng cho bất kỳ người đánh giá nào.
Khi tác vụ hoàn thành, hãy đặt thuộc tính "trạng thái" trên nhánh là "đã giải quyết".
Hoặc, bạn có thể đánh dấu nó là đã hoàn thành trong trình theo dõi sự cố của mình. Tất cả phụ thuộc vào bộ công cụ cụ thể của bạn và cách bạn thực sự triển khai quy trình làm việc.
Đánh giá
Khi bạn đánh dấu nhiệm vụ của mình là hoàn thành, nó có thể được đồng nghiệp xem xét.
Bây giờ đến lượt người đánh giá xem xét những thay đổi của bạn và xem liệu họ có thể phát hiện ra lỗi, sai sót hoặc sự không nhất quán trong phong cách mã hóa của bạn, hoặc bất kỳ khía cạnh thiết kế nào cần thay đổi hay không. Nếu vậy, nhiệm vụ sẽ được mở lại và chu kỳ sẽ bắt đầu lại.
Xác thực
Xác thực là một bước tùy chọn.
Một số nhóm sẽ "xác thực" nhiệm vụ – một thành viên khác trong nhóm sẽ thực hiện một bài kiểm tra thăm dò ngắn để đảm bảo tính năng hoặc thay đổi mới có ý nghĩa. Họ không tìm lỗi (các bài kiểm tra tự động lo việc đó) mà xem xét sự thay đổi từ góc độ của khách hàng. Trạng thái có thể được đặt thành "đã xác thực" trong thuộc tính.
Tự động hóa kiểm thử và hợp nhất
Cấu hình hệ thống tích hợp liên tục (CI) của bạn để giám sát tất cả các nhánh có thuộc tính được đặt. Một nhánh sẽ chỉ được hệ thống CI xem xét khi nó đạt đến một trạng thái nhất định (trong trường hợp này là "đã xác thực").
Sau khi tác vụ được xem xét/xác thực, nhánh tác vụ sẽ tự động được kiểm tra trước khi được hợp nhất vào main.
Nếu bộ kiểm thử vượt qua việc hợp nhất, nó sẽ được xác nhận và gửi đến hệ thống CI để xây dựng và kiểm thử. Quy trình này giúp ngăn ngừa việc build bị lỗi. Nếu nó thất bại, quá trình sẽ được khởi động lại và bạn sẽ phải rebase từ main để giải quyết bất kỳ xung đột nào.
Triển khai
Nếu các bài kiểm tra vượt qua, việc hợp nhất sẽ được kiểm tra và nhánh hiện đã sẵn sàng để phân phối. Lưu ý rằng trạng thái hiện đã được đặt thành "merged."
Nếu bản phát hành mới sẵn sàng để triển khai, thay đổi mới trên nhánh chính được gắn nhãn như vậy và phần mềm được triển khai lên môi trường sản xuất.
Bạn có thể nhận được một bản phát hành mới sau mỗi tác vụ mới đi qua chu trình này, hoặc bạn có thể quyết định nhóm một vài tác vụ lại. Khi thực hành triển khai liên tục, việc triển khai mọi tác vụ lên môi trường sản xuất là quy trình hợp lý nhất.
Các phương pháp hay nhất
Thiết lập tích hợp liên tục
Với Unity Version Control, bước kiểm thử và hợp nhất tự động có thể được cấu hình bằng plug-in cho công cụ CI bạn chọn, chẳng hạn như Jenkins, Bamboo hoặc Unity Cloud Build.
Bước này cũng có thể được điều phối bằng tính năng mergebot của Unity Version Control. Mergebot có thể hợp nhất các nhánh và kích hoạt một bản dựng để đảm bảo nó hoạt động. Các lần hợp nhất chỉ được xác nhận nếu bản dựng tốt, tránh các bản dựng bị lỗi.
Các phương pháp hay nhất về quy ước đặt tên nhánh
Chúng tôi thích tuân theo quy ước đặt tên sau: tiền tố + số tác vụ. Ví dụ, các nhánh có thể được đặt tên là task1213, task1209 và task1221. Tiền tố là “task,” và số đại diện cho số nhiệm vụ thực tế trong trình theo dõi sự cố liên quan.
Ảnh chụp màn hình cũng hiển thị mô tả cho từng nhánh cùng với số vì trình khám phá nhánh lấy số từ trình theo dõi sự cố. Bạn cũng có thể xem mô tả nhánh bằng cách chọn “hiển thị thông tin tác vụ nhánh.”
Giữ các nhánh tác vụ ngắn
Các quy tắc của Scrum quy định rằng các tác vụ không nên dài hơn 16 giờ. Thực hành này giúp kiểm soát tiến độ dự án.
Các nhánh tác vụ phải được đóng nhanh chóng. Lý tưởng nhất là bạn nên có nhiều nhiệm vụ nhỏ mà bạn có thể hoàn thành chỉ trong vài giờ. Cấu trúc này giúp duy trì nhịp điệu dự án của bạn và tạo điều kiện cho việc Deployment liên tục. Một nhiệm vụ lớn hơn kéo dài cả tuần, ví dụ, làm đình trệ chu trình.
Một dấu hiệu cảnh báo cần lưu ý: Đừng tạo các nhiệm vụ "cắt bằng dao rựa". Nếu bạn cần chia một nhiệm vụ thành các phần nhỏ hơn, hãy đảm bảo rằng nhiệm vụ đó vẫn có ý nghĩa khi đứng một mình và có thể được triển khai độc lập.
Quy trình làm việc và văn hóa
Các quy trình làm việc của nhánh tác vụ chỉ có thể thành công với sự đồng thuận của toàn đội.
Giống như bất kỳ quy trình DevOps nào, có một thành phần văn hóa trong quy trình làm việc này. Các nhánh tác vụ là về việc giao tiếp tiến độ một cách cởi mở và tránh tình trạng biệt lập. Trước khi bắt buộc một quy trình làm việc hoặc một cách làm việc cụ thể với các nhiệm vụ, bạn cần thúc đẩy sự đồng thuận. Giúp các thành viên trong nhóm hiểu lợi ích của việc hoàn thành một phần nhỏ của một nhiệm vụ lớn hơn ngay hôm nay, thay vì vật lộn với các nhiệm vụ lớn trong thời gian dài hơn.
Giữ các nhánh tác vụ độc lập
Hãy tự hỏi (hoặc đồng đội của bạn): Bạn có thực sự cần mã bạn vừa hoàn thành trong nhiệm vụ 1213 để bắt đầu nhiệm vụ 1209 không?
Các nhiệm vụ có xu hướng độc lập hơn nhiều so với bạn nghĩ. Vâng, chúng có thể cùng chủ đề, nhưng bạn không cần chạm vào chính xác cùng một đoạn mã. Bạn có thể chỉ cần thêm thứ gì đó mới và tin tưởng vào việc hợp nhất để nó làm việc.
Giả sử rằng 1213 và 1209 trong ví dụ trên là các bản sửa lỗi thay vì các tác vụ. Bạn không muốn một cái phụ thuộc vào cái kia. Bạn muốn họ đánh vào chính và được phát hành nhanh nhất có thể. Ngay cả khi chúng chạm vào cùng một mã, chúng vẫn là những bản sửa lỗi khác nhau.
Kiểm tra với các người đánh giá trong tâm trí
Mỗi phần kiểm tra phải giúp người đánh giá theo dõi mạch suy nghĩ và quy trình của bạn để hiểu cách bạn giải quyết nhiệm vụ.
Để lại chi tiết trong phần bình luận của việc checkin sẽ giúp người đánh giá, vì họ sẽ không cần phải so sánh toàn bộ nhánh. Thay vào đó, họ sẽ khác biệt từng thay đổi một. Và họ sẽ làm theo phần giải thích được ghi âm trước mà bạn đã làm để làm rõ từng giai đoạn của nhiệm vụ. Họ sẽ không thấy mình đang nhìn vào một danh sách đậm gồm hơn 100 tệp đã sửa đổi. Thay vào đó, họ sẽ đi từng bước một.
Các tác vụ đã hoàn thành phải có thể triển khai được
Mọi nhánh tác vụ phải sẵn sàng để tích hợp sau khi hoàn thành. Nếu một thay đổi mong manh hoặc sẽ khiến sản phẩm hoạt động một cách vụng về, thì nhiệm vụ không nên được đặt là hoàn thành.
Đây là một cái giá nhỏ phải trả cho những lợi ích của tự động hóa. Đội ngũ phải thống nhất về định nghĩa của "hoàn thành", nghĩa là "sẵn sàng cho sản xuất". Đổi lại, bạn có thể yên tâm biết rằng việc chuyển tác vụ của bạn lên môi trường sản xuất là dễ dàng, hoàn toàn tự động và sẽ không dẫn đến tình trạng khẩn cấp lúc 2 giờ sáng.
Các công tắc tính năng
Cờ tính năng là gì? Những điều này rất quan trọng cho việc triển khai liên tục. Kỹ thuật phát triển phần mềm này cho phép các tính năng được kiểm thử trước khi chúng hoàn thành và sẵn sàng để phát hành.
Một công tắc tính năng có thể ẩn, bật hoặc tắt tính năng trong quá trình chạy. Nó cho phép bạn bật một tính năng chỉ cho đội ngũ phát triển, một số lượng nhỏ người dùng sớm, hoặc cho tất cả mọi người. Ví dụ, một nhà phát triển có thể bật một tính năng để thử nghiệm và tắt nó đối với những người dùng khác trong quá trình phát triển.
Sử dụng các công tắc tính năng
Hãy xem một ví dụ. Bạn có một tính năng lớn được chia thành bảy phần sẽ được chuyển thành các tác vụ và triển khai bằng các nhánh tác vụ. Làm thế nào để triển khai Phần 4 nếu không có gì khác sẵn sàng?
Phần 4 có thể được hợp nhất vào nhánh chính và thậm chí được triển khai trong khi vẫn ẩn bằng cách sử dụng công tắc tính năng.
Ẩn không có nghĩa là mã mới bỏ qua việc kiểm thử trước khi phát hành. Khi toàn bộ tính năng sẵn sàng để kích hoạt, các thành phần riêng lẻ đã được kiểm tra nhiều lần. Việc tích hợp phần cuối cùng sẽ không kích hoạt một lần hợp nhất lớn; đó chỉ là một phần nhỏ hơn đi vào main.
Các hướng dẫn hữu ích hơn
Các câu hỏi thường gặp
Unity Version Control có thể giúp bạn với việc phân nhánh và hợp nhất. Nhánh và hợp nhất (ngay cả các hình ảnh trực quan trong các ví dụ trên) là một phần của sản phẩm. Version Control không phải là một hệ thống CI, mà nó là một bộ điều phối. Nó có thể kích hoạt các bản dựng, tự động hóa các lần hợp nhất, thực hiện gắn nhãn và nhiều hơn nữa.
Plastic cung cấp một API để tích hợp với hầu hết các hệ thống CI trên thị trường. Ngay từ đầu, nó tích hợp với Unity Build Automation, Jenkins, Bamboo và TeamCity.
Vâng, bạn có thể cắm CI của riêng mình và thực hiện chu trình được mô tả ở trên.
Nếu bạn muốn tận dụng tối đa chu trình trên và hoàn thành tự động hóa, bạn nên. Nhưng bạn luôn có thể làm thủ công: bạn có thể tạo các nhánh tác vụ, làm việc trên chúng và nhờ một người trong nhóm (người tích hợp/kỹ sư xây dựng) thực hiện việc hợp nhất.
Không. Unity Version Control cực kỳ linh hoạt, và bạn được tự do triển khai bất kỳ mẫu nào bạn muốn.
Chúng tôi tin tưởng mạnh mẽ vào các nhánh tác vụ vì chúng hòa hợp rất tốt với các mô hình hiện đại như phát triển dựa trên trunk.
Ví dụ, nhiều đội game (đặc biệt là các nghệ sĩ) thích làm việc trên một nhánh duy nhất, luôn kiểm tra vào nhánh chính, điều này là ổn.
Gửi một tác vụ sẽ là một phần của một người quản lý sản phẩm/người quản lý scrum/bạn-tên-bất-khi-nào hầu hết thời gian. Nhưng ngay cả khi, với tư cách là một nhà phát triển, bạn phải nộp nó, mỗi phút tiết kiệm được trong việc mô tả những gì cần làm sẽ giúp bạn tiết kiệm được một lượng lớn các câu hỏi, vấn đề và hiểu lầm.
Đối với quy trình làm việc này, bạn sẽ cần tách chúng ra. Một số trong số này có thể là một "câu chuyện" hơn, hoặc thậm chí là một "sử thi" với nhiều nhiệm vụ liên quan. Bằng các nhiệm vụ, chúng tôi muốn nói đến các đơn vị công việc thực tế: những phần công việc nhỏ nhất có thể được giao dưới dạng một đơn vị.