Qual é a diferença entre esses três termos? Minha universidade fornece as seguintes definições:

A integração contínua basicamente significa que as cópias de trabalho do desenvolvedor são sincronizadas com uma linha principal compartilhada várias vezes ao dia.

A entrega contínua é descrita como a evolução lógica da integração contínua: sempre seja possível colocar um produto em produção!

A implantação contínua é descrita como a próxima etapa lógica após a entrega contínua: implante automaticamente o produto em produção sempre que ele passar no controle de qualidade!

Eles também fornecem um aviso: Às vezes, o termo "Implantação Contínua" também é usado se você puder implantar continuamente no sistema de teste.

Tudo isso me deixa confusa. Qualquer explicação um pouco mais detalhada (ou que vem com um exemplo) é apreciada!

Integração contínua

Concordo com a definição da sua universidade. Integração Contínua é uma estratégia de como um desenvolvedor pode integrar código à linha principal continuamente - em vez de frequentemente.

Você pode alegar que é apenas uma estratégia de ramificação no seu sistema de controle de versão.

Tem a ver com o tamanho das tarefas que você atribui a um desenvolvedor; Se uma tarefa for estimada em 4-5 dias úteis, o desenvolvedor não terá incentivo para entregar nada pelos próximos 4-5 dias, porque ainda não terminou nada.

Então o tamanho importa:

small task = continuous integration
big task   = frequent integration

O tamanho ideal da tarefa não é maior que o dia de trabalho. Dessa forma, um desenvolvedor naturalmente terá pelo menos uma integração por dia.

Entrega Contínua

Existem basicamente três escolas na Entrega Contínua:

Entrega contínua é uma extensão natural da integração contínua

Esta escola examina a série de assinaturas "Martin Fowler" de Addison-Wesley e assume que desde o lançamento de 2007 foi chamado de "Integração Contínua" e o que se seguiu em 2011 foi chamado de "Entrega Contínua" , provavelmente são de volume 1 + 2 da mesma idéia conceitual que tem a ver com algo contínuo .

Entrega contínua tem a ver com desenvolvimento ágil de software

Essa escola se diverte com a ideia de que a Entrega Contínua é capaz de apoiar os princípios do movimento ágil, não apenas como uma idéia conceitual ou uma carta de intenções, mas para real - na vida real.

Compensando o primeiro princípio do Manifesto Ágil, em que o termo "entrega contínua" é realmente usado pela primeira vez:

Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso.

Esta escola alega que "Entrega Contínua" é um paradigma que abrange tudo o que é necessário para implementar uma verificação automatizada da sua "definição de pronto" .

Essa escola aceita que "Entrega Contínua" e a palavra popular ou megatendência "DevOps" são lados opostos da mesma moeda, no sentido de que ambos tentam abraçar ou encapsular esse novo paradigma ou abordagem, e não apenas uma técnica.

Entrega Contínua é sinônimo de Implantação Contínua

A terceira escola defende que a implantação contínua e a entrega contínua podem ser usadas de forma intercambiável para significar a mesma coisa.

Quando algo está pronto nas mãos dos desenvolvedores, ele é entregue imediatamente aos usuários finais, o que na maioria dos casos significa que ele deve ser implantado no ambiente de produção. Portanto, "implantar" e "entregar" significa o mesmo.

Qual escola participar

Sua universidade ingressou claramente na primeira escola e afirma que estamos nos referindo ao volume 1 + 2 da mesma série de publicações. Minha opinião é que este é um uso indevido do termo Entrega Contínua.

Eu, pessoalmente, defendo o entendimento de que a Entrega Contínua está relacionada à implementação de um suporte na vida real para as idéias e conceitos declarados pelo movimento ágil. Então entrei na escola que diz que o termo abrange todo um paradigma - como "DevOps".

A escola que usa entrega como sinônimo de implantação é defendida principalmente por fornecedores de ferramentas que criam consoles de implantação, tentando obter um pouco de hype pelo uso mais difundido do termo Entrega Contínua .

Implantação Contínua

