Tôi đã thực hiện / tạo rất nhiều bài thuyết trình liên quan đến SCM và bây giờ tôi đang cố gắng "nâng cấp" thành người kế thừa DevOps của nó.

Điều tôi luôn cố gắng thực hiện trong các bài thuyết trình của mình là đưa ra một slide giới thiệu bằng cách nào đó bao gồm thông điệp tôi muốn gửi (và sau đó tôi sẽ trình bày trong phần còn lại của bài thuyết trình). Khi làm như vậy, tôi cố gắng trả lời câu hỏi của riêng mình như "Tôi sẽ sử dụng từ 1 đến 3 cụm từ nào nếu tôi muốn 10 đến 20 giây (chỉ!) Để giải thích cho ai đó mới biết về nó? * ".

Tôi nghĩ rằng tôi biết DevOps thực sự có nghĩa là gì, và nó là về cái gì. Nhưng tôi đã thấy một số cách sử dụng / bối cảnh kỳ lạ của DevOps (ngay cả trên DevOps.SE ...). Nó khiến tôi tự hỏi liệu có lẽ những gì tôi nghĩ DevOps là, hoàn toàn sai.

Vì vậy, những gì thường được đồng ý là định nghĩa của DevOps?

DevOps một cách ngắn gọn

Từ Wikipedia :

DevOps (một hợp chất được cắt xén của " phần mềm DEV elopment " và " công nghệ thông tin OP eration S ") là một thuật ngữ dùng để chỉ một tập hợp nhấn mạnh sự hợp tác và giao tiếp của cả chuyên gia phát triển phần mềm và công nghệ thông tin (CNTT) trong khi tự động hóa quá trình phân phối phần mềm và thay đổi cơ sở hạ tầng.

Nó nhằm mục đích thiết lập một nền văn hóa và môi trường nơi việc xây dựng , thử nghiệm 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ừ tổng quan :

Biểu đồ Venn cho thấy DevOps là giao điểm của phát triển (công nghệ phần mềm), hoạt động và đảm bảo chất lượng (QA)

Mặc dù không có "công cụ" duy nhất cho DevOps, mà là một bộ công cụ, còn được gọi là chuỗi công cụ DevOps :

Minh họa hiển thị các giai đoạn trong chuỗi công cụ DevOps

Minh họa của DevOps

Dưới đây là một vài trích dẫn từ một số câu hỏi trên DevOps.SE , tất cả dường như đều phù hợp / xác nhận một phần mô tả của DevOps ở trên:

• Từ 'Sự khác biệt giữa SRE và DevOps là gì? ':

  ... DevOps là về việc duy trì mã ...

• Từ (một câu trả lời cho) ' Làm cách nào để tôi thuê một DevOps tốt, phù hợp với công ty của tôi? ':

  ... Có một sự hiểu lầm phổ biến rằng, Dev Devpsps là một vai trò trong một công ty. Từ này chỉ đơn thuần biểu thị một sự thay đổi tổ chức trong các công ty phần mềm ...

• Từ ' Tổ chức của tôi có cần áp dụng Agile Soft không. Nhà phát triển trước khi áp dụng DevOps? ':

  ... vẫn còn những tổ chức không thực hành Agile trong phát triển phần mềm của họ, những người có thể quan tâm đến việc áp dụng DevOps ...

DevOps KHÔNG phải là một vai trò

Dưới đây là một vài trích dẫn từ một số câu hỏi trên DevOps.SE , tất cả dường như minh họa rằng DevOps KHÔNG phải là một vai trò:

• Từ (một câu trả lời cho) 'Sự khác biệt giữa Sysadmin và DevOps Engineering là gì? ':

  ... DevOps không phải là một vai trò (khi được sử dụng như vậy nó là một từ thông dụng hơn là một vai trò thực sự).

• Từ (một câu trả lời cho) ' Làm cách nào để tôi thuê một DevOps tốt, phù hợp với công ty của tôi? ':

  ... Có một sự hiểu lầm phổ biến rằng, Dev Devpsps là một vai trò trong một công ty. Từ này chỉ đơn thuần biểu thị một sự thay đổi tổ chức trong các công ty phần mềm ...

Tôi đã thực hành và tư vấn cho DevOps với tư cách là nhà tư vấn với các khách hàng khác nhau trong gần năm năm nay, trước khi ở vị trí hiện tại, tôi giữ vai trò phát triển phần mềm, vận hành web và quản trị hệ thống. Theo kinh nghiệm cá nhân của tôi, DevOps có nhiều hương vị.

Mô hình tổ chức

DevOps Antipotypes:

