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?
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:
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:
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:
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 .
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 ở đó.
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 Rolling
bản phát hành "" (==> Agile).
một Long Term Support
bản phát hành "" (==> Thác nước).