O foco na Implantação Contínua é principalmente relevante em domínios em que o acesso do usuário final a atualizações de software depende da atualização de alguma fonte centralizada para essas informações e onde essa fonte centralizada nem sempre é fácil de atualizar porque é monolítica ou tem (muito) alta coerência por natureza (web, SOA, bancos de dados etc.).

Para muitos domínios que produzem software em que não há fonte centralizada de informações (dispositivos, produtos de consumo, instalações de clientes etc.) ou onde a fonte centralizada de informações é fácil de atualizar (lojas de aplicativos, sistemas de gerenciamento de artefatos, repositórios de código aberto etc.) ), quase não há exageros sobre o termo Implantação Contínua. Eles apenas implantam; não é grande coisa - não é uma dor que requer foco especial.

O fato de a Implantação Contínua não ser algo genericamente interessante para todos também é um argumento de que a escola que afirma que "entrega" e "implantação" são sinônimos entendeu tudo errado. Porque a Entrega Contínua realmente faz todo o sentido, mesmo que você esteja desenvolvendo software incorporado em dispositivos ou lançando plugins de Código Aberto para uma estrutura.

A definição da sua universidade de que a Implantação Contínua é um próximo passo natural da Entrega Contínua supõe implicitamente que toda entrega com controle de qualidade deve ser disponibilizada imediatamente aos usuários finais, está mais próxima da definição que minha tribo usa para descrever o termo "Contínua Release ", que, por sua vez, é outro conceito que também não faz sentido para todos.

Um lançamento pode ser uma coisa muito estratégica ou política e não há razão para supor que todo mundo queira fazer isso o tempo todo (a menos que seja uma livraria on-line ou um tipo de empresa de serviço de streaming). No entanto, as empresas que não divulgam tudo cegamente o tempo todo podem ter inúmeras razões para quererem ser mestres na implantação, de modo que também fazem a implantação contínua . Não de liberação para produção, mas de candidatos a liberação para ambientes semelhantes a produção .

Mais uma vez, acredito que sua universidade entendeu errado. Eles estão confundindo "Implantação contínua" com "Liberação contínua".

A implantação contínua é simplesmente a disciplina de poder mover continuamente o resultado de um processo de desenvolvimento para um ambiente semelhante à produção, onde os testes funcionais podem ser executados em grande escala.

A história da entrega contínua

Na imagem, tudo ganha vida:

O processo de Integração Contínua é as duas primeiras ações no diagrama de transição de estado. que - se for bem-sucedido - inicia o pipeline de Entrega Contínua que implementa a definição de concluído . A implantação é apenas uma das muitas ações que deverão ser realizadas continuamente neste pipeline. Idealmente, o processo é automatizado a partir do ponto em que o desenvolvedor se compromete com o VCS até o ponto em que o pipeline confirmou que temos um candidato à liberação válido.

Nem a pergunta nem as respostas realmente se encaixam na minha maneira simples de pensar sobre isso. Sou consultor e sincronizei essas definições com várias equipes de desenvolvimento e pessoal de desenvolvimento, mas estou curioso para saber como ele combina com o setor em geral:

Basicamente, penso na prática ágil de entrega contínua como um continuum:

Não contínuo (tudo manual) 0% ----> 100% Entrega contínua de valor (tudo automatizado)

Passos para entrega contínua:

Zero. Nada é automatizado quando os desenvolvedores fazem check-in do código ... Você tem sorte se eles compilaram, executaram ou executaram qualquer teste antes do check-in.

1. Criação contínua: criação automatizada em cada check-in, que é o primeiro passo, mas não faz nada para provar a integração funcional do novo código.

2. Integração Contínua (IC): criação e execução automatizadas de pelo menos testes de unidade para provar a integração do novo código ao código existente, mas de preferência testes de integração (ponta a ponta).

3. Implantação contínua (CD): implantação automatizada quando o código passa o IC pelo menos em um ambiente de teste, de preferência em ambientes mais altos quando a qualidade é comprovada por meio do CI ou pela marcação de um ambiente inferior como PASSADO após o teste manual. IE, o teste pode ser manual em alguns casos, mas a promoção para o próximo ambiente é automática.

