Khi nói đến việc cung cấp một scrum, mọi người thường mong đợi việc phát hành sẽ được thực hiện sau khi sprint kết thúc. Điều này có nghĩa là ngay sau khi demo thành công cho khách hàng.
Nhưng tôi luôn tự hỏi làm sao nó lại có thể tự động chờ đợi như vậy. Đặc biệt là khi bạn xem xét các hành động có thể xảy ra sau đây phải xảy ra trước hoặc bên cạnh nó.
- Phát triển và hoàn thiện tất cả các story trong sprint. Một số có thể được hoàn thành sớm, nhưng hầu hết các story đều được hoàn thành ngay trước khi kết thúc sprint. Có lẽ ngay cả sau khi trình bày bản demo sẽ được mở ở đây.
- Thực hiện tất cả các thử nghiệm nội dung chạy nước rút theo kế hoạch để đảm bảo rằng mã được phát hành đã sẵn sàng để sản xuất.
- Cập nhật các lỗi được phát hiện và khắc phục kịp thời trước khi phát hành.
- Đảm bảo quy trình triển khai được cập nhật với nội dung mới nhất và bản thân quy trình triển khai đó đáng tin cậy để thực thi.
- Chạy quy trình trên tất cả các môi trường có liên quan để đưa chúng đến trạng thái mới nhất từ cả góc độ mã và dữ liệu.
- Chuẩn bị ghi chú phát hành và thông báo cho khách hàng về tác động của bản phát hành cũng như chính xác những gì sẽ thay đổi tiếp theo.
- Đồng bộ hóa với các nhóm scrum đồng thời khác khi cần để đảm bảo rằng nội dung phụ thuộc được phát hành đồng thời. Không được thiếu thứ gì để nội dung phát hành hoạt động như mong đợi.
- Ngoài ra, hãy trải qua tất cả các buổi lễ scrum. Không chỉ liên quan đến sprint hiện tại mà còn liên quan đến những thứ tập trung vào sprint tiếp theo (ví dụ: các phiên cải thiện câu chuyện).
Bây giờ hãy tưởng tượng rằng cuộc chạy nước rút kéo dài hai tuần.
Bản thân việc sa thải cũng đòi hỏi thời gian và con người. Nhưng nó không thể mất quá nhiều thời gian. Ngay sau ngày cuối cùng của lần chạy nước rút là ngày đầu tiên của lần chạy nước rút tiếp theo và vòng tròn lại bắt đầu lại.
Việc chờ đợi được giải phóng sau mỗi lần chạy nước rút vẫn trông rất tự động phải không?
Làm chậm quá trình xử lý nội dung của bạn
Nếu tất cả các quy trình trong một lần chạy nước rút đều được tự động hóa, thì có thể “bóp cò” và cài đặt phiên bản mã mới nhất vào sản xuất vào cuối mỗi lần chạy nước rút. Vấn đề là tôi chưa bao giờ trải qua trạng thái hoàn hảo như vậy của một nhóm scrum.
Nếu điều này xảy ra với một số công ty tư nhân nhỏ, tôi thực sự ghen tị với họ. Nhưng thực tế trong thế giới doanh nghiệp là một nhóm scrum sẽ không đạt đến mức độ trưởng thành đó. Ngược lại, quy trình phát hành thường gắn liền với các hoạt động tốn thời gian bao trùm hầu hết các lần chạy nước rút tiếp theo, ảnh hưởng đến lần chạy nước rút đó từ góc độ nội dung và tất cả các số liệu. Việc giải phóng chỉ đơn giản là một hành động căng thẳng khiến không ai trong nhóm cảm thấy vui vẻ.
Vì vậy, tôi đã khám phá ra tình huống tốt nhất tiếp theo để xử lý các bản phát hành.
Kết luận là mỗi giây chạy nước rút phải là một lần chạy nước rút giải phóng. Đây là ý nghĩa của nó.
Một phiên bản mã riêng cho phiên bản tiếp theo
Đó là về việc hỗ trợ các nhánh riêng biệt trong kho GIT. Có nhiều cách để tiếp cận cùng một vấn đề và tất cả chúng đều có thể thành công. Nhưng vì mục đích của bài viết này, tôi sẽ giữ mọi thứ đơn giản để chứng minh cách tiếp cận và tác động của nó.
Để giảm thiểu tác động của quá trình phát triển đang diễn ra, điều quan trọng là nội dung của phiên bản tiếp theo phải được tách thành một nhánh riêng. Hãy gọi nó là Đội Giải tán. Điều này sẽ giải quyết các vấn đề sau:
- Nhóm phát triển có thể tiếp tục và kết nối với những câu chuyện mới từ nhánh chính mà không bị gián đoạn.
- Không có nguy cơ nội dung của bản phát hành sẽ bị ảnh hưởng bởi những sửa đổi không mong muốn đối với mã của nhóm scrum.
- Hoạt động thử nghiệm có thể được thực hiện trong một không gian biệt lập. Chỉ những thay đổi cần thiết để giải bài kiểm tra mới được thực hiện ở đây.
- Vì quy trình phát hành sẽ chỉ triển khai nội dung từ nhánh phát hành sang sản xuất nên chúng tôi có quy trình minh bạch và toàn quyền kiểm soát nội dung sẽ được phát hành. Không thể xảy ra trường hợp một số cam kết không mong muốn trong nhánh Git phá vỡ mã đã được kiểm tra.
Vì vậy, chỉ cần đặt nội dung của phiên bản tiếp theo sang một bên và để nó ở trạng thái ổn định, sẵn sàng phát hành.
Phát hành thời gian để chúng chạy nhiều lần
Tôi từ bỏ tham vọng giải phóng sau mỗi lần chạy nước rút. Rõ ràng là điều này sẽ không hiệu quả. Ít nhất là không có tác dụng phụ như:
- ảnh hưởng đến nội dung phát triển của sprint tiếp theo,
- không có khả năng ổn định nội dung của vấn đề,
- bù đắp cho tất cả các hoạt động thử nghiệm cần thiết, v.v.
Vì vậy, mục tiêu là tạo ra bản phát hành vào cuối mỗi lần chạy nước rút khác. Điều này có nghĩa như sau:
- Vấn đề sẽ luôn chứa các câu chuyện từ hai lần chạy nước rút đã hoàn thành gần đây nhất. Vì bản phát hành đang được thực thi trong lần chạy nước rút hiện tại (đang hoạt động) nên nội dung chạy nước rút này chưa được đưa vào bản phát hành.
- Có một khoảng thời gian chạy nước rút để hoàn thành việc kiểm tra cần thiết và sửa lỗi.
- Chủ sở hữu bản phát hành có đủ thời gian để thu thập thông tin liên quan đến bản phát hành (trường hợp thử nghiệm, ghi chú phát hành, v.v.) trong một lần chạy nước rút không phát hành. Bằng cách này, về cơ bản họ có thể tự chạy trong khi những người còn lại trong nhóm phát triển làm việc với những câu chuyện mới.
- Nếu phát hiện lỗi, chủ sở hữu bản phát hành có thể nhanh chóng kết nối với nhà phát triển cụ thể để khắc phục sự cố và quay lại nội dung chạy nước rút hiện tại. Do đó, luôn phải có một tỷ lệ phần trăm thời gian nhất định được phân bổ theo khả năng của nhóm để hỗ trợ sửa lỗi này. Bạn có thể khám phá chính xác bao nhiêu trong thời gian.
Rõ ràng là người dùng sẽ không nhận được nội dung chạy nước rút mới nhất trong phiên bản mới nhất. Nhưng với thời gian nó sẽ không thành vấn đề. Và do đó, họ sẽ nhận được hai lần chạy nước rút nội dung với mỗi lần phát hành tiếp theo, sau mỗi lần chạy nước rút thứ hai.
Đây có vẻ như là một sự thỏa hiệp tốt giữa sự hài lòng của việc giao hàng nhanh chóng và việc duy trì các hoạt động scrum mà không bị gián đoạn đáng kể.
Thực hiện triển khai phát hành
Sau khi bạn đã hoàn thành thành công việc kiểm tra, sửa lỗi và sẵn sàng cho quy trình, việc triển khai quy trình sản xuất và hoàn tất việc phát hành sang sản xuất là một quy trình khá đơn giản.
Vì nó được triển khai từ một nhánh độc lập nên về cơ bản nó có thể là một hoạt động không được chú ý và vô hình. Không ai cần biết. Trong trường hợp đó, đây là cách triển khai bản phát hành tốt nhất có thể.
Điều kiện tiên quyết là xây dựng một quy trình DevOps tự động mạnh mẽ. Nó không chỉ được sử dụng để triển khai trong môi trường sản xuất mà còn trong tất cả các môi trường cấp thấp khác. Điều này có thể bao gồm phát triển, hộp cát, thử nghiệm, QA, môi trường hiệu suất, v.v. Đây phải là một cú nhấp chuột để triển khai tất cả các giải pháp cho mọi môi trường.
Việc giải phóng không nên là một điểm đau đớn hoặc căng thẳng. Hoặc một cơn ác mộng mà ai cũng sợ hãi và đã chuẩn bị cho ngày này suốt một tuần. Không – thay vào đó, nếu không ai để ý đến điều đó thì đó là dấu hiệu tốt nhất của việc phát hành thành công.
Liên kết lại nhánh phát hành với nhánh phát triển
Nhánh phát hành hiện chứa nội dung đặc biệt không có trong nhánh phát triển liên tục thông thường. Điều này liên quan đến tất cả các bản sửa lỗi đã được triển khai trong thời gian thử nghiệm. Nội dung này cần được đưa lại vào nhánh phát triển để đảm bảo rằng các bản sửa lỗi vẫn ở đó ngay cả sau bản phát hành tiếp theo.
Tại thời điểm này, nhánh phát hành mới nhất đóng vai trò là mã sản xuất dự phòng sẵn sàng để triển khai lại. Nếu một vấn đề khẩn cấp, có mức độ ưu tiên cao cần được giải quyết ngay sau khi triển khai sản xuất thì có thể sử dụng nhánh này. Thật dễ dàng để lấy mã này và thực hiện sửa lỗi bên trong. Nó vẫn là bản sao chính xác của mã sản xuất hiện tại và không có nội dung mới, chưa được phát hành.
Cuối cùng, khi giai đoạn thử nghiệm mới bắt đầu, nhánh phát hành trước đó có thể bị xóa và thay thế bằng nhánh mới. Cái mới được tạo lại dưới dạng bản sao từ nhánh phát triển hiện tại.
Thiết lập các bản phát hành thường xuyên
Và bây giờ chúng tôi đã có nó 😀 – một quá trình vững chắc hướng tới việc ra mắt. Điều duy nhất còn thiếu là sự cam kết đều đặn. Trong trường hợp này, sau mỗi giây chạy nước rút.
Bằng cách duy trì nó thường xuyên, chúng tôi thực sự đang đặt nền móng để đạt được mục tiêu này dễ dàng hơn, chủ yếu là vì:
- Nếu bản phát hành diễn ra sau một thời gian ngắn thì sẽ không có nhiều nội dung mới được cài đặt trong môi trường sản xuất. Sự gia tăng là nhỏ và được coi là ổn định.
- Bây giờ có quá nhiều nội dung mới đồng nghĩa với việc không có nhiều thử nghiệm và phát triển trường hợp thử nghiệm. Ít giao tiếp hơn, kêu gọi sự đồng ý và hợp tác với các bên liên quan về những gì tất cả đều cần xác nhận lại. Họ cũng sẽ đồng ý rằng chưa được bao lâu kể từ lần phát hành cuối cùng. Vì vậy, hành động này ít được coi trọng hơn.
- Nhóm sẽ quen với chu kỳ này; theo thời gian, nó sẽ trở thành một phần tự nhiên của nhóm.
- Một tác dụng phụ thường là làm mới dữ liệu trong môi trường phát triển và thử nghiệm. Dù sao thì điều này cũng cần thiết cho mỗi chu kỳ thử nghiệm mới. Vì vậy, nó sẽ không chỉ là một hoạt động theo lịch trình khác để thực hiện. Đúng hơn là một hành động đã là một phần của một quy trình đã được thiết lập. Sự thay đổi quan điểm này có tác động rất lớn đến bầu không khí trong nhóm. Sẽ không ai tin điều đó.
Ứng dụng
Chương này kết thúc các bài viết trước đây của tôi về vòng đời scrum. Nó cũng nói về những gì đã có hiệu quả trong cuộc sống thực.
Thường thì các nhóm bắt đầu trở nên nhanh nhẹn và làm rất nhiều việc sai. Sau đó, cuối cùng họ tiến hóa và bắt đầu làm những điều khác biệt. Loạt bài này có thể giúp một số người trong số họ thực hiện thay đổi đó nhanh hơn.
Cách tiếp cận phát hành này không phải là cách khả thi duy nhất và cũng không phải là không có vấn đề. Những điều này vẫn sẽ tồn tại và các đội phải đối phó với chúng. Sau đó sửa lại những gì có thể và quên đi những gì không có ý nghĩa.
Nhưng theo những gì tôi biết, cách tiếp cận này tuy đơn giản nhưng đã chứng minh rằng sự thay đổi là có thể thực hiện được. Từ những lần chạy nước rút hỗn loạn, không thể đoán trước cho đến việc phân phối ổn định hơn với các bản phát hành thường xuyên mà bạn có thể dựa vào và lập kế hoạch. Và nó không đòi hỏi một phương pháp đặc biệt, rất phức tạp – các quy tắc đơn giản và sẵn sàng tuân theo kế hoạch là đủ.
