DevOps có bị giới hạn ở các công ty có sản phẩm SaaS không?

Các thực tiễn mô tả DevOps, như giao hàng liên tục, tự động hóa, v.v ... có liên quan đến các sản phẩm cung cấp dịch vụ liên tục, chẳng hạn như các sản phẩm SaaS.

Ví dụ, một công ty phát triển phần mềm chủ yếu thực hiện các dự án cho các khách hàng khác có thể không bao giờ được duy trì những điều này sau khi dự án kết thúc. Và các dự án khách hàng không được chia sẻ với các khách hàng khác, vì không liên quan.

DevOps thậm chí có áp dụng cho các công ty phát triển nhiều dự án một lần không? Những thực hành DevOps nào áp dụng trong trường hợp này, nếu có?

Tuyệt đối không!

DevOps là tất cả về việc phá vỡ các silo truyền thống (các phòng ban) để có hiệu quả hơn.

Giao tiếp tốt hơn giữa các đội, cải thiện tầm nhìn và quy trình tự động và đáng tin cậy là những cách để đạt được một sản phẩm tốt hơn.

Tôi đã từng làm việc cho một công ty truyền thông lớn, nơi chúng tôi sẽ hỗ trợ một công cụ nội bộ và phát triển các trang web công khai.

Lợi ích của DevOps trong trường hợp của chúng tôi là như sau:

• Thông qua việc xây dựng liên tục, chúng tôi cho biết nhóm phát triển sớm hơn là sau này nếu có sự cố tích hợp hoặc xây dựng với mã của họ. Họ có thể khắc phục các sự cố trong khi tâm trí của họ vẫn nằm trên đoạn mã họ vừa cam kết.
• Thông qua thử nghiệm và phân phối liên tục (vào QA), chúng tôi đã cho phép nhóm QA tìm ra các vấn đề sớm hơn và báo cáo chúng sớm hơn. Điều này làm giảm thời gian tìm và sửa lỗi cũng như giảm độ phức tạp của các cuộc điều tra này.
• Với các công cụ tổng hợp và thu thập nhật ký, chúng tôi đã cấp cho các nhà phát triển quyền truy cập vào thứ mà họ thường không nhìn vào (họ rất quan tâm đến trình gỡ lỗi :) - hiểu cách các bản ghi được các nhóm khác nhìn thấy và sử dụng đã cải thiện chất lượng tổng thể của nhật ký
• Chúng tôi thường chia sẻ thông tin và tạo tài liệu để chia sẻ kiến ​​thức giữa các đội, cố gắng phá vỡ các bức tường. Bằng cách hiểu nhu cầu của Ops, chúng tôi tạo ra một vài hướng dẫn cho những gì cần luôn được ghi nhớ khi bootstrapping một ứng dụng (nơi / cách quản lý các thuộc tính, v.v.). Bằng cách hiểu thực tế của Dev (mã nhiều tính năng hơn, nhanh hơn, gogogogo!), Chúng tôi có thể có các op tạo máy chủ và cụm phù hợp hơn với nhu cầu của nhà phát triển.
• Chất lượng tổng thể của việc triển khai cũng được cải thiện rất nhiều. Việc triển khai đã được xử lý bởi nhóm của chúng tôi, vì vậy chúng tôi có tầm nhìn hoàn hảo trên cả Ops và Dev. Điều này đã loại bỏ nhiều vấn đề liên quan đến "xử lý mã" trong đó nhà phát triển sẽ bàn giao một gói và tài liệu một trang cho các op nói "Cài đặt cái này!".

Nhìn chung, tôi sẽ nói rằng bất kể bạn đang cập nhật môi trường sản xuất một lần mỗi ngày hay mỗi tháng một lần và bất kể bạn có bao nhiêu khách hàng hoặc mô hình kinh doanh, mọi doanh nghiệp đều có thể sử dụng giao tiếp tốt hơn, công cụ tốt hơn, khả năng hiển thị tốt hơn, phản hồi nhanh hơn, v.v.

Nhóm của tôi và tôi chịu trách nhiệm phát triển "một lần", các sản phẩm sau khi hoàn thành được đưa cho khách hàng để bảo trì hoặc trong một số trường hợp do chúng tôi quản lý có tính phí.

Chúng tôi vẫn cần duy trì một đường truyền phát triển vững chắc để xử lý các phản hồi liên tục từ khách hàng của mình để đảm bảo rằng chúng tôi gửi cho họ một thứ gì đó đáng tin cậy và được chứng minh để chạy.

Mặc dù khách hàng không quan tâm đến DevOps (trong hầu hết các trường hợp), nhưng nó vẫn hữu ích cho chúng tôi. Với DevOps, chúng tôi có thể nhanh chóng đẩy các bản dựng mới, vì vậy khách hàng có thể thấy phản hồi trong vài phút chứ không phải vài giờ và chúng tôi cũng có thể bắt gặp bất kỳ lỗi / lỗi nào với thử nghiệm của chúng tôi thông qua Jenkins / Travis.

Để đảm bảo các chiến lược triển khai của chúng tôi giống nhau trên các dự án, chúng tôi tập trung vào việc chứa các ứng dụng của chúng tôi. Sử dụng Docker, chúng tôi có thể dễ dàng chuyển ứng dụng cho khách hàng của chúng tôi.

