Scott W.Ambler: Top 10 phương pháp DevOps hiệu quả – Phần 1

Ứng dụng những phương pháp DevOps sau đây để đạt được mục tiêu hợp tác hiệu quả, vận hành trơn tru hơn và code sạch hơn. DevOps đã trở thành một trong số những thuật ngữ được biết đến nhiều nhất trong ngành công nghiệp của chúng ta. Thế nhưng, một điều bất ngờ là vẫn chưa có một ý kiến thống nhất về định nghĩa thực sự DevOps là gì, bên cạnh tầm nhìn cao xa về sự hợp tác hiệu quả giữa team phát triển (developer) và team vận hành (operator). Mặc dù DevOps có thể mang ý nghĩa khác nhau đối với mỗi tổ chức, vẫn tồn tại những thủ thuật tối ưu cốt lõi đang nổi lên nhằm thúc đẩy mục đích chính là tăng cường hiệu quả hợp tác để cho ra những phần mềm tốt hơn. Trong bài viết này, tôi sẽ đi sâu hơn vào những thủ thuật đó. Cũng xin được nói trước, tôi sẽ không chỉ phân tích vấn đề này dưới góc độ quan điểm của developer. Tôi đã liệt kê những đề mục dưới đây theo độ ưu tiên, phương pháp đứng sau ít nhiều sẽ phụ thuộc vào phương pháp được nói đến trước đó.

Phương pháp 1: Chủ động tham gia với tư cách một Stakeholder

Một triết lý căn bản của DevOps chính là việc các lập trình viên, nhóm vận hành, và cả nhóm hỗ trợ phải thường xuyên làm việc gần nhau. Điều đó có nghĩa là họ phải xem nhau như những stakeholder quan trọng và chủ động tìm đến hợp tác. Một cách tiếp cận thường thấy trong cộng đồng agile chính là “khách hàng tại hiện trường”, được rút ra từ Extreme Programming (XP), có tác dụng thúc đẩy lập trình viên Agile làm việc sát với mục tiêu kinh doanh. Những chuyên gia Agile kỷ luật sẽ nâng cách tiếp cận này lên một tầm cao mới bằng việc thực thi phương pháp: “chủ động tham gia với tư cách Stakeholder”, trong đó yêu cầu dev phải làm việc trực tiếp với tất cả các stakeholder của họ, bao gồm cả đội vận hành và hỗ trợ – chứ không chỉ riêng gì những stakeholder đóng vai trò đối tác kinh doanh. Đây là mối quan hệ hai chiều: nhóm vận hành và hỗ trợ cũng phải sẵn lòng hợp tác với phía lập trình viên.

Phương pháp 2: Kiểm thử tự động (Automated Testing)

• Những việc làm hấp dẫn từ
• 

  (HCM) Java Developer |Attractive salary

  Capgemini Vietnam - Ho Chi Minh

  AgileJ2EEJavaFront-EndBack-End
• 

  (HCM) Software QA Engineer (Automation) | Attractive Salary

  MISFIT - Ho Chi Minh

  AgileQA
• 

  (HCM) Senior Automation Testers | Attractive Salary

  KMS Technology - Ho Chi Minh

  AgileQAQCTester

Các nhà phát triển phần mềm Agile được cho là “chú trọng chất lượng” do quan tâm rất nhiều đến việc viết ra những đoạn code tốt và mong muốn test sản phẩm một cách liên tục và nhanh chóng nhất có thể. Kết quả là kiểm thử thoái lùi tự động (automated regression testing) trở thành một kỹ thuật phổ biến được các team Agile áp dụng, và thi thoảng còn mở rộng đến những phương pháp test-first như TDD (Test-Driven Development) và BDD (Behavior-Driven Development). Vì team Agile thường chạy các test-suite tự động của họ nhiều lần trong một ngày, và vì họ sửa những vấn đề họ bắt gặp được ngay tức khắc, nên họ đạt được chất lượng cao hơn những team không áp dụng. Đây là một tin đáng mừng cho những operator vẫn luôn kiên định rằng giải pháp được đưa ra phải đủ chất lượng trước khi được chấp thuận đưa vào sản xuất.

Phương pháp 3: Quản lý cấu hình tích hợp (Integrated Configuration Management)

