|
DevOpsDevOps (kết hợp của cụm từ tiếng Anh "software DEVelopment" và "information technology OPerationS") là một thuật ngữ để chỉ một tập hợp các hành động trong đó nhấn mạnh sự hợp tác và trao đổi thông tin của các lập trình viên và chuyên viên tin học khi cùng làm việc để tự động hóa quá trình chuyển giao sản phẩm phần mềm và thay đổi kiến trúc hệ thống.[1][2] Điều này nhằm thiết lập một nền văn hóa và môi trường nơi mà việc build (biên dịch phần mềm), kiểm tra, và phát hành phần mềm có thể xảy ra nhanh chóng, thường xuyên, và đáng tin cậy hơn.[3][4][5] Tổng quan Theo truyền thống, các tổ chức có sự phân chia chức năng phòng ban rất hiếm khi có một phòng ban giữ chức năng tích hợp cả chức năng của phòng IT. Nhưng DevOps đề xướng một phương thức mới giúp trao đổi và hợp tác giữa các phòng ban phát triển phần mềm, quản lý chất lượng phần mềm (QA) và phòng IT.[6] Trong một số tổ chức, sự hợp tác này lại được thực hiện bằng cách "nhúng" chuyên viên IT vào trong nhóm phát triển phần mềm, do đó tạo thành một đội đa chức năng – điều này có thể cũng được kết hợp với ma trận quản lý. Lịch sửTại hội nghị Agile năm 2008, Andrew Clay Shafer và Patrick Debois đã thảo luận về "cơ sở hạ tầng Agile".[7] Thuật ngữ DevOps được phổ biến thông qua một loạt các series "devopsdays", bắt đầu từ năm 2009 ở Bỉ.[8] Kể từ đó, đã có các hội nghị devopsdays được tổ chức ở nhiều quốc gia trên toàn thế giới.[9] Chuỗi công cụ DevOps (DevOps toolchain) Bởi vì DevOps là một sự thay đổi về văn hóa và hợp tác (giữa các nhóm phát triển, điều hành và kiểm thử phần mềm) nên không có duy nhất một "công cụ DevOps" mà thay vào đó là chuỗi công cụ DevOps bao gồm nhiều công cụ.[10] Thông thường, chuỗi công cụ DevOps dùng để làm công việc phù hợp với một hoặc nhiều thể loại, điều này phản ánh các khía cạnh chủ chốt của sự phát triển phần mềm và quá trình phân phối phần mềm:[11][12]
Mặc dù có rất nhiều công cụ, nhưng trong một số tổ chức, chỉ một số loại trong đó là cần thiết để thiết lập chuỗi công cụ DevOps. Một số nơi cố gắng xác định những công cụ cơ bản để có thể tìm trong các danh mục có sẵn.[13] Các công cụ như Docker (container), Jenkins (Tích hợp liên tục), Puppet (Mã nguồn như là cơ sở hạ tầng - IaC) và Vagrant (nền tảng ảo hóa)—trong số nhiều thứ khác—thường được sử dụng và thảo luận khi nói về chuỗi công cụ DevOps.[14] Mối quan hệ với Agile và Phân phối Liên tục (Continous delivery)AgileAgile (Phát triển phầm mềm linh hoạt) và DevOps tương tự nhau, nhưng trong khi Agile đại diện cho một sự thay đổi trong suy nghĩ và thực hành (dẫn đến sự thay đổi tổ chức), DevOps có trọng tâm nhiều hơn về việc thực hiện thay đổi có tổ chức để đạt được mục tiêu của mình. Sự cần thiết DevOps được sinh ra từ sự phổ biến của phát triển phần mềm linh hoạt (Agile), là xu hướng dẫn đến sự gia tăng số lượng các bản phát hành. Một mục tiêu của DevOps là thiết lập một môi trường nơi phát hành nhiều ứng dụng đáng tin cậy hơn, nhanh hơn và thường xuyên hơn. Các nhà quản lý phát hành bắt đầu sử dụng các công cụ (như các công cụ phát hành ứng dụng tự động và tích hợp liên tục) để giúp thực hiện mục tiêu nay— bằng cách làm gì đó thông qua việc tiếp cận quy trình phân phối liên tục.[10] Phân phối Liên tục (Continuous delivery)Phân phối liên tục (CD) và DevOps tương tự nhau ở ý nghĩa (và thường pha trộn vào nhau), nhưng chúng là hai khái niệm khác nhau:[15]
Chúng có chung mục tiêu cuối cùng, và thường sử dụng kết hợp, để đạt được chúng. DevOps và Phân phối liên tục chia sẻ một nền tảng trong các phương pháp Agile và Lean: các thay đổi nhỏ và nhanh chóng tập trung vào việc mang lại giá trị cho người dùng cuối. Chúng đang được truyền đạt tốt và hợp tác trong nội bộ, do đó giúp đạt được thời gian ra thị trường nhanh, giảm rủi ro. Mục tiêuCác mục tiêu cụ thể của DevOps là để kết nối toàn bộ pipeline (đường ống) phân phối. Chúng bao gồm việc thường xuyên cải tiến sự triển khai, có thể dẫn đến:
Tiếp cận DevOps giúp đơn giản hóa quy trình, nâng cao khả năng lập trình và năng động.[16] DevOps nhằm mục đích để tối đa hóa dự đoán, hiệu quả, an ninh và bảo trì các quá trình hoạt động. Rất thường xuyên, tự động hóa hỗ trợ mục tiêu này. Lợi ích của DevOpsCác công ty áp dụng DevOps cho thấy họ đạt được một số lợi ích đáng chú ý như: rút ngắn thời gian đưa sản phẩm ra thị trường, nâng cao sự hài lòng của khách hàng, chất lượng sản phẩm tốt hơn, phát hành nhiều sản phẩm đáng tin cậy hơn, nâng cao hiệu suất và hiệu năng,..[15] Tuy nhiên, một nghiên cứu phát hành vào tháng giêng 2017 bởi F5 dựa trên gần 2,200 giám đốc điều hành IT và chuyên gia ngành công nghiệp cho thấy rằng chỉ có một phần năm số người khảo sát nghĩ rằng DevOps đã có một chiến lược tác động vào tổ chức của họ mặc dù gia tăng trong việc sử dụng. Cùng một nghiên cứu cho thấy rằng chỉ 17% xác định DevOps như chìa khóa phát triển, xếp dưới phần mềm dạng dịch vụ (42%), dữ liệu lớn (41%) và cloud dạng dịch vụ (39%).[15] Thay đổi văn hóaDevOps không đơn thuần là công cụ hay quy trình, nó yêu cầu sự thay đổi văn hóa có tổ chức.[10] Sự thay đổi văn hóa này đặc biệt khó khăn, bởi vì sự mâu thuẫn về vai trò của các phòng ban:
Tập hợp các nhóm này để làm việc chung một cách chặt chẽ — là một thách thức quan trọng trong môi trường doanh nghiệp để có thể áp dụng DevOps.[18] Xây dựng một nền văn hóa DevOps Nguyên tắc lớn nhất của DevOps là sự giao tiếp liên phòng ban - team buiilding và khuyến khích nhân viên hoạt động - để tạo một môi trường thuận lợi cho sự liên lạc này.[15] Team building có thể bao gồm chơi trò chơi, hội thảo.[15] Triển khaiCác công ty thường xuyên phát hành phiên bản phần mềm có thể triển khai DevOps. Ví dụ, công ty về lưu trữ hình ảnh trên trang web Flickr phát triển một phương pháp DevOps, hỗ trợ yêu cầu triển khai 10 lần mỗi ngày.[19] Điều này được gọi là Triển khai liên tục[20] hoặc Phân phối liên tục[21] và đã được kết hợp với các phương pháp Lean.[22] Các nhóm làm việc, các hiệp hội chuyên nghiệp và blog đã được hình thành theo chủ đề DevOps từ năm 2009.[23][24] DevOps và kiến trúcĐể thực hành DevOps một cách hiệu quả, phần mềm phải đáp ứng một tập hợp các yêu cầu đặc biệt về kiến trúc (architecturally significant requirements - ASRs) như: có thể triển khai, thay đổi, kiểm thử, và giám sát). Những yêu cầu ASRs này có độ ưu tiên cao và không thể xem nhẹ. Mặc dù về nguyên tắc, có thể thực hành DevOps với bất kỳ kiểu kiến trúc nào — nhưng microservices là kiểu kiến trúc tiêu chuẩn để xây dựng hệ thống triển khai liên tục.[15] Phạm vi áp dụngMột số bài viết về DevOps cho rằng: "DevOps chỉ là nguyên tắc của Phát triển phần mềm linh hoạt..."[25] Một cuộc điều tra được xuất bản vào tháng 1 năm 2016 bởi công ty RightScale, áp dụng DevOps tăng từ 66% trong năm 2015 lên 74% vào năm 2016. Và trong các tổ chức lớn, DevOps thậm chí còn cao hơn — 81%.[15] Áp dụng DevOps được điều khiển bởi nhiều yếu tố — bao gồm:
Gia tăng áp dụng"Thuyết về sự Hạn chế" (The theory of constraints) áp dụng vào việc thực hành DevOps như sau: sự hạn chế có giới hạn thường ăn sâu sự vào sự không ưa thay đổi trong các bộ phận trong doanh nghiệp.[29] Sự gia tăng áp dụng biểu hiện qua các phương pháp "Lý Thuyết về sự Hạn chế" cung cấp cho cuộc chiến chống bất kỳ sự cưỡng ép nào, được gọi là "Năm bước tập trung".[15] Ba nguyên tắc sau của Gene Kim thiết lập các cách cơ bản để áp dụng DevOps:[15] Cách đầu tiên: suy nghĩ có hệ thốngNhấn mạnh việc tập trung vào hiệu năng toàn hệ thống hơn là các thành phần đơn lẻ. Cách thứ hai: khuếch đại vòng lặp phản hồiNhấn mạnh vào việc gia tăng phản hồi và hiểu biết của các nhóm làm việc có liên quan. Cách thứ ba: nền văn hóa của sự thử nghiệm và học hỏi liên tụcHai thứ quan trọng nhất: thử nghiệm và thực hành. Tham khảo
Xem thêm
Đọc thêm
|