• NoOps và NoDevs - không hoàn toàn DevOps theo nghĩa nghiêm ngặt nhất, tuy nhiên, các nhóm này đều xây dựng và vận hành phần mềm mà không có ranh giới giữa Phát triển và Vận hành. Những thách thức với các nhóm này đã đến lúc trưởng thành, các nhóm Phát triển có thể là Chuyên gia phát triển phần mềm nhưng là Người vận hành mới và ngược lại.

• Cầu DevOps - đây là nơi một hoặc nhiều nhóm được giao trách nhiệm nhận công việc từ các nhóm phát triển và " Sản xuất " để làm cho nó hoạt động được. Thách thức đến nay có hai lần bắt tay, đó là Phát triển → DevOps và DevOps → Hoạt động.

• Nhóm DevOps - có thể được cho là có thể hoạt động nếu nhóm có trách nhiệm xây dựng các công cụ hỗ trợ Mô hình hoạt động được kích hoạt DevOps, tuy nhiên, có lẽ nên được gọi là "Nhóm công cụ" hoặc "Nhóm nền tảng".

Mô hình DevOps:

• DevOps nhúng - thường được gọi là Kỹ thuật nền tảng, trong đó có một người trong nhóm chịu trách nhiệm nhưng không chịu trách nhiệm cung cấp tự động hóa, công cụ và cơ sở hạ tầng để cung cấp và triển khai giải pháp, đôi khi bao gồm cả vận hành phần mềm - trong tâm trí của tôi , đó là cái sau thực sự là đại diện của DevOps.

• DevOps thể chế hóa - nơi một nhóm dự án cùng nhau chịu trách nhiệm cho cả phát triển và hoạt động của một gói phần mềm xây dựng sở hữu được chia sẻ và vòng phản hồi tích cực.

Thực tiễn

Thực tiễn thực tế của DevOps được xây dựng dựa trên một số thực tiễn khác, cụ thể là:

• Giao hàng nhanh
• Hội nhập liên tục
• Giao hàng liên tục
• Triển khai liên tục

Mỗi thực hành trên được xây dựng dựa trên các thực tiễn khác, có thể không tuân theo một thực tiễn, tuy nhiên, điều đó có nghĩa là một chu kỳ phản hồi quan trọng bị thiếu có thể là dấu hiệu của "cơ hội bị bỏ lỡ". Sự khác biệt chính giữa việc tuân theo bất kỳ thực tiễn nào khác và DevOps là hoạt động của phần mềm trong sản xuất .

Ba cách

Trong Dự án Phượng hoàng, Gene Kim và các đồng tác giả đã mô tả ba cách của DevOps :

Hệ thông suy nghĩ

Cách thứ nhất nhấn mạnh hiệu suất của toàn bộ hệ thống, trái ngược với hiệu suất của một silo cụ thể của công việc hoặc bộ phận - đây có thể là một bộ phận lớn (ví dụ: Hoạt động phát triển hoặc CNTT) hoặc nhỏ như một người đóng góp riêng lẻ (ví dụ , một nhà phát triển, quản trị hệ thống).

Theo kinh nghiệm của tôi, bắt đầu khiến các Nhà phát triển xem xét các Mối quan tâm hoạt động và các yêu cầu phi chức năng đạt được mục tiêu này. Đây là một phần rất lớn trong các khía cạnh văn hóa của DevOps.

Khuếch đại các vòng phản hồi

Cách thứ hai là về việc tạo các vòng phản hồi từ phải sang trái. Mục tiêu của hầu hết mọi sáng kiến ​​cải tiến quy trình là rút ngắn và khuếch đại các vòng phản hồi để có thể liên tục sửa chữa.

Tôi thường đạt được điều này thông qua Tích hợp / Phân phối / Triển khai liên tục và theo dõi và cảnh báo được chia sẻ, do đó nó rất phù hợp với thành phần công cụ của DevOps.

Văn hóa thử nghiệm và học tập liên tục

Cách thứ ba là tạo ra một nền văn hóa thúc đẩy hai điều: thử nghiệm liên tục, chấp nhận rủi ro và học hỏi từ thất bại; và hiểu rằng sự lặp lại và thực hành là điều kiện tiên quyết để làm chủ.

Điều này rất phù hợp với không gian văn hóa , mặc dù nó phụ thuộc rất nhiều vào các công cụ và quy trình để cho phép văn hóa phát triển.

Tôi đã nghe nhiều, rất nhiều định nghĩa khác nhau về DevOps. Chúng bao gồm:

