Phát hành sớm/phát hành thường xuyên cho phần mềm thương mại?

Question

Có ai có kinh nghiệm/ví dụ về phát hành sớm/phát hành thường xuyên cho phần mềm thương mại không? Nó có hoạt động không?

Tôi đã suy nghĩ về VMware, nơi họ có rất nhiều phiên bản phát hành giữa mỗi phiên bản chính. Và kinh nghiệm cài đặt là khủng khiếp, đôi khi họ sẽ phá vỡ các máy ảo hiện có và lần khác các công cụ VMware bên trong hệ điều hành khách sẽ hỏng hóc/không cài đặt. Nó thật khủng khiếp.

Và tôi cũng đang nghĩ đến triển khai ClickOnce, vì với ClickOnce khi bạn cập nhật phần mềm, tất cả khách hàng sẽ tự động được thông báo về bản phát hành và với một cú nhấp chuột, chúng được cập nhật lên phiên bản mới. Nếu phần mềm của bạn có lỗi, sau đó họ sẽ tự động "nâng cấp" để có được những lỗi là tốt.

Bạn có kinh nghiệm \ example \ đề xuất để áp dụng bản phát hành sớm/phát hành thường nguyên tắc cho phần mềm thương mại không?

Tôi đang tìm cách áp dụng nó cho một.

Answer 1

Kenny là đúng: nó phụ thuộc.

Chúng tôi làm việc trên phần mềm Doanh nghiệp, nơi khách hàng có thể chạy một dự án 3 tháng bên trong để nâng cấp lên bản phát hành mới. Trong môi trường đó, các bản phát hành thường xuyên làm không phải là hoạt động. Khách hàng sẽ ở lại trên một bản phát hành cũ trong nhiều năm và chúng tôi phải tiếp tục hỗ trợ họ, do đó, nhiều bản phát hành đang hoạt động công việc hỗ trợ nhiều hơn.

Ở mức độ khắc nghiệt khác, tôi đã chạy Google Chrome và đọc về làm mới beta. Tôi đã đi để xem làm thế nào để có được nó và phát hiện ra rằng Chrome đã tự cập nhật. Nếu có bất kỳ thông báo nào tôi đã bỏ lỡ, và điều đó là tốt với tôi.

Câu hỏi chính là làm thế nào phá vỡ bản phát hành mới là.Ví dụ, nếu MS phát hành phiên bản mới của Visual Studio cứ 3 tháng một lần với phiên bản .NET mới, thời gian chạy C, vv thì chúng tôi sẽ dành một phần thời gian của chúng tôi để xử lý việc nâng cấp, điều này sẽ không tốt. Nhưng nếu họ muốn phát hành phiên bản mới của trình phát phương tiện Windows với một số tiện ích con mới phù hợp với tôi - chỉ cần làm cho quy trình tải xuống/cài đặt càng liền mạch càng tốt.

Answer 2

Tôi nghĩ rằng điều đó luôn tùy thuộc vào thị trường hoặc cơ sở khách hàng của bạn. Thay đổi/nâng cấp phần mềm luôn gây đau đớn và thậm chí còn đau đớn hơn trong một số môi trường và công ty. Chu kỳ phát hành nhanh có thể gây gián đoạn. Những gián đoạn này thường mở rộng đến các hoạt động nội bộ của bạn, tùy thuộc vào cách tính năng tốt được quản lý bằng cách tiếp thị/quản lý.

Vì vậy, câu trả lời cổ điển luôn đúng "nó phụ thuộc" trả lời một lần nữa.

Nếu bạn đang thực sự thêm giá trị cho sản phẩm, thì khách hàng đặc biệt là những khách hàng mới sẽ muốn nó. Trường hợp tốt nhất, là loại bỏ nỗi đau thay đổi nâng cấp, như trong, nó hoạt động tương tự, nhưng tốt hơn theo những cách rõ ràng. Tuyệt quá.

Answer 3

Tùy thuộc vào tài nguyên của bạn. Nếu bạn là MicroSoft, bạn có thể sớm phát hành một POS bị lỗi có vần với Sista và dựa vào sức mạnh tiếp thị của bạn để khiến mọi người quên trải nghiệm ban đầu của họ với sản phẩm.