Chi phí tiết kiệm được bởi DevOps rất khó xác định. Chúng tôi có thêm chi phí dưới dạng phần mềm mà chúng tôi chọn sử dụng cho đường ống (Travis, Jenkins, Puppet, bạn có gì), nhưng chúng tôi cũng tiết kiệm thời gian và tiền bạc bằng cách sửa lỗi / phản hồi nhanh chóng cho khách hàng. Thời gian đáp ứng nhanh chóng của chúng tôi giữ cho khách hàng của chúng tôi hạnh phúc, lần lượt, giữ cho ví của chúng tôi hạnh phúc.

Tôi đã làm việc cho các công ty sản xuất phần mềm dưới dạng các sản phẩm thu nhỏ, như các triển khai được cài đặt và hỗ trợ đầy đủ và dưới dạng mã nhúng trong các thiết bị. Trong tất cả các công ty đó, DevOps cung cấp hỗ trợ thiết yếu để phát triển:

• Các bản dựng tự động, có thể tái tạo của phần mềm, với các cấu hình đã biết, được kiểm soát của trình biên dịch, thư viện và các công cụ xây dựng khác.
• Kiểm tra hệ thống tự động, lặp lại để kiểm tra hồi quy và kiểm tra chức năng mới.
• Các hành động tự động và thường xuyên khác (ví dụ: ảnh chụp màn hình mẫu được cập nhật liên tục có sẵn trong tất cả các ngôn ngữ được hỗ trợ, để người dịch xác minh và cho các tác giả kỹ thuật kết hợp vào hướng dẫn sử dụng).

Trong mọi trường hợp, đây là những điều mà các nhà phát triển riêng lẻ có thể thực hiện một lần, nhưng đó sẽ không sử dụng tốt thời gian của nhà phát triển, cũng không có sự đảm bảo kiểm soát cấu hình tương tự như các bản dựng tự động.

Các hoạt động phát triển và triển khai phần mềm trước đây không yêu cầu tích hợp sâu giữa các phòng ban. Nhưng ngày nay cần phải hợp tác chặt chẽ tất cả các bộ phận (Phát triển, Hoạt động CNTT, Đảm bảo chất lượng, v.v.).

Đối với các nhà phát triển, thay đổi là những gì họ được trả tiền cho. Kinh doanh luôn cần những thay đổi để phù hợp với thế giới hiện đại. Sự hiểu biết này thúc đẩy các nhà phát triển tạo ra số lượng thay đổi tối đa có thể. Các chuyên gia CNTT có một sự hiểu biết khác nhau, trong đó thay đổi là có hại. Mỗi người trong số họ nghĩ rằng nó hoạt động chính xác, mang lại lợi ích cho doanh nghiệp. Thật vậy, nếu chúng ta xem xét chúng một cách riêng biệt, cả hai đều đúng.

Tất cả nhân viên phải hiểu rằng họ là một phần của một quy trình. DevOps trau dồi suy nghĩ, điều đó có thể nhận ra rằng các quyết định và hành động cá nhân của mọi người nên được hướng tới việc thực hiện một mục tiêu duy nhất. Và thành công nên được đo lường liên quan đến toàn bộ chu trình phát triển đến giao hàng, và không phải từ sự thành công của các vai trò riêng lẻ. Là kết quả của sự hợp tác chặt chẽ giữa các nhà phát triển và chuyên gia bảo trì, một thế hệ kỹ sư mới được thành lập, lấy thành tựu tốt nhất của cả hai ngành và kết hợp chúng vì lợi ích của người dùng. Điều này được thể hiện trong sự xuất hiện của các nhóm chức năng chéo có kinh nghiệm trong việc phát triển, quản lý cấu hình, quản lý cơ sở dữ liệu, thử nghiệm và quản lý cơ sở hạ tầng.

Vì vậy, phương pháp này hữu ích không chỉ trong SaaS.

Không có gì. Mặc dù đã có những ví dụ tuyệt vời về chủ đề này, tôi muốn chia sẻ một giai thoại của riêng tôi. Vào năm 2001, tôi đã kế thừa một dự án phần mềm với một bản phát hành liên quan đến việc tạo ra một CD. Tài liệu cho quy trình phát hành bao gồm 40 bước (!) Được ghi lại bởi một kỹ sư trước đó, bao gồm một số hướng dẫn viết tay kỳ cục như "mở tệp cấu hình này và thay đổi tên của tệp .jar trên dòng 41 để bao gồm số phiên bản bản phát hành mới ".

Chúng tôi tích cực tự động hóa từng bước của quy trình xây dựng đó, thay thế các hướng dẫn bằng văn bản như thế bằng những thứ như 'bản vá' được viết theo kịch bản. Chúng tôi thậm chí đã phải mở vé với nhà cung cấp công cụ cài đặt bên thứ ba của chúng tôi để làm cho các tệp dự án của họ có thể vá được.

Khi quy trình đó được tự động hóa, chúng tôi đã mua 'CD Jukebox'. Mỗi đêm sau khi các bài kiểm tra vượt qua, máy dựng sẽ tự động tạo CD cài đặt mới. Những người thử nghiệm của chúng tôi có thể đến vào sáng hôm sau, lấy một đĩa và đảm bảo mọi thứ đều có thể cài đặt được.

Chúng tôi chắc chắn có các vòng phản hồi chặt chẽ hơn khi chúng tôi có thể triển khai phần mềm như một dịch vụ, nhưng các nguyên tắc cốt lõi của tự động hóa, phản hồi, thời gian chu kỳ, các bản phát hành nhỏ, v.v ... đều được áp dụng.