• Nhà phát triển xử lý các nhiệm vụ hoạt động
• Một người làm gấp đôi công việc (trong cùng một khoảng thời gian)
• Các nhà phát triển và nhóm hoạt động làm việc với nhau
• Hoạt động làm việc cho công cụ phát triển (theo mạch của "Web Ops")
• Một chức danh cho một người tạo và duy trì công cụ phát triển
• Việc sử dụng tự động hóa trong hoạt động
• Việc sử dụng các đám mây công cộng trong hoạt động
• Một công việc kết hợp các khía cạnh của hoạt động, phát triển và đảm bảo chất lượng
• Một công việc đòi hỏi phải giúp các nhóm phát triển và vận hành làm việc cùng nhau
• Một triết lý phá vỡ các rào cản giữa các đội
• Coi cơ sở hạ tầng là mã
• Bạn nhận được gì khi các cựu kỹ sư phần mềm chuyển sang hoạt động
• Một từ thông dụng hoàn toàn vô nghĩa

Không có sự đồng thuận nào của công chúng về những gì DevOps thực sự là . Vài năm trước, chúng tôi đã gặp vấn đề tương tự với "Agile" và điều đó có định nghĩa bằng văn bản .

Khi giới thiệu các khái niệm của bạn cho người mới, tôi tập trung vào giới thiệu các khái niệm, thay vì áp dụng nhãn, nếu không họ sẽ nghe thấy các định nghĩa mâu thuẫn và bị nhầm lẫn. Ví dụ: nếu bạn đang cố gắng nói về cơ sở hạ tầng dưới dạng mã , hãy nói với họ rằng bạn đang nói về cơ sở hạ tầng dưới dạng mã. Bạn càng cụ thể, càng tốt, vì ngay cả với các định nghĩa đã được thống nhất, hầu hết các công ty đều tập trung nhiều hơn vào các phần nhất định của triết lý.

Định nghĩa tôi luôn sử dụng trong tình huống này là như sau:

Một nền văn hóa sáng tạo phần mềm nhấn mạnh vào sự giao tiếp và hợp tác giữa các nhóm vận hành và phát triển phần mềm trong khi tự động hóa quy trình phân phối phần mềm và thay đổi cơ sở hạ tầng. Mục tiêu của DevOps là làm cho quá trình xây dựng, kiểm tra và triển khai phần mềm trở nên thường xuyên, nhanh chóng và tốt nhất có thể.

Tuy nhiên, cùng với định nghĩa, điều quan trọng là họ hiểu TẠI SAO chúng ta cần DevOps. Hãy chắc chắn nói với họ rằng DevOps giảm thiểu lỗi phần mềm nhanh hơn, cho phép quản lý tài nguyên tốt hơn, ít lỗi hơn, kiểm soát phiên bản tốt hơn, môi trường hoạt động ổn định, v.v.

Bằng tài liệu nghiên cứu khoa học sau đây để khám phá chính xác câu hỏi này, "DevOps là gì", định nghĩa xuất phát của DevOps là:

DevOps là một phương pháp phát triển nhằm thu hẹp khoảng cách giữa Phát triển (Dev) và Hoạt động (Ops), nhấn mạnh vào giao tiếp và hợp tác, tích hợp liên tục, đảm bảo chất lượng và phân phối với triển khai tự động sử dụng một tập hợp phát triển.

[Jabbari et al.] "DevOps là gì?: Một nghiên cứu lập bản đồ có hệ thống về định nghĩa và thực tiễn" (2016)

Devops là thực tiễn phát triển của các ứng dụng viết có lĩnh vực kinh doanh là hoạt động. Trong đó hầu hết phát triển ứng dụng tập trung vào việc xây dựng các ứng dụng làm tài chính hoặc chăm sóc sức khỏe hoặc hậu cần hoặc video cho mèo, các nhà phát triển tập trung vào các ứng dụng cho phép xây dựng, triển khai, giám sát và thu thập số liệu.

Mục tiêu quan trọng nhất phải luôn luôn là cho phép những người ra quyết định trở thành người ra quyết định . Hãy tưởng tượng ứng dụng di động của ngân hàng của bạn. Khi bạn yêu cầu chuyển, nó xảy ra khi bạn nhấn nút. Bạn đã đưa ra quyết định, sau đó đưa ra quyết định. Điều tương tự với hoạt động của bạn. Khi người thích hợp quyết định một số công việc đã sẵn sàng để triển khai vào sản xuất, họ sẽ có thể nhấn nút và "Điều đúng xảy ra". Tương tự, họ nên có tất cả các thông tin cần thiết để đưa ra quyết định kinh doanh chính xác.

Đó không phải là về việc cung cấp cho người kinh doanh vỏ quyền truy cập vào máy chủ - đó là mục đích khó hiểu với việc thực hiện. Đó là về việc cung cấp các nút và đòn bẩy chính xác với thông tin phù hợp và đường ray bảo vệ đúng cho đúng người để những người ra quyết định là người ra quyết định.