Làm thế nào DevOps có thể giúp cải thiện thủ tục Ký quỹ phần mềm?

Hãy xem xét một nhà cung cấp phần mềm và một khách hàng được cấp phép của một số phần mềm của nhà cung cấp này, trong đó phần mềm được cấp phép được sử dụng trên cơ sở (tại địa điểm của khách hàng) hoặc theo định dạng của giải pháp SaaS (được lưu trữ bởi nhà cung cấp). Tuy nhiên, khách hàng chỉ có quyền truy cập vào những gì cần thiết để sử dụng / chạy phần mềm (thực thi và những thứ tương tự), do đó, không phải các thành phần nguồn và bất cứ điều gì liên quan đến điều đó để tạo ra các tệp thực thi.

Để bảo vệ tính liên tục trong kinh doanh của khách hàng trong các tình huống có thể xảy ra sự cố với nhà cung cấp (ví dụ: phá sản), cả hai bên có thể đồng ý với một số thỏa thuận Ký quỹ phần mềm (SE ... 'cũng') (còn gọi là ký quỹ mã nguồn ). Với thỏa thuận như vậy, cả hai bên đồng ý cho bên thứ 3 tham gia (= "Đại lý ký quỹ phần mềm"), được cả hai bên tin tưởng. Đây là những điểm nổi bật của thỏa thuận SE như vậy (= thông số kỹ thuật của quy trình SE thực tế):

• TẤT CẢ các phần của thành phần phần mềm (hiện vậtliên quan đến phần mềm được cấp phép) được gửi bởi nhà cung cấp phần mềm, tại một số địa điểm đã thỏa thuận liên quan đến đại lý SE. Các khoản tiền gửi này bao gồm các tệp thực thi, nhưng cũng có các thành phần nguồn và bất kỳ thứ gì liên quan đến đó để tạo các tệp thực thi (thậm chí cả tài liệu, hướng dẫn, v.v để tạo các tệp thực thi).
• Vì nhà cung cấp phần mềm có thể tạo nhiều bản phát hành trong thời hạn của giấy phép phần mềm và khách hàng có quyền nhận các bản phát hành mới đó (theo thỏa thuận cấp phép), một phần của thỏa thuận SE đó là "với mỗi bản phát hành mới chính" (bất kể "chính" có thể có nghĩa là gì ...), khoản tiền gửi được giao cho đại lý SE cũng sẽ được cập nhật / làm mới.
• Nếu các điều kiện cụ thể được thỏa mãn (ví dụ: phá sản của nhà cung cấp), thì đại lý Ký quỹ phần mềm sẽ giao cho khách hàng được cấp phép, theo yêu cầu của khách hàng đó, sao chép mọi thứ đã được gửi, để khách hàng có thể tiếp tục sử dụng phần mềm và nơi cần thiết thậm chí điều chỉnh mã nguồn để tiếp tục sử dụng nó cho doanh nghiệp của khách hàng.

Một thông lệ chung cho các đặc vụ SE như vậy tham gia, là một loại pháp nhân / pháp nhân, chẳng hạn như luật sư. Nhưng để thực sự "xử lý tiền gửi SE" (bởi các tác nhân SE), tất cả các loại quản lý phát hành và / hoặc nhiệm vụ phân phối phần mềm cần phải được thực hiện bởi ai đó hoặc một cái gì đó (đại lý SE nghèo) có thể không biết tại tất cả những gì phần mềm được cấp phép được cho là làm ... niềm vui được đảm bảo!

Câu hỏi của tôi :

Làm thế nào DevOps có thể giúp cải thiện thủ tục Ký quỹ phần mềm như được mô tả ở trên? Thích kiểu gìchuỗi công cụ-tools bạn muốn giới thiệu để được sử dụng để thực hiện phần nào của thỏa thuận SE? Và nơi thích hợp sử dụng giải pháp phần mềm (tốt nhất là nguồn mở) cho nó?

Ghi chú :

