Một chút nền tảng ở đây - chúng tôi là một nhóm nhỏ (gồm 5) nhà phát triển RAD chịu trách nhiệm phát triển phần mềm nội bộ trong một công ty phi phần mềm lớn. "Phần mềm nội bộ" thay đổi từ ứng dụng .NET trên máy tính để bàn sử dụng máy chủ MSSQL dưới dạng phụ trợ cho các tập lệnh Python chạy trên nền cho các tài liệu và mẫu MS Word - một sở thú công nghệ.
Toàn bộ nhóm bao gồm tất cả những người xung quanh có thể nhận được các yêu cầu từ người dùng, mã hóa nó, kiểm tra và triển khai vào sản xuất. Một khi phần mềm trong quá trình sản xuất nó đang được một nhóm khác chăm sóc nhưng chúng tôi thường dễ dàng can thiệp nếu có sự cố xảy ra.
Tất cả nghe có vẻ tốt, nhưng có một vấn đề - là một nhóm RAD chúng tôi phải phát hành thường xuyên và sẽ không có ngày nào trôi qua mà chúng tôi không phát hành phiên bản mới của một hoặc hai ứng dụng (hoặc có thể là tập lệnh, tài liệu từ được cập nhật , Ứng dụng bảng điều khiển C ++, v.v.) vào sản xuất. Chúng tôi thực hiện thử nghiệm phát triển và cũng liên quan đến người dùng cuối bằng cách cho phép họ chạy phần mềm trong môi trường UAT ...
... Nhưng dù sao thì các con bọ đang xâm nhập vào sản xuất. Người dùng hiểu rằng những lỗi này và sự không ổn định thường xuyên là cái giá họ phải trả để có được thứ họ muốn thực sự nhanh chóng, nhưng đồng thời nó khiến chúng tôi phải suy nghĩ - có lẽ chúng tôi có thể cải thiện sự phát triển của mình hoặc thực hành phát hành để cải thiện tính ổn định của phần mềm và giảm số lượng lỗi chúng tôi giới thiệu khi thêm chức năng mới.
Điều tốt - chúng tôi không thực sự có nhiều quy trình ngay từ đầu, vì vậy thật dễ dàng để bắt đầu cải thiện, điều tồi tệ - là một nhóm RAD nhỏ mà chúng tôi không thực sự có nhiều thời gian và nguồn lực để thực hiện một cái gì đó lớn, nhưng chúng tôi đã suy nghĩ về các sáng kiến sau đây và sẽ hoan nghênh mọi phản hồi, mẹo, gợi ý và đề xuất.
Hiện tại một số ứng dụng đang được phát hành ngay sau khi nhà phát triển thử nghiệm, bỏ qua thử nghiệm chấp nhận của người dùng. Nên ngừng thực hành đó và ngay cả một thay đổi nhỏ cũng phải được kiểm tra bởi người dùng cuối. Mỗi ứng dụng sẽ có một trình kiểm tra beta chuyên dụng được chọn từ người dùng cuối. Chỉ sau khi trình kiểm tra beta có ok-ed, bản phát hành mới được phát hành từ thử nghiệm sang môi trường sản xuất.
Chúng tôi không tiến hành đánh giá mã - nhưng chúng tôi sẽ bắt đầu thực hiện đánh giá mã trước khi một trong số chúng tôi kiểm tra thay đổi. Tôi cũng đã suy nghĩ về một "đánh giá triển khai" - về cơ bản, một trong số các nhà phát triển phải ngồi cạnh người khác xem anh ta / cô ta đang triển khai phần mềm (sao chép nhị phân, cập nhật cấu hình, thêm bảng mới vào cơ sở dữ liệu, v.v.) mất 5-10 phút để không mất nhiều thời gian "xem xét triển khai".
Làm thế nào để bắt chước thời gian rollback khi một bản phát hành mới được chứng minh là có lỗi đủ để rút khỏi sản xuất và được thay thế bằng một phiên bản tốt trước đó. Chúng tôi lưu trữ lịch sử của tất cả các bản phát hành (dưới dạng nhị phân) để giúp dễ dàng quay lại một phiên bản - và mặc dù nó nhanh chóng "ghi đè một nhị phân mới được phát hành với các nhị phân phiên bản trước" nhưng đây vẫn là một quy trình thủ công dễ bị lỗi và yêu cầu đôi khi "điều gì xảy ra nếu rollback sẽ thất bại và sẽ khiến hệ thống không sử dụng được thay vì lỗi".
Đây là nơi chúng tôi hết ý tưởng và chúng tôi muốn nhận phản hồi của bạn về những ý tưởng này và nếu bạn có thể chia sẻ một số lời khuyên cải tiến quy trình phát hành / phát hành đơn giản - điều đó thật tuyệt vời.