DevOps

DevOps (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. Đ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.

Tổng quan
ơ đồ Venn cho thấy DevOps là sự giao thoa giữa 3 bên: phát triển phần mềm (lập trình viên), quản trị phần mềm và đảm bảo chất lượng phần mềm (QA)]]
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. 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". 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ỉ. 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.

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ụ. 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:
Mã nguồn (Code) - phát triển và phê duyệt mã nguồn, công cụ quản lý phiên bản mã nguồn, trộn mã nguồn;
Biên dịch (Build) — công cụ Tích hợp liên tục và trạng thái build;
Kiểm thử (Test) — kiểm thử và xác định kết quả hiệu suất thực thi;
Đóng gói (Package) — kho lưu trữ Artifact, các giai đoạn của ứng dụng trước khi triển khai;
Phát hành (Release) — quản lý thay đổi, chấp thuận phát hành, phát hành tự động;
Cấu hình (Configure) — cấu hình cơ sở hạ tầng và quản lý, các công cụ về cơ sở hạ tầng dạng mã nguồn;
Giám sát (Monitor) — giám sát hiệu suất ứng dụng, trải nghiệm người dùng cuối.
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.

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.

Mối quan hệ với Agile và Phân phối Liên tục (Continous delivery)

Agile
Agile (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. 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 DevOps
Cá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,..

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. Điều này được gọi là Triển khai liên tục hoặc Phân phối liên tục và đã được kết hợp với các phương pháp Lean. 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.

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.

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%. và đám mây, cơ sở hạ tầng — từ bên trong và bên ngoài cung cấp;
Tăng sử dụng dữ liệu trung tâm tự động và quản lý các công cụ,
Tăng cường tập trung vào bài kiểm tra tự động và liên tục hợp các phương pháp;
Một khối lượng quan trọng của công khai–sẵn sàng thực hành tốt nhất.

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. 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".

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:

Cách đầu tiên: suy nghĩ có hệ thống
Nhấ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ồi
Nhấ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ục
Hai thứ quan trọng nhất: thử nghiệm và thực hành.

Tham khảo

Xem thêm
Tích hợp liên tục
Phân phối liên tục
Kiểm thử liên tục
Hệ thống quản lý phiên bản
Lập trình cực hạn
Lập trình linh hoạt

Đọc thêm