Como implementar a etapa manual no final da entrega contínua?

13

A resposta aceita à minha pergunta sobre " Como a integração contínua se relaciona à entrega / implantação contínua? " Também explica a pequena diferença entre entrega contínua e implantação contínua . Parece estar relacionado à resposta a uma pergunta como "Como você deseja implantar na produção, enquanto estas são as opções (exclusivas) para escolher:

Automático).
Manual.

Não consigo imaginar que exista um "operador" ruim do outro lado do muro do DevOps, que precisará fazer algo que corresponda ao que quer que esse "manual" signifique ... Minhas perguntas:

A minha referência (na minha pergunta) a "distribuir" versus "instalar" está próxima de uma possível implementação de tal coisa "manual"? Aqui está uma citação relevante da minha pergunta relacionada:

distribua para algum ambiente de destino, usando algo como FTP (se as cópias padrão não puderem preencher a lacuna), mas ainda não a ative no destino. É isso que deve ser semelhante / próximo à entrega contínua , ou não?

instalar (ou ativar ) em algum ambiente de destino, combinado com coisas como ligações, operações de parar / iniciar etc. Isso é o que deve ser semelhante / próximo à implantação contínua , ou não?

Quais são as outras implementações possíveis?

continuous-delivery continuous-deployment

— Pierre.Vriens
fonte

Para implantações da AWS, criei um script de upload / deploy ao qual somente o gerente da equipe tem acesso. Portanto, para implantar na produção, o gerente da equipe precisa executar o script.

— Turtle

Desculpe por quebrar seus sonhos, mas ainda temos uma equipe de 'deploy', que a Oek lançará atualizações de banco de dados no Db2-iSeries com o ARCAD e, em seguida, chef nos servidores Tomcart para implantar versões em produção a cada 2 quinta-feira, entre 20h e meia-noite. Então, infelizmente, às vezes há um operador de pobres (que não é esperançosamente seu único trabalho)

— Tensibai

5

Pessoalmente, considero o distributionsoftware como um destino apenas uma etapa intermediária de uma implantação - a instalação / ativação desse software é necessária para concluir essa implantação.

Para mim, o delivery(como em continuos delivery) para quando o software a ser implantado é criado e disponibilizado para implantação (ou seja, para distribuição, instalação e ativação)

Portanto, para responder à sua 1ª pergunta, não, eu não consideraria a distribuição e instalação como um reflexo da etapa manual que diferencia a entrega contínua da implantação contínua.

Sim, em alguns casos (espero que seja raro), essa etapa manual é apenas a decisão humana final para implantar na produção, refletindo a desconfiança cultural na automação de processos e o conforto mental de ter um humano checando e assinando a decisão de implantação (assumindo assim responsabilidade por isso), mesmo que essa decisão seja puramente tomada com base em um algoritmo que pode ser automatizado (como contar os resultados dos testes aprovados / reprovados).

Mas, em geral, simplesmente reflete o fato de que a decisão de executar a implantação na produção não é simplesmente o resultado de um algoritmo automatizado. Aqui estão alguns exemplos desses casos:

a decisão automatizada é substituída
- a implantação pode ser assinada mesmo que nem todos os critérios de qualidade sejam atendidos (todos sabemos que esse não é apenas um caso teórico)
- a implantação é realizada por qualquer motivo, mesmo se todos os critérios forem atendidos (devido a implicações de tempo de mercado, por exemplo)
o algoritmo automatizado ainda não está implementado / implantado
o algoritmo inclui verificações de alguns critérios, dependendo das decisões humanas (por exemplo, resultados de testes manuais)
a implantação é realmente feita em um ambiente de cliente de terceiros, após verificações adicionais do cliente

Portanto, eu não consideraria a etapa manual simplesmente como um problema de implementação.

— Dan Cornilescu
fonte

Merci (obrigado: obrigado) por compartilhar seus pontos de vista sobre isso. Parece que temos uma percepção diferente de "distribuição". Então, deixe-me adicionar um cenário: você tem uma janela de 1 hora, para um sistema bancário on-line, no início da manhã de domingo, para "ativar" 150.000 executáveis atualizados. E, por qualquer motivo, uma reversão seria necessária, nenhuma negociação seria possível para estender essa janela. Deseja realmente desperdiçar seu tempo em "distribuir", em vez de usar o tempo necessário para isso "apenas no caso de reversão ser necessária? Pense duas vezes: se demorar mais de uma hora ... você está demitido ... Bem ???

— Pierre.Vriens

Isso é IMHO apenas um detalhe de otimização ou implementação da própria implantação, aplicável no seu caso (mas isso não a torna uma regra). Só porque você está executando parte de sua implantação antes de realmente desligar a antiga execução sw, não significa que o respectivo trabalho faça parte do estágio de entrega. Também não significa necessariamente que, uma vez iniciada a implantação, você também precisa concluí-la.

— Dan Cornilescu

2

Uma consideração adicional se você estiver publicando algo que espera que outros projetos consumam, a implantação também assume o significado de "publicação para uso de outras pessoas"

Considere um fluxo de trabalho em que você implanta uma biblioteca em um repositório de artefato comum. Essa parte do processo pode ser parte da implementação de outro componente que requer esse artefato no momento da construção ou pode ser simplesmente uma atualização para uma biblioteca comum. Porém, independentemente disso, para esse artefato, seu ciclo de vida não termina necessariamente ao ser disponibilizado para consumo por outras pessoas, mas a implantação desse artefato no repositório de artefatos pode ser o estágio final do trabalho dos desenvolvedores após a decisão de cortar um nova versão de lançamento e antes que outros possam consumir com segurança a nova versão.

— hvindin
fonte