Como o DevOps pode ajudar a melhorar os procedimentos de Custódia de Software?

Considere um fornecedor de software e um cliente licenciado de algum software desse fornecedor, em que o software que está sendo licenciado é usado no local (no local do cliente) ou no formato de solução SaaS (hospedada pelo fornecedor). No entanto, o cliente obtém acesso apenas ao necessário para usar / executar o software (executáveis ​​e similares), portanto, não os componentes de origem e nada relacionado a isso para criar os executáveis.

Para proteger a continuidade de negócios do cliente em cenários em que algo pode dar errado com o fornecedor (por exemplo: falência), ambas as partes podem concordar com algum tipo de contrato de Garantia de Software (SE ... 'também') (também chamado garantia de código-fonte ). Com esse contrato, ambas as partes concordam em envolver uma terceira parte (= um "Agente de Custódia de Software"), confiável por ambas as partes. Estes são os destaques desse contrato SE (= especificações do processo SE real):

• TODOS os componentes de software (artefatosrelacionados ao software licenciado) sejam depositados pelo fornecedor do software, em algum local acordado relacionado ao agente SE. Esses depósitos incluem os executáveis, mas também os componentes de origem e qualquer coisa relacionada a isso para criar os executáveis ​​(mesmo documentação, instruções, etc. para criar os executáveis).
• Como o fornecedor do software pode criar várias versões durante a licença de software e o cliente tem o direito de receber essas novas versões (conforme o contrato de licença), parte desse contrato SE é que "a cada nova versão principal" (seja qual for "importante" possa significar ...), o depósito entregue ao agente SE também será atualizado / atualizado.
• Se condições específicas forem atendidas (por exemplo: falência do fornecedor), o agente de Garantia de Software entregará ao cliente licenciado, mediante solicitação desse cliente, cópia de tudo o que foi depositado, para que o cliente possa continuar usando o quando necessário, adapte o código-fonte para continuar a usá-lo nos negócios do cliente.

Uma prática comum para o envolvimento desse agente de SE é algum tipo de pessoa / entidade jurídica, como um advogado. Mas para realmente "processar os depósitos SE" (pelos agentes SE), todos os tipos de tarefas de gerenciamento de liberação e / ou entrega de software precisam ser executados por alguém ou alguma coisa (o pobre agente SE) que provavelmente não sabe o que o software licenciado deve fazer ... diversão garantida!

Minha pergunta :

Como o DevOps pode ajudar a melhorar os procedimentos do compromisso de software, conforme descrito acima? Como que tipo deconjunto de ferramentasferramentas que você recomendaria que fossem utilizadas para o cumprimento de qual parte do contrato SE? E onde apropriado, usando quais soluções de software (preferencialmente de código aberto) para isso?

Notas :

1. Para não complicar ainda mais as coisas, basta assumir que é acordado entre todas as partes envolvidas, que o agente SE não precisa fazer nenhum tipo de " verificação " sobre os depósitos que estão sendo feitos. Ou seja: tudo o que é depositado é considerado completo, atualizado, documentado etc.

2. Sobre o "novo grande lançamento": suponha que haja entre 1 e 3 a cada ano, o que significa que o cliente licenciado espera apenas ter acesso (via agente SE) a esses lançamentos. Mesmo se houver entregas intermediárias (como correções ou versões beta) para o cliente licenciado, esses tipos de entregas são considerados fora do escopo. Mesmo que fosse apenas porque:

   • o agente SE cobra "por cada depósito a ser processado pelo agente SE".
   • o cliente licenciado raramente altera as liberações e só está interessado em poder usar o contrato SE se as coisas derem errado, pois elas estão sendo executadas no momento em que as coisas dão errado.

Uma pergunta muito interessante. Supondo que o objetivo de um processo de Custódia de Software é permitir que uma ^Terceira Parte assuma ou nomeie outra parte para cumprir a responsabilidade do fornecedor do software, eu sugeriria os seguintes elementos de um modelo operacional do DevOps que suportaria custódia de software:

1. Infraestrutura como código - a documentação eficaz por meio de uma especificação executável da infraestrutura dependente, armazenada e com versão no controle de origem fornece os ambientes nos quais o código fonte é desenvolvido. Diferentemente da documentação estática nos arquivos de texto, porque é executada regularmente pelo software fornecedor para construir seus próprios ambientes, ele não desatualiza e sofre de "podridão de bits". Isso sempre terá o maior valor quando todo o pipeline de desenvolvimento for construído e mantido no controle de origem, aplicando princípios de infraestrutura como código.