4. Entrega Contínua: publicação e liberação automatizadas do sistema em produção. Trata-se de um CD em produção, além de outras alterações na configuração, como instalação para testes A / B, notificação aos usuários de novos recursos, notificação de suporte a nova versão e notas de alteração, etc.

EDIT: Gostaria de ressaltar que há uma diferença entre o conceito de "entrega contínua", conforme mencionado no primeiro princípio do Manifesto Ágil ( http://agilemanifesto.org/principles.html ) e a prática da Entrega Contínua, como parece ser referenciado pelo contexto da pergunta. O princípio da entrega contínua é o de tentar reduzir o desperdício do Inventário, conforme descrito no pensamento Lean ( http://www.miconleansixsigma.com/8-wastes.html ). A prática da Entrega Contínua (CD) por equipes ágeis surgiu nos muitos anos desde que o Manifesto Ágil foi escrito em 2001. Essa prática ágil aborda diretamente o princípio, embora sejam coisas diferentes e aparentemente facilmente confusas.

Eu acho que a definição da Amazon é direta e simples de entender.

" A entrega contínua é uma metodologia de desenvolvimento de software em que o processo de liberação é automatizado. Toda alteração de software é criada, testada e implantada automaticamente na produção. Antes do envio final à produção, uma pessoa, um teste automatizado ou uma regra de negócios decide quando o Embora seja necessário liberar imediatamente todas as alterações de software bem-sucedidas para produção com entrega contínua, nem todas as alterações precisam ser lançadas imediatamente.

A integração contínua é uma prática de desenvolvimento de software em que os membros de uma equipe usam um sistema de controle de versão e integram seu trabalho frequentemente ao mesmo local, como uma filial principal. Cada alteração é criada e verificada por testes e outras verificações para detectar erros de integração o mais rápido possível. A integração contínua é focada na criação e teste de código automaticamente, em comparação com a entrega contínua, que automatiza todo o processo de liberação do software até a produção ".

Confira http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

Atlassian postou uma boa explicação sobre Integração contínua vs. entrega contínua vs. implantação contínua .

Em poucas palavras:

Integração Contínua - é uma automação para criar e testar aplicativos sempre que novas confirmações são enviadas para a filial.

Entrega Contínua - é a Integração Contínua + Implanta o aplicativo na produção "clicando em um botão" (a liberação para os clientes é frequentemente, mas sob demanda).

Implantação Contínua - é Entrega Contínua, mas sem intervenção humana (a liberação para os clientes está em andamento).

A integração contínua basicamente significa que as cópias de trabalho do desenvolvedor são sincronizadas com uma linha principal compartilhada várias vezes ao dia.

Ou mais do que várias vezes por dia. Frequentemente, qualquer tarefa discreta é concluída, basicamente. Considere, por exemplo, uma equipe de desenvolvedores trabalhando em um único aplicativo de negócios. Em muitos ambientes, pode acontecer o seguinte:

• Um ou dois desenvolvedores mantêm alterações locais por alguns dias porque "ainda não está pronto".
• Um ou dois desenvolvedores criam ramificações no controle de origem para que possam trabalhar em seus recursos "sem serem incomodados pelas alterações de outras pessoas".

Isso pode levar a problemas. Organização pobre de código / tarefa leva à ramificação, ramificação leva à fusão, fusão ... leva ao sofrimento. A integração contínua como prática aborda isso, incentivando todos a trabalhar na mesma fonte compartilhada. Itens de trabalho individuais devem ser discretos o suficiente para serem concluídos em um curto período de tempo (no máximo horas).

Basicamente, a ideia geral é integrar uma pequena mudança em uma pequena quantidade de trabalho. Integrar uma grande mudança é uma quantidade desproporcionalmente grande de trabalho. O agregado do trabalho de integração é menor se realizado em pequenas etapas constantes. Isso permite que os desenvolvedores passem mais tempo trabalhando em recursos visíveis nos negócios em vez de sobrecarga no processo de desenvolvimento.

A entrega contínua é descrita como a evolução lógica da integração contínua: sempre seja possível colocar um produto em produção!

Isso segue a mesma ideia de itens de trabalho discretos e bem definidos. Se houver uma única base de código mestre que só é ajustada em pequenos incrementos por recursos de trabalho completos, testados e conhecidos, essa base de código é sempre estável. O teste automatizado é a chave aqui para poder provar essa estabilidade ao pressionar um botão.

Quanto menos trabalho de estabilização precisar ser realizado (que, mais uma vez, é uma sobrecarga do processo de desenvolvimento e deve ser eliminado), mais frequentemente essa base de código pode ser enviada para qualquer ambiente. Em muitas empresas, uma implantação pode ser um processo bastante desgastante. Mesmo uma operação de uma semana, com as mãos no convés. Isso é caro e não produz valor comercial. Ao empregar boas definições de itens de trabalho, testes automatizados eficazes e integração contínua, uma equipe pode estar em posição de automatizar a entrega da base de código em qualquer ambiente.

A implantação contínua é descrita como a próxima etapa lógica após a entrega contínua: implante automaticamente o produto em produção sempre que ele passar no controle de qualidade!

Você raramente vê isso acontecer em um ambiente de negócios, e é uma alegria quando é encontrado. Se a base de código puder ser testada e implantada automaticamente em qualquer ambiente, então, a produção será um ambiente como outro qualquer. Portanto, se a equipe acumular até esse ponto, há um potencial de valor significativo para os negócios, sempre podendo implantar atualizações na produção.

Correções de defeitos são enviadas aos clientes mais rapidamente, novos recursos chegam ao mercado mais rapidamente, novas idéias são testadas em relação ao mercado em incrementos menores para permitir o redirecionamento de prioridades etc.

Por exemplo, digamos que uma empresa tenha uma grande idéia para um novo recurso em seus produtos ou serviços baseados em software. Eles fizeram algumas pesquisas, conhecem o mercado e acreditam que essa ideia resultará em uma nova e forte linha de receita. Agora considere duas opções para fornecer esse recurso:

1. Passe meses desenvolvendo tudo em um ramo único. Passe semanas integrando-o de volta à base de código principal. Passe dias testando-o. Passe um dia implantando-o. E só então comece a rastrear a receita real no sistema de produção.
2. Implemente pequenas partes do recurso, uma de cada vez. A cada semana, libere uma nova peça. A cada semana, obtenha mais dados sobre a receita real.

No primeiro cenário, se o recurso não tiver o efeito de mercado desejado, muito dinheiro será desperdiçado em algo que os clientes realmente não desejam. No segundo cenário, o fato de os clientes não quererem é determinado muito, muito mais cedo e o restante do trabalho é priorizado.

Em última análise, essas "coisas contínuas" são sobre remover as despesas gerais do processo de desenvolvimento. Se a linha de receita de uma empresa é uma oferta de serviço específica, idealmente todos os seus custos devem ser incluídos nessa oferta. As despesas gerais do processo de desenvolvimento (mesclar código, testar novamente os mesmos recursos após uma mesclagem, tarefas de implantação manual etc.) não contribuem realmente para o valor do serviço; portanto, esses conceitos buscam remover esses custos do processo.

Um gráfico pode substituir muitas palavras:

Aproveitar! :-)