1. Để không làm phức tạp thêm mọi thứ, chỉ cần giả định rằng nó đã được thỏa thuận giữa tất cả các bên liên quan, rằng đại lý SE KHÔNG phải thực hiện bất kỳ loại " xác minh " nào về việc gửi tiền được thực hiện. Đó là: bất cứ điều gì được gửi đều được coi là hoàn chỉnh, cập nhật, ghi lại, v.v.

2. Về "bản phát hành mới lớn": giả sử có từ 1 đến 3 mỗi năm, điều đó có nghĩa là khách hàng được cấp phép chỉ mong có thể có quyền truy cập (thông qua đại lý SE) cho các bản phát hành đó. Mặc dù nếu đã có giao hàng trung gian (như bản sửa lỗi hoặc phiên bản beta) cho khách hàng được cấp phép, những loại giao hàng đó được coi là ngoài phạm vi. Ngay cả khi đó chỉ là vì:

   • phí đại lý SE "cho mỗi khoản tiền gửi được xử lý bởi đại lý SE".
   • khách hàng được cấp phép hiếm khi thay đổi các bản phát hành và chỉ quan tâm đến việc có thể sử dụng thỏa thuận SE nếu có sự cố xảy ra, vì bản phát hành mà họ đang chạy vào thời điểm có sự cố.

Một câu hỏi rất thú vị. Giả định rằng mục tiêu của quy trình Ký quỹ phần mềm là cho phép Bên ^thứ 3 tiếp quản hoặc chỉ định một bên bổ sung để thực hiện trách nhiệm của nhà cung cấp phần mềm, tôi sẽ đề xuất các yếu tố sau của mô hình hoạt động DevOps sẽ hỗ trợ ký quỹ phần mềm:

1. Cơ sở hạ tầng dưới dạng mã - ghi lại một cách hiệu quả thông qua một đặc tả có thể thực hiện được của cơ sở hạ tầng phụ thuộc, được lưu trữ và phiên bản trong kiểm soát nguồn cung cấp các môi trường mà mã nguồn được phát triển. Không giống như tài liệu tĩnh trong các tệp văn bản bởi vì phần mềm được thực thi trên cơ sở thường xuyên nhà cung cấp để xây dựng môi trường của riêng họ, nó không bị lỗi thời do "thối bit". Điều này sẽ luôn giữ giá trị cao nhất khi toàn bộ đường ống phát triển được xây dựng và duy trì trong kiểm soát nguồn áp dụng các nguyên tắc cơ sở hạ tầng dưới dạng mã.

2. Tích hợp liên tục - mục tiêu của tích hợp liên tục là thực hiện một tập hợp các bước tích hợp giải pháp một cách thường xuyên, lý tưởng cho mỗi thay đổi. Thông thường, điều này có nghĩa là khi đăng ký và đẩy vào kho lưu trữ trung tâm, một tập hợp các kiểm tra được thực thi để xác nhận quy trình. Từ góc độ ký quỹ phần mềm, tôi hy vọng điều này cũng sẽ đẩy một phiên bản hoạt động sang kho lưu trữ "dự phòng" thứ cấp do các bên ^thứ 3 sở hữu và vận hành . Điều quan trọng cần lưu ý là điều này không cần phải "không liên kết" về mặt pháp lý và tài chính từ nhà cung cấp phần mềm.

3. Triển khai liên tục - mục tiêu của việc triển khai liên tục là cung cấp phần mềm ở trạng thái hoạt động thường xuyên. Theo nghĩa này, bên ^thứ 3 chỉ là một mục tiêu triển khai khác để triển khai các kết quả đầu ra, mặc dù có thể không chủ động tăng cường cơ sở hạ tầng trên kết cấu của bên ^thứ 3 .

Một số cân nhắc khác để đưa vào phương trình là:

• việc chuyển từ tài liệu tĩnh sang cơ sở hạ tầng dưới dạng mã làm giảm đáng kể công việc liên quan đến cập nhật tài liệu mô tả cách cài đặt, định cấu hình và khôi phục phần mềm.
• đừng quên quản lý bí mật, chẳng hạn như Chứng chỉ X.509, khóa đối xứng, mật khẩu và khóa giấy phép, chúng có thể được lưu trữ trong kiểm soát nguồn tuy nhiên điều này có nhược điểm riêng.

Từ góc độ công cụ, điều này sẽ phụ thuộc rất nhiều vào môi trường phát triển, tôi không tin có bất kỳ công cụ nào dành riêng cho ký quỹ phần mềm:

• Phát triển .NET

  • GitHub hoặc BitBucket để kiểm soát nguồn
  • AppVeyor , TeamCity hoặc Jenkins cho các yếu tố xây dựng và thử nghiệm của đường ống.
  • Ansible , Puppet hoặc Chef cho các thành phần quản lý cấu hình của đường ống.
  • ProGet cho các thành phần quản lý gói của đường ống
  • Bạch tuộc Triển khai cho các khía cạnh triển khai của đường ống

• Phát triển Java và một số nền tảng Nguồn mở rộng

  • CircleCI , TravisCI , TeamCity hoặc Jenkins cho các yếu tố xây dựng và thử nghiệm của đường ống.
  • Ansible , Puppet hoặc Chef cho các thành phần quản lý cấu hình của đường ống.
  • JFrog Artifactory hoặc Sonartype Nexus cho các thành phần quản lý gói của đường ống
  • Capistrano cho các khía cạnh triển khai của đường ống

Vào cuối ngày, nếu bạn có thể sử dụng các nguyên tắc Cơ sở hạ tầng, Tích hợp liên tục và Triển khai liên tục cho gói phần mềm, nó có thể được sử dụng để thực hiện nghĩa vụ của bạn theo hợp đồng Ký quỹ phần mềm.

Nhưng để thực sự "xử lý tiền gửi SE" (bởi các tác nhân SE), tất cả các loại quản lý phát hành và / hoặc nhiệm vụ phân phối phần mềm cần phải được thực hiện bởi ai đó hoặc một cái gì đó (đại lý SE nghèo) có thể không biết tại tất cả những gì phần mềm được cấp phép được cho là làm ... niềm vui được đảm bảo!

Tôi sẽ không làm việc với một nhà cung cấp SE sẽ cho phép tình huống đáng tiếc như vậy tồn tại - họ không biết họ đang làm gì.

Nếu tiền gửi SE được xử lý theo bất kỳ cách nào bởi đại lý SE, quy trình xử lý chính xác và đầy đủ cần phải được ghi lại đầy đủ trong các thỏa thuận để nó thực sự có thể sử dụng được.

Điều đó cũng nên bao gồm đặc tả môi trường chính xác (hoặc thủ tục để tái tạo nó) và chuỗi công cụ được sử dụng để xử lý như vậy. Nói cách khác, sự lựa chọn không thực sự đơn phương mở cho đặc vụ SE. Ngoại trừ có thể cho chiến lược lưu trữ thực tế (cá nhân tôi cũng bao gồm lựa chọn đó trong đặc tả thỏa thuận, ngay cả khi lựa chọn được thực hiện đơn phương bởi đại lý SE).

Một thỏa thuận SE tốt cũng sẽ đảm bảo rằng mỗi khoản tiền gửi SE của nhà cung cấp đều trải qua quá trình xử lý đó và khách hàng luôn nhận được và đủ điều kiện / ký kết kết quả của quá trình xử lý cụ thể đó, không phải là kết quả thay thế trực tiếp từ nhà cung cấp - để xác thực rằng thủ tục vẫn duy trì up2date và có hiệu lực cho mỗi và mọi khoản tiền gửi SE.

Mặt khác, khả năng tái tạo "rút tiền SE" sau đó (nếu / khi cần) là đáng nghi ngờ, điều này thực tế nói lên toàn bộ câu chuyện SE.