Những khía cạnh Quản lý phát hành nào giúp giải thích sự khác biệt giữa Waterfall và Agile?


12

Khi giải thích DevOps cho ai đó, một câu hỏi xuất hiện như sau:

Quản lý phát hành sử dụng phương pháp Agile khác với Waterfall như thế nào?

Vì vậy, loại tiêu chí nào bạn có thể sử dụng để giải thích những khác biệt này cho khán giả như vậy?

Câu trả lời:


11

IMO DevOps là văn hóa, giống như Agile (không chọn phương pháp nhanh.) Do đó, bạn không "làm" DevOps.

Bạn "làm" một phương pháp phát hành được gọi là Phân phối liên tục như là một phần của Văn hóa DevOps. (tiết lộ đầy đủ, tôi không nghĩ rằng tôi đã từng gọi CD là một phương pháp phát hành trước đây, nhưng trong trạng thái phản lực của tôi, tôi nghĩ rằng nó hoạt động)

Nếu bạn sẽ mua cái đó, thì đây là định nghĩa về Giao hàng liên tục từ một trong những người đã viết cuốn sách có cùng tiêu đề, Jez Humble .

Phân phối liên tục là khả năng nhận được các thay đổi của tất cả các loại, bao gồm các tính năng mới, thay đổi cấu hình, sửa lỗi và thử nghiệm, sản xuất, hoặc vào tay người dùng, một cách an toàn và nhanh chóng.

Mục tiêu của chúng tôi là thực hiện triển khai, cho dù là một hệ thống phân tán quy mô lớn, môi trường sản xuất phức tạp, hệ thống nhúng hay ứng dụng có thể dự đoán được, các công việc thường xuyên có thể được thực hiện theo yêu cầu.

Chúng tôi đạt được tất cả điều này bằng cách đảm bảo mã của chúng tôi luôn ở trạng thái có thể triển khai, ngay cả khi đối mặt với các nhóm hàng ngàn nhà phát triển thực hiện thay đổi hàng ngày. Do đó, chúng tôi loại bỏ hoàn toàn các giai đoạn tích hợp, thử nghiệm và làm cứng mà theo truyền thống là theo dev dev dev, cũng như đóng băng mã.

Vì vậy, sau đó, bạn có thể làm việc theo phương pháp Agile, có phần mềm bạn có thể trình diễn cho doanh nghiệp, đảm bảo bạn đang thực hiện kiểm tra tự động đúng cách, phản ứng tốt với sự thay đổi và tất cả những điều làm cho nó tốt hơn thác nước. Tất cả quá thường xuyên không có nghĩa là bạn thực sự có thể triển khai nó vào sản xuất.

Bạn kết thúc với một cái gì đó như thế này: nhanh nhẹn mà không cần cd

Vì vậy, phần mềm sẽ (có thể) sẽ tốt hơn khi bạn hoàn thành sau đó nếu bạn không có cách tiếp cận lặp nào đó, nhưng bạn không thực sự biết vì người dùng thực sự chưa từng thấy nó.

Những gì bạn thực sự muốn là một cái gì đó trông giống như thế này:

nhập mô tả hình ảnh ở đây

Mỗi lần lặp lại, một cái gì đó được triển khai để sản xuất. Vì vậy, phần mềm được triển khai . Nếu bạn quyết định để tạo ra tải, mở lên máy chủ web, hoặc tuy nhiên bạn sẽ có được phần mềm vào tay của người sử dụng nó phát hành .

Cái quái gì thế!? Tôi hỏi về DevOps! Không ai hỏi về việc giao hàng liên tục !!

Vậy DevOps phải làm gì với điều này?

Rất, rất khó (gần như không thể) để thực sự có phần mềm của bạn ở trạng thái bạn có thể triển khai phần mềm bất cứ khi nào bạn muốn trừ khi nhóm đó làm việc trong văn hóa DevOps. Một nền văn hóa nơi Quản trị viên hệ thống, DBA, SRE, Nhân viên bảo mật, Nhà phát triển, QAs, v.v., v.v., tất cả đều là một phần của một nhóm duy nhất và không phải là một phần của một tổ chức có bàn giao.

Lưu ý :

Về một phần của một bình luận được đăng lên câu trả lời này, giống như vậy:

Về phần mềm "... của bạn ở trạng thái bạn có thể triển khai phần mềm bất cứ khi nào bạn muốn ...": điều đó nhắc tôi về phần mềm "phi công tự động" (trong máy bay) ... Câu hỏi yêu thích của tôi về điều đó: " Hãy tưởng tượng một bản cập nhật được áp dụng cho phần mềm như vậy ... Bạn cảm thấy thế nào khi thực hiện điều đó ... Trong khi bạn ở trên tàu? ".