# Atualizei a imagem correta ...

Diferença entre integração contínua, entrega contínua e implantação contínua

Acho que estamos analisando demais e talvez complicando um pouco o conjunto "contínuo" de palavras. Nesse contexto, contínuo significa automação. Para as outras palavras anexadas a "contínuo", use o idioma inglês como guia de tradução e não tente complicar as coisas! Em "build contínuo", automaticamente criamos (escrevemos / compilamos / vinculamos / etc) nosso aplicativo em algo executável para uma plataforma / container / tempo de execução / etc específicos. "Integração contínua" significa que sua nova funcionalidade testa e executa como pretendido ao interagir com outra entidade. Obviamente, antes que a integração ocorra, a construção deve ocorrer e testes completos também serão usados ​​para validar a integração. Então, na "integração contínua" usa-se a automação para agregar valor a um bloco de funcionalidades existente de uma maneira que não perturbe negativamente a funcionalidade existente, mas se integre perfeitamente a ela, agregando um valor percebido ao todo. A integração implica, por sua mera definição em inglês, que as coisas fluem harmoniosamente; portanto, em conversas de código, meu add compila, vincula, testa e roda perfeitamente dentro do todo. Você não chamaria algo de integrado se falhasse no produto final, não é? Em nosso contexto, "implantação contínua" é sinônimo de "entrega contínua", pois no final do dia fornecemos funcionalidade aos nossos clientes. No entanto, analisando mais isso, eu poderia argumentar que implantar é um subconjunto de entrega porque implantar algo não significa necessariamente que nós entregamos. Nós implantamos o código, mas porque não temos ' t efetivamente comunicados aos nossos stakeholders, não conseguimos entregar da perspectiva dos negócios! Destacamos as tropas, mas não entregamos a água e a comida prometidas na cidade vizinha. E se eu adicionasse o termo "transição contínua", ele teria seu próprio mérito? Afinal, talvez seja mais adequado descrever o movimento do código nos ambientes, pois possui a conotação de "de / para" mais do que implantação ou entrega, o que poderia implicar apenas um local, em perpetuidade! É isso que obtemos se não aplicarmos o bom senso. teria seu próprio mérito? Afinal, talvez seja mais adequado descrever o movimento do código nos ambientes, pois possui a conotação de "de / para" mais do que implantação ou entrega, o que poderia implicar apenas um local, em perpetuidade! É isso que obtemos se não aplicarmos o bom senso. teria seu próprio mérito? Afinal, talvez seja mais adequado descrever o movimento do código nos ambientes, pois possui a conotação de "de / para" mais do que implantação ou entrega, o que poderia implicar apenas um local, em perpetuidade! É isso que obtemos se não aplicarmos o bom senso.