2. Integração contínua - o objetivo da integração contínua é executar um conjunto de etapas que integram a solução regularmente, idealmente a cada alteração. Normalmente, isso significa que, durante o check-in e o envio a um repositório central, um conjunto de testes é executado para validar o processo. De uma perspectiva de garantia de software, eu esperaria que isso também enviasse uma versão funcional para um repositório secundário de "backup", de propriedade e operado por ^terceiros . É importante observar que isso precisa ser legal e financeiramente "desvinculado" do fornecedor do software.

3. Implantação contínua - o objetivo da implantação contínua é fornecer software em um estado de funcionamento com frequência. Neste sentido, a 3 ^rd partido é apenas mais um destino de implementação para implementar as saídas para, embora provavelmente não girando ativamente a infra-estrutura no 3 ^rd partidos tecido.

Algumas outras considerações a serem trazidas para a equação são:

• a mudança da documentação estática para a infraestrutura como código reduz significativamente o trabalho envolvido na atualização da documentação que descreve como instalar, configurar e recuperar o software.
• não se esqueça do gerenciamento de segredos, como certificados X.509, chaves simétricas, senhas e chaves de licença, eles podem ser armazenados no controle de origem, no entanto, isso tem suas próprias desvantagens.

De uma perspectiva de ferramentas, isso dependerá muito do ambiente de desenvolvimento; no entanto, não acredito que existam ferramentas específicas para o depósito de software:

• Desenvolvimento .NET

  • GitHub ou BitBucket para controle de origem
  • AppVeyor , TeamCity ou Jenkins para os elementos de compilação e teste do pipeline.
  • Ansible , Puppet ou Chef para os elementos de gerenciamento de configuração do pipeline.
  • ProGet para os elementos de gerenciamento de pacotes do pipeline
  • Octopus Deploy para os aspectos de implantação do pipeline

• Desenvolvimento Java e, em certa medida, plataformas Open Source

  • CircleCI , TravisCI , TeamCity ou Jenkins para os elementos de compilação e teste do pipeline.
  • Ansible , Puppet ou Chef para os elementos de gerenciamento de configuração do pipeline.
  • JFrog Artifactory ou Sonartype Nexus para os elementos de gerenciamento de pacotes do pipeline
  • Capistrano para os aspectos de implantação do pipeline

No final do dia, se você puder empregar os princípios Infraestrutura como código, Integração Contínua e Implantação Contínua em um pacote de software, ele poderá ser usado para cumprir suas obrigações sob um contrato de Custódia de Software.

Mas para realmente "processar os depósitos SE" (pelos agentes SE), todos os tipos de tarefas de gerenciamento de liberação e / ou entrega de software precisam ser executados por alguém ou alguma coisa (o pobre agente SE) que provavelmente não sabe o que o software licenciado deve fazer ... diversão garantida!

Eu não negociaria com um fornecedor de SE que permitiria a existência de uma situação tão infeliz - eles não sabem o que estão fazendo.

Se os depósitos do SE forem processados ​​de alguma maneira pelo agente do SE, o procedimento de processamento exato e completo precisará ser totalmente documentado nos contratos para que seja realmente utilizável.

Isso também deve incluir a especificação exata do ambiente (ou procedimento para reproduzi-la) e a cadeia de ferramentas usada para esse processamento. Em outras palavras, a escolha não é realmente aberta unilateralmente ao agente SE. Exceto, talvez, a estratégia de armazenamento real (pessoalmente, eu incluiria essa opção também na especificação do contrato, mesmo que a escolha seja feita unilateralmente pelo agente SE).

Um bom contrato de SE também garantiria que todos os depósitos de SE pelo fornecedor passassem por esse processamento e o cliente sempre obtém e qualifica / assina o resultado desse processamento específico, e não um resultado alternativo diretamente do fornecedor - para validar isso. o procedimento em si permanece atualizado e eficaz para cada depósito SE.

Caso contrário, a capacidade de reproduzir as "retiradas do SE" posteriormente (se / quando necessário) é questionável, o que praticamente anula toda a história do SE.