Bằng cách tiếp cận quản lý cấu hình (CM) theo lối tích hợp, các nhóm phát triển không chỉ áp dụng CM ở mức độ solution truyền thống, mà còn cân nhắc đến vấn đề cấu hình sản xuất giữa solution của họ và điều kiện cơ sở hạ tầng của những bộ phận còn lại trong tổ chức của bạn. Điều này có thể coi là thay đổi rất lớn đối với một số developer, bởi họ thường quen với việc cân nhắc CM trên một phương diện duy nhất, là solution mà họ đang thực hiện. Trong môi trường DevOps, lập trình viên cần phải ý thức đến mục tiêu kinh doanh và “nhìn xa trông rộng” hơn. Làm sao để solution của họ vừa có thể làm việc với, và vừa tận dụng được những tài nguyên khác trong sản xuất? Liệu những tài nguyên khác có thể trở thành đòn bẩy cho solution đang được phát triển hiện tại? Điều này có nghĩa là dev team sẽ phải hiểu được, và quản lý được, toàn bộ những yếu tố phụ thuộc sản phẩm của họ. Phương pháp “quản lý cấu hình tích hợp” sẽ giúp bộ phận vận hành nắm được sức ảnh hưởng tiềm tàng của mỗi đợt phát hành mới, từ đó dễ dàng quyết định được thời điểm nào nên cho ra sản phẩm.

Phương pháp 4: Quản lý thay đổi tích hợp (Integrated Change Management)

Theo quan điểm ngành IT, “quản lý thay đổi” (change management) là hành động đảm bảo sự tiến bộ thành công và có ý nghĩa của cơ sở hạ tầng IT, để hỗ trợ tổng thể tổ chức một cách hiệu quả hơn. Điều này chỉ trên cấp độ team dự án thôi đã rất khó khăn, bởi quá trình phát triển một solution độc nhất đòi hỏi phải áp dụng nhiều loại công nghệ, thậm chí cả những phiên bản khác nhau của cùng một loại công nghệ. Bởi DevOps giới thiệu cả những vấn đề thuộc cấp độ tổ chức kinh doanh liên quan đến vận hành vào trong hỗn hợp này, chiến lược “quản lý thay đổi tích hợp” có thể trở nên phức tạp hơn rất nhiều, do cùng lúc phải cân nhắc một số lượng lớn những solution đang chạy và tương tác trong sản xuất. Với phương pháp “quản lý thay đổi tích hợp”, team phát triển buộc phải làm việc sát với team vận hành để hiểu được một thay đổi bất kỳ về mặt công nghệ có thể dẫn đến kết quả như thế nào ở cấp độ tổ chức. Cách tiếp cận này phụ thuộc vào phương pháp tôi đã nêu ra trước đó là chủ động tham gia với tư cách một Stakeholder, quản lý cấu hình tích hợp và kiểm thử tự động.

Phương pháp 5: Tích hợp liên tục (Continuous Integration)

Continuous Integration (CI) là nguyên tắc xây dựng và hợp thức hóa một dự án, thông qua kiểm thử thoái lùi tự động và thi thoảng là phân tích code mỗi khi code mới cập nhật được check vào hệ thống quản lý phiên bản (VCS). CI là một trong những phương pháp phát triển Agile đặc biệt gợi cảm (trong mắt một developer) và thường được gắn liền với DevOps. CI cho phép một lập trình viên phát triển một solution chất lượng và hiệu quả một cách an toàn, thông qua những bước nhỏ và đều đặn bằng cách gửi phản hồi ngay lập tức khi phát hiện hư hỏng trong code.

SCOTT W.AMBLER LÀ MỘT KỸ SƯ PHẦN MỀM, TÁC GIẢ SÁCH VÀ HIỆN ĐANG LÀM SENIOR CONSULTING PARTNER TẠI SCOTT AMBLER + ASSOCIATES. ÔNG ĐÃ VIẾT RẤT NHIỀU NHỮNG CUỐN SÁCH VỀ PHƯƠNG PHÁP PHÁT TRIỂN AGILE CÓ KỶ LUẬT (DISCIPLINED AGILE DELIVERY), UNIFIED SOFTWARE DEVELOPMENT PROCESS, PHÁT TRIỂN PHẦN MỀM AGILE, UNIFIED MODELING LANGUAGE, VÀ PHÁT TRIỂN DỰA TRÊN CMM (CAPABILITY MATURITY MODEL).