Em conclusão, isso é algo simples de descrever (fazê-lo é um pouco mais ... complicado!), Basta usar o bom senso, o idioma inglês e você ficará bem.

Integração contínua: A prática de mesclar o desenvolvimento trabalha constantemente com o ramo principal, para que o código seja testado o mais rápido possível para detectar problemas mais cedo.

Entrega Contínua: entrega contínua de código para um ambiente assim que o código estiver pronto para envio. Isso pode ser uma preparação ou produção. A idéia é que o produto seja entregue a uma base de usuários, que podem ser QAs ou clientes para revisão e inspeção.

O teste de unidade durante a fase de Integração Contínua não pode capturar todos os bugs e lógica de negócios, principalmente os problemas de design e é por isso que precisamos de controle de qualidade ou ambiente de teste para teste.

Implantação contínua: a implantação ou liberação do código assim que estiver pronto. A implantação contínua requer integração contínua e entrega contínua, caso contrário, a qualidade do código não será garantida em uma liberação.

Implantação Contínua ~~ Integração Contínua + Entrega Contínua

Integração contínua

• Automatizado (criação de check-ins + teste de unidade)

Entrega Contínua

• Integração contínua
• Automatizado (implantação no ambiente de teste + teste de carga + teste de integração)
• Manual (implantação na produção)

Implantação Contínua

• Entrega contínua, mas automatizada (implantação na produção)

CI / CD é uma jornada. Não é um destino.

Essas etapas são sugestões. Você pode adaptar os estágios com base nas suas necessidades comerciais. Alguns estágios podem ser repetidos para vários tipos de teste, segurança e desempenho. Dependendo da complexidade do seu projeto e da estrutura de suas equipes, algumas etapas podem ser repetidas várias vezes em diferentes níveis. Por exemplo, o produto final de uma equipe pode se tornar uma dependência no projeto da próxima equipe. Isso significa que o produto final da primeira equipe é posteriormente preparado como um artefato no projeto da próxima equipe.

Nota de rodapé:

Praticando integração contínua e entrega contínua na AWS

Fonte: https://thenucleargeeks.com/2020/01/21/continuous-integration-vs-continuous-delivery-vs-continuous-deployment/

O que é Integração Contínua A Integração Contínua é um processo ou uma prática de desenvolvimento de compilação e teste automatizados, isto é, é necessário que um desenvolvedor comprometa seu código várias vezes em um repositório compartilhado, onde cada integração é verificada por compilação e teste automatizados.

