Quy mô nhóm hoặc ứng dụng có ảnh hưởng đến quá trình phát hành không? Vâng, nó phụ thuộc. Hãy tưởng tượng một công ty khởi nghiệp với một nhóm nhỏ. Trong trường hợp này, nhóm thường tạo ra một tính năng và sau đó chỉ phát hành nó. Bây giờ, hãy tưởng tượng một dự án lớn, chẳng hạn như một ứng dụng ngân hàng, với nhiều nhóm làm việc trên đó. Trong trường hợp này, có lẽ nên có một quy trình, chu kỳ phát hành và có thể có một số thủ tục hành chính. Không có điều đó sẽ có sự hỗn loạn. Vì vậy, khi nào thì rõ ràng đã đến lúc thiết lập quy trình như vậy cho ứng dụng của bạn? Trong bài viết này, tôi sẽ chia sẻ kinh nghiệm triển khai Đào tạo phát hành cho ứng dụng Dodo Pizza (Android và iOS) và những vấn đề chúng tôi gặp phải khiến nhóm của chúng tôi triển khai Đào tạo phát hành. Nếu bạn là Trưởng nhóm/Trưởng nhóm công nghệ của một dự án Android hoặc iOS đang phát triển nhanh chóng và bạn chưa quản lý quy trình phát hành, tôi hy vọng rằng kinh nghiệm của chúng tôi sẽ giúp ích cho bạn. Nó đã từng như thế nào Vào năm 2021, chúng tôi đã sử dụng phương pháp Phát triển dựa trên đường trục (TBD) trong nhóm của mình. Chúng tôi đã bao phủ mã bằng các chuyển đổi tính năng, các tác vụ được phân tách và chạy thử nghiệm đơn vị và giao diện người dùng. Các nhánh tính năng của chúng tôi không tồn tại được lâu và chúng tôi đã có CI hoạt động. Quá trình phát hành rất đơn giản: bất cứ ai sẵn sàng triển khai tính năng của mình thì hãy triển khai nó. Kịch bản lý tưởng Đây là đại khái quy trình làm việc tại chi nhánh của chúng tôi trông như thế nào. Một số đội (xám, xanh lam, cam và xanh lục) đã nghiên cứu các tính năng khác nhau. Vì chúng tôi đang làm việc theo TBD nên mỗi tính năng có thể tồn tại qua một số nhánh liên tiếp. Ví dụ: đội xám thực hiện đặc điểm của mình trong 4 bước, đội xanh lam và cam thực hiện đặc điểm của mình trong 1 bước và đội xanh lá cây thực hiện đặc điểm của mình trong 2 bước. Khi một nhóm hoàn thành một tính năng, họ có thể tung ra bản phát hành. Ví dụ: nếu đội xanh hoàn thành một tính năng, họ có thể phát hành. Sau đó, đội màu cam sẽ hoàn thành một tính năng và thực hiện một bản phát hành khác. Có vẻ như lúc đó chúng tôi đã có một dòng chảy hoàn hảo. Nó hoạt động rất tốt ở một mức độ nào đó, nhưng tất cả những điều tốt đẹp đều kết thúc. Đã xảy ra sự cố: khó khăn, đông đúc và không thể đoán trước voi ma mút Vấn đề đầu tiên chúng tôi gặp phải là các bản phát hành bắt đầu tích lũy nhiều tính năng và trở nên quá lớn. Không phải lúc nào các nhóm cũng muốn phát hành tính năng của mình ngay lập tức. Quá trình phát hành và hồi quy tốn nhiều thời gian và mất 3–4 ngày. Vì vậy, nếu tính năng của bạn nhỏ và không khẩn cấp, không phải lúc nào bạn cũng có thể tự mình phát hành nó vì có thể một số nhóm khác sẽ sớm phát hành và nó sẽ được đưa vào bản phát hành đó. Đại khái nó trông như thế này: Đây là một sự sắp xếp khá mong manh, đặc biệt khi số lượng đội bắt đầu tăng lên. Nhiều nhóm đã phát triển nhiều tính năng nhỏ và tổng khối lượng mã mới trong mỗi bản phát hành mới trở nên khổng lồ. Khi ai đó phải phát hành tính năng lớn của mình, họ phải phát hành cả một cùng với nó. con voi ma mút Việc phát hành khổng lồ đã dẫn đến: hồi quy chậm trễ; nguy cơ xảy ra lỗi hồi quy cao hơn; nguy cơ gặp lỗi cao hơn trong quá trình sản xuất. Chúng tôi cần phải làm sao để ngay cả khi đội xanh và cam trong ví dụ không muốn phát hành thì việc phát hành vẫn được thực hiện bằng cách nào đó. Nút thắt cổ chai Mỗi đội là duy nhất và mọi tính năng đều khác nhau. Đôi khi, mọi thứ diễn ra theo cách mà một số đội sẽ hoàn thành các tính năng của mình trong cùng một thời điểm. Trong trường hợp này, có rất nhiều câu “đợi tôi nhé, sáng mai tôi sẽ hợp nhất, tôi hứa!” đi xung quanh. Cuối cùng, những tắc nghẽn như vậy đã dẫn đến: phát hành biến thành voi ma mút; việc phát hành bị trì hoãn ảnh hưởng tiêu cực đến kế hoạch của nhóm phát hành, đặc biệt nếu nhu cầu của mọi người khác được đáp ứng. Chúng tôi cần thực hiện 2 thay đổi quan trọng: Nhóm phát hành không cần phải đợi ai cả; mọi nhóm khác nên biết khi nào dự kiến có bản phát hành tiếp theo. Thiếu khả năng dự đoán Hãy tưởng tượng, đội xanh làm một tính năng nhỏ và mong đội cam sẽ sớm ra mắt. Nhưng đã xảy ra sự cố và đội màu cam cũng không tung ra bản phát hành vì một số vấn đề của riêng họ. Do đó, đội xanh đã nói với doanh nghiệp rằng tính năng này sẽ sớm được đưa vào sản xuất, nhưng hóa ra là chưa đủ sớm. Do đó, không thể dự đoán khi nào tính năng này sẽ được đưa vào sản xuất. Điều này không có nghĩa là đội xanh vô trách nhiệm. Nếu họ có tính năng siêu quan trọng hoặc cấp bách thì tất nhiên họ sẽ tự tung ra. Nhưng trong các trường hợp khác, không có cách nào để biết chính xác khi nào tính năng này sẽ có sẵn cho người dùng. Như bạn có thể đoán, chúng tôi gặp phải những vấn đề như vậy khá thường xuyên. Chúng tôi cần có thể biết chính xác khi nào khách hàng sẽ nhận được một tính năng trong quá trình sản xuất bất kể quy mô hay mức độ khẩn cấp của nó. Cả 3 vấn đề (phát hành khổng lồ, tắc nghẽn và thiếu khả năng dự đoán) đều liên quan chặt chẽ và bổ sung cho nhau. Tuy nhiên, có lẽ điều cơ bản và quan trọng nhất trong số đó là thiếu khả năng dự đoán. Nó tạo ra các vấn đề khác. Thả tàu Chúng tôi đã có đủ; đã đến lúc phải thay đổi. được cho là sẽ giúp chúng tôi làm điều đó. Chuyến tàu phóng thích Thuật ngữ Đào tạo phát hành có nhiều ý nghĩa khác nhau: hoặc một trách quản lý quy trình phát hành. Ở đây, chúng ta sẽ nói về quy trình phát hành theo lịch trình. quy trình phát hành theo lịch trình nhóm chuyên Tôi thích cách Martin Fowler mô tả Release Train trong bài viết “ ” và định nghĩa được (có thể nó cũng thuộc về Martin). Các mô hình quản lý các nhánh mã nguồn Thoughtworks đưa ra trong radar công nghệ của họ Đây là cách chúng tôi đã xác định Release Train cho chính mình: Release Train là quá trình phối hợp phát hành giữa các nhóm. Tất cả các bản phát hành đều diễn ra theo một lịch trình cố định, không phụ thuộc vào việc các tính năng đã sẵn sàng hay chưa. Chuyến tàu không đợi ai cả. Nếu đến trễ thì phải đợi chuyến sau. Hãy chia nhỏ nó bằng một vài ví dụ sử dụng các nhóm được mã hóa màu của chúng tôi. Giải quyết vấn đề voi ma mút Release Train diễn ra theo lịch trình và không phụ thuộc vào người đã sáp nhập những gì vào nhánh chính. Trong ví dụ bên dưới, các tính năng của đội xanh và cam sẽ được ra mắt. Những người còn lại sẽ đợi chuyến tàu tiếp theo. Chúng ta có thể đợi lâu hơn một chút, nhưng sau đó chúng ta sẽ có được một con voi ma mút. Giải quyết tắc nghẽn Đồng thời, Chuyến tàu phát hành giúp chúng tôi lên kế hoạch cho công việc của mình hiệu quả hơn. Giả sử đội xanh ban đầu dự định hoàn thành một tính năng sau. Nhưng vì mọi người đều biết ngày phát hành nên họ có thể sắp xếp lại kế hoạch của mình một chút để hoàn thành sớm tính năng này. Hoặc ngược lại, họ có thể nhận ra rằng mình chắc chắn sẽ không đến kịp chuyến tàu tiếp theo và do đó, họ có thể hoàn thành nhiệm vụ một cách an toàn vì họ biết toàn bộ lịch trình. Trong ví dụ bên dưới, đội xanh muốn tiếp cận bản phát hành và hợp nhất tất cả các thay đổi của họ trước khi phát hành. Nếu không, có thể đã có một nút thắt cổ chai. Quan trọng nhất, Release Train . đã cho chúng tôi khả năng dự đoán theo thiết kế Những ví dụ này có vẻ hiển nhiên đối với một số người, nhưng chúng tôi đã giải quyết được vấn đề khi chúng phát sinh. Khi không có vấn đề gì với các bản phát hành, chúng tôi không bận tâm đến việc sử dụng Release Train. Khi vấn đề chồng chất, chúng tôi nhận ra rằng thời cơ đã đến. Cách triển khai quá trình phát hành trong nhóm của bạn Điều đầu tiên chúng tôi làm là viết một . RFC đề cập đến cả quy trình và tài liệu thiết kế mà sử dụng trước khi họ bắt đầu thực hiện một dự án. Một số sử dụng RFC cụ thể, một số sử dụng ADR và một số chỉ gọi chúng bằng thuật ngữ chung hơn là Design Doc. RFC nhiều công ty Tại Dodo Engineering, chúng tôi sử dụng cả RFC và ADR. Quá trình RFC của chúng tôi trông như thế này: Chúng tôi đã soạn thảo một tài liệu RFC; chúng tôi đã thảo luận về nó trong một nhóm nhỏ, thu thập ý kiến và điều chỉnh; sau đó RFC được truyền đạt đến một nhóm rộng hơn; sau đó chúng tôi thực hiện nó; sau đó, chúng tôi thu thập phản hồi, theo dõi số liệu và đánh giá kết quả. Cấu trúc của tài liệu RFC dành cho Bản phát hành của chúng tôi như sau: mô tả về quy trình Đào tạo Phát hành; những đội nào tham gia, họ đang làm gì; lịch trình sẽ như thế nào; số liệu. Khi soạn thảo RFC, chúng tôi đã dựa vào kinh nghiệm của các công ty khác: SkyScanner Soundcloud Monzo Facebook Triển khai lần đầu Đầu tiên, chúng tôi nghĩ ra quy trình này: phát hành hàng tuần; tạo một nhánh phát hành vào sáng thứ Tư; hoàn thành hồi quy và gửi ứng dụng để xem xét vào thứ Sáu; bắt đầu tung ra bản phát hành vào thứ Hai. Nhóm phát hành: 1 nhà phát triển iOS và 1 Android từ một trong các nhóm tính năng; 2 kỹ sư QA. tạo một nhánh phát hành mới vào thứ Tư; lập lịch trình trước một phần tư, cho biết khi nào đến lượt mỗi đội phát hành. Sau một phần tư, hãy cùng nhau kéo dài lịch trình. Theo sơ đồ, Chuyến tàu phát hành của chúng tôi trông như thế này: Mọi chuyện không diễn ra suôn sẻ Sau một tháng, rõ ràng là mặc dù trải nghiệm đầu tiên rất tuyệt vời, Thực sự rất khó để thực hiện hồi quy hàng tuần và hoàn thành trước thứ Sáu; không có thời gian cho các bản sửa lỗi nóng và đôi khi chúng vẫn xảy ra. Vào năm 2021, thử nghiệm hồi quy của chúng tôi thường mất trung bình 3–4 ngày. Chúng tôi đã cố gắng rút ngắn thời gian xuống còn 2–3 ngày vào năm 2022, nhưng đôi khi, thời gian sẽ vượt quá khung thời gian đó. Chúng tôi tiếp tục đề cập đến các trường hợp hồi quy bằng thử nghiệm e2e, nhưng chúng tôi chưa đạt được phạm vi bao phủ 100%. Chúng tôi có phạm vi bao phủ khoảng 70% và 60% các trường hợp hồi quy trên mỗi nền tảng tương ứng. Bài học rút ra từ điều này là thì việc chạy chu kỳ phát hành hàng tuần có thể sẽ không thoải mái. miễn là bạn phải hoàn thành các bài kiểm tra hồi quy trong vài ngày, Câu trả lời cuối cùng Cuối cùng, chúng tôi đã chuyển sang chu kỳ phát hành 2 tuần và Quá trình phát hành giờ đây trông như thế này: phát hành 2 tuần một lần; tạo một nhánh phát hành vào sáng thứ Tư; thoái lui và gửi ứng dụng để xem xét vào thứ Sáu; bắt đầu tung ra bản phát hành vào thứ Hai. Nhóm phát hành: 1 nhà phát triển iOS và 1 Android từ một trong các nhóm tính năng; 2 kỹ sư QA. lập lịch trình trước một phần tư, cho biết khi nào đến lượt mỗi đội phát hành. Sau một quý, hãy cùng nhau kéo dài lịch trình. tung ra bản phát hành dần dần; thực hiện các bản sửa lỗi nóng nếu cần, ngay bây giờ khi chúng tôi có thời gian dành cho chúng; một tuần sau vào thứ Tư, tạo một nhánh phát hành mới. Quy trình sẽ trông như thế này nếu mọi thứ diễn ra theo đúng kế hoạch: Tất cả trông giống như một chu kỳ hàng tuần ngoại trừ việc còn rất nhiều thời gian cho các bản sửa lỗi tiềm năng. Đây là giao diện của nó trong trường hợp kiểm tra hồi quy mở rộng: Cũng không có gì to tát cả; vẫn còn thời gian cho các bản sửa lỗi nóng. Quy trình mới ảnh hưởng đến khả năng dự đoán như thế nào? Mục tiêu chính của chúng tôi là . Nó có thể được chia thành hai phần: tăng khả năng dự đoán Khi nào ứng dụng sẽ được phát hành; Tính năng của tôi sẽ được đưa vào bản phát hành nào? Chúng tôi đã trả lời câu hỏi “Khi nào sẽ có bản phát hành?” bằng cách thực hiện quy trình Đào tạo phát hành. Bây giờ, mỗi nhóm sẽ có thể trả lời câu hỏi “Tính năng của tôi sẽ xuất hiện ở phiên bản nào?” độc lập tại thời điểm họ lập kế hoạch và đánh giá tính năng. Trước đây, không thể nói chắc chắn vì nhóm khác có thể thực hiện hoặc không thể thực hiện việc phát hành. Giờ đây, mọi chuyện chỉ còn phụ thuộc vào kế hoạch của chính đội đó. Để xác nhận thêm điều này, chúng tôi đã tiến hành khảo sát giữa các nhà phát triển thiết bị di động, QA và người quản lý sản phẩm, trong đó, cùng với các câu hỏi khác, chúng tôi đã hỏi: Khi nào có bản phát hành tiếp theo? (100% trả lời câu hỏi này). Release Train có giúp bạn lên kế hoạch làm việc nhóm không? (75% trả lời tích cực, nhưng một số đã dự đoán hoàn hảo công việc của họ ngay cả khi không có Tàu phát hành). Release Train cũng đã giúp chúng tôi trong việc đóng băng mã và đóng băng phát hành. Chúng tôi đã có một số sự kiện trong số đó, ngoài đêm giao thừa (ví dụ: ngày 1 tháng 9 và một số ngày lễ). Giờ đây, với Release Train, chúng tôi không phải điều chỉnh theo những ngày này bằng cách tạo các nhánh phát hành, thử nghiệm hồi quy, v.v. Phát hành công việc đúng tiến độ; chúng tôi chỉ mở chúng trong các cửa hàng sau. Tác động đến số liệu Ngoài việc giải quyết vấn đề, chúng tôi còn đo lường các số liệu. Chúng ta hãy nhìn vào những cái chính. Thời gian dẫn Số liệu quan trọng đầu tiên mà chúng tôi đo lường là . cam kết về Thời gian thực hiện để phát hành Biểu đồ trông như thế này. Tôi đã đánh dấu điểm khi chúng tôi bắt đầu quá trình Đào tạo phát hành bằng một mũi tên. Biểu đồ cho thấy Thời gian thực hiện đã giảm xuống khoảng sáu ngày. Sáu ngày là thời gian dài hay ngắn? Điểm chuẩn của Google Có , nhưng nó chủ yếu dành cho phần phụ trợ. Trên quy mô của họ, họ phân biệt các nhóm sau: điểm chuẩn từ Google cho số liệu này Ưu tú: chưa đầy một giờ Cao: 1 giờ đến 1 tuần Trung bình: 1 tuần đến 6 tháng Thấp: 6 tháng trở lên Tôi tin rằng đối với các ứng dụng di động tiêu chuẩn, thời gian thực hiện lý tưởng nhất là bằng một nửa thời gian của chu kỳ phát hành. Điều này tương đương với việc hợp nhất một nhiệm vụ vào nhánh chính mỗi ngày. Điều này cho biết, . nếu chu kỳ phát hành là 14 ngày thì Thời gian thực hiện nên nhắm đến là 7 ngày Lỗi mỗi lần hồi quy Một số liệu khác mà chúng tôi theo dõi là số lượng lỗi trên mỗi lần hồi quy. Nó mô tả mức độ ổn định của ứng cử viên phát hành. Nếu bản phát hành trước đó đã lâu thì có lẽ chúng ta đã tạo ra rất nhiều mã mới có khả năng chứa nhiều lỗi và chúng ta có thể dành nhiều thời gian hơn cho việc hồi quy và sửa lỗi. Tại một thời điểm, số liệu này có tới ba lỗi. Những con số cụ thể không quá quan trọng nhưng nhìn chung, bạn có thể thấy xu hướng đã đi xuống. Nhiều số liệu hơn Tôi sẽ thảo luận ngắn gọn về những số liệu nào cũng được giám sát như một phần của Khóa đào tạo phát hành. Không có sự cố. Chúng tôi luôn theo dõi số liệu này. Có giả thuyết cho rằng nó sẽ giảm do chúng tôi cố gắng điều chỉnh hồi quy vào một khung thời gian chặt chẽ hơn. Vâng, không có sự sụt giảm nào xảy ra. Chúng tôi tự hỏi liệu việc phát hành thường xuyên (hàng tuần) có ảnh hưởng đến việc rời bỏ khách hàng và xóa ứng dụng hay không. Kết quả là chúng tôi không phát hiện thấy tác động nào. Thực hiện, cải tiến Chúng tôi thích quy trình hiện tại vì chúng tôi nghĩ rằng nó đã đạt được mục tiêu. Chúng tôi cũng biết cách cải thiện nó hơn nữa: Chúng tôi tiếp tục nỗ lực tự động hóa quá trình hồi quy để làm cho quá trình này đơn giản và nhanh hơn. Cho đến nay, chúng tôi đã bỏ qua phần tự động hóa công việc (các tập lệnh để phân nhánh), nhưng đây cũng sẽ là một điểm phát triển tuyệt vời trong tương lai. Ứng dụng của chúng tôi hoạt động ở 20 quốc gia và chúng tôi cần dịch ứng dụng sang nhiều ngôn ngữ khác nhau. Có một dịch vụ nội bộ cho việc này, nhưng các nhà phát triển vẫn phải tham gia vào quá trình này một cách thủ công trước khi phát hành. Tự động hóa quá trình này có thể cải thiện chu kỳ phát hành hơn nữa. Bản tóm tắt Mặc dù chúng tôi còn tương đối nhỏ nhưng chúng tôi không cần Tàu phát hành. Khi đối mặt với thực tế là chúng tôi không thể dự đoán các bản phát hành, quy mô và số lượng của chúng, chúng tôi đã quyết định triển khai Đào tạo phát hành. Lúc đầu, chúng tôi thử chu kỳ phát hành hàng tuần, nhưng do quá trình hồi quy tốn thời gian nên chúng tôi phải chuyển sang chu kỳ phát hành hai tuần. Chúng tôi đã sống như vậy kể từ đó. Bây giờ, chúng tôi có khả năng dự đoán về các bản phát hành và các số liệu cho thấy động lực tích cực. Chúng tôi có kế hoạch tăng mức độ bao phủ của các trường hợp hồi quy bằng thử nghiệm e2e, tự động hóa quy trình làm việc với các nhánh và tối ưu hóa quy trình dịch. Tôi hy vọng bài viết này và kinh nghiệm của chúng tôi sẽ giúp ích cho bạn, đặc biệt nếu bạn đã gặp phải những vấn đề tương tự và chúng khiến bạn phải suy nghĩ về quá trình phát hành. Cảm ơn bạn rất nhiều vì đã đọc bài viết của tôi. Tôi hy vọng bạn thích nó. Nếu bạn có bất kỳ câu hỏi hoặc đề xuất nào, hãy gửi cho tôi một dòng trong phần bình luận và tôi chắc chắn sẽ đọc nó! Và . Thông thường, tôi đăng bài về phát triển Android và công nghệ phần mềm nói chung. theo dõi tôi trên Twitter Cũng được xuất bản ở đây
