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

7

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 (relacionados 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 deferramentas 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.
Pierre.Vriens
fonte

Respostas:

4

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:

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.

Richard Slater
fonte
O que exigiria Capistrano em cima do boneco ou chef?
Tensibai 24/03
Resposta impressionante, eu preciso digeri-lo mais algumas vezes. Mas, por enquanto, esses comentários / pensamentos estão constantes: (1) quem você quer dizer com "fornecedor" (você pode tentar usar "fornecedor de software" ou "agente SE" para esclarecer isso)? (2) "segredos", neste caso, seriam as chaves de licença (considere também partes do código, por exemplo, contendo IDs de PU, etc.) (3) Como ITer, concordo com a recomendação "contínua". No entanto, "depósitos contínuos" também implicariam "faturas contínuas" (= não acessíveis), então ainda não tenho certeza de como a "liberação" (como 1 a cada 6 meses) se encaixa nisso
Pierre.Vriens
@Tensibai: do jeito que eu vejo isso, o Capistrano é uma ferramenta de implantação com capacidade de gerenciamento de configuração; O Ansible é uma ferramenta de gerenciamento de configuração com um recurso de implantação ... só porque você pode usar uma ferramenta para realizar as duas tarefas não significa que você deveria .
Richard Slater
@ Pierre.Vriens - Eu tentei abordar o seu ponto 1 e o ponto 2 . O ponto 3 , no entanto, pode precisar de um pouco mais de contribuição, fundamentalmente o setor está mudando se um agente da SE estiver sugerindo que cada depósito resulte em uma fatura; respeitosamente, eles precisam visitar novamente seu modelo de custo. As conseqüências deles não fazerem isso é a diferença entre prosperar em um mundo DevOps e desaparecer na obsolescência.
Richard Slater
Esta postagem do blog é um pouco antiga e não leva em conta alguns recursos do chef , aqui implantados inspirados no Capistrano. Ainda não significa que você deve ou não, mas não vale a pena uma palavra sobre isso IMHO
Tensibai
1

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.

Dan Cornilescu
fonte
Merci Dan por esta resposta. Eu concordo com (a maior parte) o que você escreveu, mas parece que você não levou em consideração minha "nota 1". Sua resposta aqui parece relacionada a uma (nova) pergunta como "Quais são os níveis típicos de verificação oferecidos nos contratos SE (e como selecionar um)?". FYI: IMO há 3 níveis ... Não tenho certeza se eu deveria postar que algum dia como uma auto respondeu à pergunta ...
Pierre.Vriens
Eu vi a nota 1, mas se a aplicar, não vejo como a pergunta faz sentido :) Se não houver um pipeline de processamento, para que o conjunto de ferramentas devops é usado? Exceto, talvez, o CRM / armazenamento (minha resposta também é importante).
Dan Cornilescu 26/03
Não sabe ao certo o que você quer dizer com esse CRM no seu comentário (você pode tentar novamente?). Além disso, imagine que o agente SE (pobre) aceite depósitos no formato de CDs que são entregues fisicamente em seus escritórios (por exemplo, 1 a 3 CDs por ano para um fornecedor de software "a" e existem algumas dezenas desses fornecedores de software) . Se o agente SE o contratasse para modernizar essa abordagem desatualizada, introduzindo procedimentos compatíveis com o DevOps, o que você recomendaria?
Pierre.Vriens
@ Pierre.Vriens Desculpe, siglas misturadas. Não é CRM. Eu quis dizer repositório de artefatos / armazenamento.
Dan Cornilescu 26/03
@ Pierre.Vriens Se receber o CD é o que está no contrato, armazenar e recuperar CDs (ou imagens de CD) é praticamente tudo o que existe. Se é mais do que isso, mas não envolve processamento - não tenho certeza do que é isso. Se o processamento permanecer sobre a mesa - há muito o que fazer. No extremo, você pode considerar todas as três partes do contrato de SE envolvidas no pipeline de entrega de sw, que produz sw que é garantido para manter a manutenção, mesmo em um evento catastrófico de fornecedor.
Dan Cornilescu 26/03