Bản ghi video (Phần 1):
Chào mừng đến với Phần 1 của Chiến lược Phân nhánh. Tên tôi là Tomaz Borstnar. Khi bạn sử dụng các công cụ như Git, bạn có rất nhiều sự linh hoạt, nơi bạn có thể quyết định loại sử dụng Git phù hợp với phong cách phát triển của bạn, cho quy mô nhóm của bạn, cho tần suất phát hành các ứng dụng của bạn, v.v.
Vì vậy, những cách phù hợp để triển khai là gì? Nói chung, bạn nên tuân theo cái gọi là tích hợp và triển khai liên tục. Vì vậy, ý tưởng với việc triển khai tích hợp liên tục là trong trường hợp bạn có các bản phát hành phần mềm mới rất thường xuyên, thậm chí có thể là nhiều lần mỗi ngày, mỗi giờ, v.v. Nó phụ thuộc vào nhiều thứ.
Bạn nên có một quá trình kiểm tra, chọn lọc rất tốt. Mặc dù bạn đã sản xuất và phát hành các ứng dụng rất thường xuyên, có khả năng xoay xở tốt, bạn vẫn nên cần sự kiểm tra về code một cách kĩ lưỡng.
Và bạn cũng nên chuẩn bị sự phản hồi nhanh chóng đối với bất kỳ vấn đề cấp bách nào. Ví dụ, nó có thể là một vấn đề lớn về bảo mật hay có thể là vấn đề ảnh hưởng nghiêm trọng đến việc sản xuất ứng dụng, v.v. Hoặc có thể có sự thay đổi đột ngột về yêu cầu ứng dụng của khách hàng. Vì vậy, bạn phải có thời gian phản hồi rất nhanh, khả năng xoay xở tốt, ổn định, thực hiện rất nhiều thử nghiệm trên các ứng dụng, phần mềm của mình trước khi cho ra mắt, nhưng bạn cũng phải sẵn sàng ngay lập tức khi cần thiết. Tất nhiên, điều này có thể hơi khó nhưng với chiến lược phù hợp thì vẫn có thể đạt được.
Vì vậy, như đã đề cập, khi bạn quyết định chiến lược phân nhánh, tất nhiên, điều đó phụ thuộc rất nhiều vào đội ngũ nhóm phát triển ứng dụng của bạn. Văn hóa hiện tại của đội là gì? Quy mô, số lượng thành viên trong đội như thế nào? Hay bạn là người duy nhất đảm nhiệm mọi chuyện, v.v... Nhưng ngày nay, khi bạn chuẩn bị cho ra mắt một ứng dụng thật sự nghiêm túc, trong hầu hết các trường hợp, nó cần phải có sự làm việc và đóng góp của nhiều thành viên trong nhóm. Vì vậy, những chiến lược đó nên được chuẩn bị cho số lượng các nhà phát triển (developers) hiện tại trong nhóm. Và các chiến lược đó cũng nên được tính trước cho sự phát triển, mở rộng về quy mô. Vì vậy, khi bạn tăng số lượng developers lên nhiều lần, chiến lược phân nhánh đó vẫn có thể hoạt động tốt.
Trong một số trường hợp, chiến lược phân nhánh này có thể không cần thiết. Nếu bạn có một chiến lược phát triển đơn giản, khi bạn chỉ có duy nhất một branch để họ thực hiện tất cả công việc, thì tất nhiên việc phân nhánh có thể không cần. Nhưng rất có thể, nhóm bạn đang bỏ lỡ việc phát hành các ứng dụng, phần mềm thường xuyên, đang thiếu sự phản ứng nhanh, v.v. Vì vậy, thông thường, bạn nên sử dụng các nhánh (branches) để giúp cho công việc dễ dàng và nhanh chóng.
Nhưng bạn cần phải có quy tắc. Làm thế nào để làm cho toàn bộ quy trình này nhất quán và hiệu quả - vì vậy các quy tắc này nên được mọi thành viên trong đội ngũ phát triển ứng dụng nắm bắt để họ biết cách làm việc trong bất kỳ branch nhất định nào. Và tất nhiên, tất cả các thành viên nên đồng ý, tán thành về các quy tắc đó.
Một trong những quy trình điển hình là quy trình làm việc tập trung (centralized workflow). Giả dụ bạn có một branch duy nhất, và bạn có thể đặt tên cho nó là bất cứ tên nào bạn muốn, có thể là “master”. Với quy trình làm việc này bạn làm mọi thứ theo cách nối tiếp. Các nhà phát triển ứng dụng trong đội thường phải đợi các nhà phát triển khác hoàn thành xong công việc của họ.
Ví dụ, bạn có một mã nguồn (source code). Bạn có nhiệm vụ tạo ra một thứ gì đó và trong khi bạn đang làm việc đó, các thành viên khác không thể thực hiện commit code của họ. Họ chỉ đơn giản là đợi bạn. Về mặt kỹ thuật, họ có thể làm việc trên bản sao code của bạn và merge với code của họ, nhưng đây không phải là cách tiếp cận được khuyến nghị. Vì vậy, thông thường, bạn muốn có nhiều branches để làm việc mà không muốn đụng độ với người khác.
Vì vậy, quy trình tiếp theo, đang được sử dụng phổ biến hơn, được gọi là quy trình làm việc theo nhánh tính năng (feature branch workflow). Thay vì chỉ sử dụng một nhánh chính (master branch/ main branch), về cơ bản bạn tạo một nhánh mới cho một tính năng mới. Và trong khi tính năng đang được phát triển, tất cả các commit sẽ đi vào nhánh riêng biệt đó. Nếu một người muốn kiểm tra tính năng nào đó, họ có thể vào nhánh đó và kiểm tra code.
Và ý tưởng là khi một nhánh tính năng đã được hoàn thành bởi các developers trong đội ngũ, và mọi thứ đã được kiểm duyệt, nhánh đó sẽ được hợp nhất (merge) vào nhánh chính (main branch). Vì vậy, với cách làm này, ưu điểm là luôn giữ được sự ổn định của nhánh chính, bất kì sự thay đổi, bổ sung nào sẽ được kiểm tra kĩ lưỡng trước khi được merge vào main branch để không làm ảnh hưởng tới mọi thứ.
Vì vậy, khi bạn muốn chia sẻ khối lượng công việc, bạn đơn giản chỉ cần đẩy nhánh đó vào kho lưu trữ từ xa (remote repository). Theo cách này, bất kỳ ai khác muốn làm việc trên nhánh đó cũng có thể tham gia. Những người khác có thể nhìn thấy những thay đổi về code của bạn và có thể giúp bạn khắc phục sự cố, v.v.
Phần quan trọng ở đây là giao tiếp. Vì vậy, bạn cần biết có nhiều người làm việc trên nhánh chung với bạn. Bạn muốn chia sẻ những phản hồi, hay muốn có những reviews về code, những sự tán thành từ mọi người để giúp bạn kiểm tra code của mình.
Phần tốt của phương pháp này là bạn có thể có nhiều nhánh độc lập. Vì vậy, nếu bạn tạo một tính năng cầu nối nhánh, chúng có thể chạy song song. Và khi chúng hoàn thành, chúng được hợp nhất vào nhánh chính. Vì vậy, theo cách này, các nhà phát triển không cần phải chờ đợi lẫn nhau. Và nhìn chung, công việc đang tiến hành của họ sẽ không ảnh hưởng đến nhau. Đây là cách tiếp cận tốt được sử dụng khi bạn đang ở giai đoạn đầu với việc phải chuẩn bị rất nhiều tính năng trong ứng dụng của mình. Và vì mỗi nhánh được tách biệt về mặt kỹ thuật trong khi phát triển, nó sẽ không làm chậm sự phát triển.
Cảm ơn bạn đã xem Phần 1 của Chiến lược Phân nhánh. Mời các bạn xem tiếp phần tiếp theo của bài thuyết trình này.