Nếu bạn hy vọng có thể truyền miệng tốt, hãy phát hành phiên bản sớm không phải là một ý tưởng hay (trừ khi bạn dự định thay đổi tên hoặc điều gì đó trước bản phát hành cuối cùng).

Answer 4

Nếu bạn định làm điều này, hãy đảm bảo rằng khi mọi người mua sản phẩm của bạn, họ sẽ được nâng cấp miễn phí lên phiên bản mới trong một năm hoặc một khoảng thời gian khác để họ không cảm thấy bị xé tắt khi một phiên bản mới xuất hiện 2 tháng sau khi họ mua một bản sao. Ngoài ra, đảm bảo rằng bạn hỗ trợ các phiên bản cũ để những người không muốn nâng cấp, chỉ muốn sửa lỗi có thể làm như vậy mà không có nguy cơ vi phạm cài đặt hiện tại của họ với phiên bản mới của phần mềm. Cá nhân tôi nghĩ rằng nó sẽ có nhiều công việc hơn, nhưng bạn sẽ kết thúc với một sản phẩm tốt hơn và bạn sẽ cho phép mọi người sử dụng phần mềm của mình để tận dụng các tính năng mới nhanh hơn nếu họ chọn.

Answer 5

Chú ý đến người đàn ông phía sau bức màn.:
Điều mà phát hành sớm - phát hành thường thực hành muốn bạn làm là phải thất bại sớm và nhanh chóng thay vì ở cuối dự án, khi quá muộn. Nó mang lại cho bạn nhiều cơ hội hơn để hiển thị những gì bạn đang xây dựng cho khách hàng cuối cùng, nhận được phản hồi có giá trị và thích nghi với chi phí thấp hơn. Người trong vai trò 'khách hàng' phải có khả năng dễ dàng có được bản phát hành mới nhất; chơi với nó và phản hồi với phản hồi mang tính xây dựng thường xuyên nhất có thể.

Trong trường hợp bạn đang xây dựng một thứ gì đó quan trọng, ví dụ: một cái gì đó giám sát hoặc điều khiển một nhà máy điện, bạn có thể muốn cẩn thận với thực hành này. Bạn không muốn mọi người dùng ngọn đuốc làm phản hồi cho bản phát hành mới của bạn. Trong những trường hợp như vậy, nó có ý nghĩa để triển khai thường xuyên đến một giường thử nghiệm, xem nó cho X ngày (theo mức độ tin cậy của bạn) và sau đó đi LIVE! Bạn có thể cung cấp cho khách hàng của bạn truy cập vào giường thử nghiệm này để chơi và xây dựng đồng hồ tự tin của mình.
Nếu ứng dụng không quan trọng của nó và bạn đã có hồ sơ lịch sử tốt về các bản phát hành tốt, hãy làm điều gì đó như ClickOnce .. nhưng cũng đảm bảo dễ dàng khôi phục lại cho khách hàng.

Answer 6

Chúng tôi chạy một ứng dụng SaaS, do đó về nguyên tắc nó có thể được cập nhật thường xuyên như chúng tôi muốn.

Mặt khác, trên thực tế, nó chỉ nhận được một vài bản phát hành chính mỗi năm (bản phát hành bản vá nhỏ hơn được đưa ra thường xuyên vài tuần một lần).

Lý do cho điều này là bản phát hành gây gián đoạn cho nhân viên điều hành; đôi khi một phần của ứng dụng cần phải được gỡ xuống. Mỗi thay đổi không phải đối mặt với khách hàng, có rất nhiều công việc đi vào thực tế làm việc phát hành như trái ngược với làm kỹ thuật.

Vì vậy, mặc dù StackOverflow dường như được cập nhật vài ngày một lần, chúng tôi không làm bất cứ điều gì như thế. Một số lỗi có thể được khắc phục trong một ngày, nhưng chúng được sửa trong một bản phát hành tiếp theo mà xuất hiện dưới dạng "tiếng nổ lớn". Hoặc một cái gì đó.