Tôi thích câu hỏi đó (in đậm, trong trích dẫn ở trên)! Ý tưởng của "nó đã thực sự sẵn sàng?" là một cái gì đó tôi luôn luôn quan tâm - blog . IMO điều quan trọng là bạn tự tin vào bảo mật, hiệu suất và các bài kiểm tra "phụ" quá thường xuyên khác để thực hành CD. Các tính năng được thực hiện khi chúng được thực hiện, nhưng tin tặc luôn ở đó.


Cảm ơn bạn vì quan điểm / câu trả lời thú vị của bạn (và hình ảnh sáng bóng ...). Tôi phải thừa nhận tôi chưa bao giờ nghe về thuật ngữ Phương pháp phát hành , mặc dù Quản lý phát hành là thứ tôi khá quen thuộc (trong hơn 2 thập kỷ ...). Về phần mềm "... của bạn ở trạng thái bạn có thể triển khai phần mềm bất cứ khi nào bạn muốn ..." (kết hợp với "jetlagged"): nhắc nhở tôi về phần mềm "phi công tự động" (trong máy bay) ... câu hỏi về điều đó: " Hãy tưởng tượng một bản cập nhật được áp dụng cho phần mềm như vậy ... Bạn cảm thấy thế nào khi thực hiện điều đó ... Trong khi bạn đang ở trên tàu? ".
Pierre.Vriens

1
Tôi thích câu hỏi đó! Ý tưởng của "nó đã thực sự sẵn sàng?" là một cái gì đó tôi luôn luôn quan tâm - blog . IMO điều quan trọng là bạn tự tin vào bảo mật, hiệu suất và các bài kiểm tra "phụ" quá thường xuyên khác để thực hành CD. Các tính năng được thực hiện khi chúng được thực hiện, nhưng tin tặc luôn ở đó.
Ken Mugrage

1
Tôi đã đề cập đến - "Hãy tưởng tượng một bản cập nhật được áp dụng cho phần mềm như vậy ... Bạn cảm thấy thế nào khi thực hiện điều đó ... Trong khi bạn đang ở trên tàu?"
Ken Mugrage

Và xin vui lòng chỉnh sửa đi, tôi là một n00b ở đây :)
Ken Mugrage

Vui lòng xem lại chỉnh sửa được đề xuất của tôi, để tích hợp nhận xét thú vị của bạn. Nếu bạn không thích nó, chỉ cần thực hiện khôi phục lại phiên bản trước (liên kết nằm trong "phiên bản") và / hoặc cải thiện / mở rộng thêm nếu muốn. Đoán xem, có vẻ như "inflight" một số "quyền" của tôi đã bị thay đổi ... có vẻ như tôi đã có quá nhiều đại diện ở đây để vẫn cần "phê duyệt" cho các chỉnh sửa được đề xuất như vậy ... thật may mắn cho chúng tôi đây chỉ là một số SE- phần mềm (không phải là bản cập nhật được đề xuất cho một số tuyến của chuyến bay mà không có sự chấp thuận trước từ kiểm soát không lưu ...). Oeps 2 (hiệu chỉnh): nó đã được chấp thuận ở tốc độ ánh sáng ...
Pierre.Vriens

2

Không chắc có ai khác không, nhưng đây là những tiêu chí tôi sử dụng:

+-------------------+-----------+-----------+
! Criteria          ! Agile     ! Waterfall !
+-------------------+-----------+-----------+
! Release Events    ! Frequent  ! Rare      !
! Risk              ! Less      ! High      !
! Required Effort   ! Smoother  ! Peaks     !
! Volume of changes ! Small     ! Huge      !
+-------------------+-----------+-----------+

Và nếu bạn thực sự muốn tự mình trải nghiệm sự khác biệt khi là người dùng một số phần mềm, thì hãy nghĩ đến việc sử dụng một số phần mềm (như bản phân phối Linux), nơi bạn có lựa chọn giữa việc sử dụng một trong những bản phát hành đó:

  • một Rollingbản phát hành "" (==> Agile).

  • một Long Term Supportbản phát hành "" (==> Thác nước).


1
Ví dụ về Linux có thể không truyền cảm hứng lắm :) Cá nhân tôi không thích các bản phát hành vì: 1. mức chất lượng và 2. những thay đổi khá mất tập trung (tôi thích tập trung vào công việc của mình hơn là vào linux tôi đang sử dụng cho công việc). Vì vậy, tôi sử dụng thuật ngữ dài (est) (thường vượt qua EOL của họ) và chỉ tập trung vào một bản cập nhật lớn cứ sau 2-3 năm một lần. Trừ khi điều này chỉ là gia tăng sự thay đổi do lão hóa? :)
Dan Cornilescu

@DanCornilescu Tôi đã sử dụng ví dụ Linux này bởi vì tôi nghĩ rằng đây là một ví dụ cực đoan về khía cạnh "phát hành" (nghĩa là tần suất phát hành) cho cả hai phương pháp. Mặc dù "cá nhân" tôi hoàn toàn đồng ý với việc bạn không thích phát hành, vì những lý do tương tự như bạn đã đề cập.
Pierre.Vriens
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.