Se a construção falhar / for bem-sucedida, ela será notificada a um desenvolvedor e ele poderá executar ações relevantes.

O que é Entrega Contínua A Entrega Contínua é a prática em que mantemos nosso código implantável a qualquer momento que tenha passado em todos os testes e possua toda a configuração necessária para enviar o código à produção, mas ainda não foi implantado.

O que é implantação contínua Com a ajuda da CI, criamos o build para nosso aplicativo e estamos prontos para avançar para a produção. Nesta etapa, nossa compilação está pronta e, com o CD, podemos implantar nosso aplicativo diretamente no ambiente de controle de qualidade e, se tudo correr bem, podemos implantar a mesma compilação na produção.

Então, basicamente, a implantação contínua é um passo além da entrega contínua. Com essa prática, todas as alterações que passam em todos os estágios do seu pipeline de produção são liberadas para seus clientes.

A Implantação Contínua é uma combinação de Gerenciamento de Configuração e Containerização.

Gerenciamento de configuração: o CM trata da manutenção da configuração do servidor que será compatível com os requisitos do aplicativo.

Containerização : a containerização é um conjunto de pedágios que manterá a consistência em todo o ambiente.

Fonte da imagem: https://www.atlassian.com/

O DevOps é uma combinação dos 3Cs - contínua , comunicação , colaboração e isso leva ao foco principal em vários setores.

Em um mundo de dispositivos conectados à IoT, vários recursos de scrum, como proprietário do produto, web, dispositivos móveis e controle de qualidade, trabalham de maneira ágil em um ciclo de scrum do scrum para entregar um produto ao cliente final.

Integração contínua: recurso de scrum múltiplo trabalhando simultaneamente em vários pontos de extremidade

Entrega contínua: com integração e implantação, entrega do produto a vários clientes para ser tratada ao mesmo tempo.

Implantação contínua: vários produtos implantados em vários clientes em várias plataformas.

Assista a isto para saber como o DevOps está habilitando o mundo conectado à IoT: https://youtu.be/nAfZt2t4HqA

Pelo que aprendi com Alex Cowan no curso Entrega Contínua e DevOps , o CI e o CD fazem parte de um pipeline de produtos que consiste no tempo que passa de uma Observação para um Produto Lançado.

Das observações aos projetos, o objetivo é obter idéias testáveis ​​de alta qualidade. Essa parte do processo é considerada Design Contínuo .

O que acontece depois, quando seguimos a partir do Código, é considerado um recurso de Entrega Contínua cujo objetivo é executar as idéias e liberar para o cliente muito rapidamente (você pode ler o livro Entrega Contínua de Jez Humble : Liberação Contínua de Software: Versões Confiáveis ​​de Software por Compilação, Teste, e automação de implantação para obter mais detalhes). O pipeline a seguir explica em quais etapas a Integração Contínua (IC) e a Entrega Contínua (CD) consistem.

Integração contínua , como Mattias Petter Johansson explica ,

é quando uma equipe de software tem o hábito de fazer várias mesclagens por dia e possui um sistema de verificação automatizado para verificar se há problemas.

(você pode assistir aos dois vídeos a seguir para obter uma visão geral mais prática usando o CircleCI - Introdução ao CircleCI - Continuous Integration P2 e Executando o CircleCI na solicitação de recebimento ).

Pode-se especificar o pipeline de CI / CD da seguinte forma, que vai de Novo Código a um Produto lançado.

Os três primeiros passos têm a ver com testes, estendendo os limites do que está sendo testado.

Implantação Contínua , por outro lado, é manipular a Implantação automaticamente. Portanto, qualquer confirmação de código que passa na fase de teste automatizado é automaticamente liberada na produção.

Nota : Isso não é necessariamente o que seus pipelines devem ter, mas eles podem servir como referência.

vamos mantê-lo breve:

CI: Uma prática de desenvolvimento de software em que membros de uma equipe integram seu trabalho pelo menos diariamente. Cada integração é verificada por compilação automatizada (inclui testes) para detectar erros o mais rápido possível. CD: CD Baseia-se no IC, em que você cria o software de forma que o software possa ser liberado para produção a qualquer momento.