O que é Integração Contínua (IC) e como é útil? [fechadas]

Alguém pode me explicar o conceito de integração contínua, como funciona de uma maneira fácil de entender? E por que uma empresa deve adotar o IC em seu fluxo de trabalho de entrega de código? Sou desenvolvedor e minha empresa (principalmente a equipe de criação) usa o Team City. Como desenvolvedor, sempre faço check-out, atualizo e confirmo o código no SVN, mas nunca tive que me preocupar com o TeamCity ou o CI em geral. Então, eu gostaria de entender qual é a utilidade da CI? O CI faz parte das metodologias ágeis?

A integração contínua em poucas palavras significa que você salva seu trabalho, envia-o para o sistema de gerenciamento de documentos (SVN no seu caso), todos os testes são executados automaticamente (testes de unidade, integração, funcionais etc.) e o aplicativo é compilado e preparado para entrega (ou seja, a imagem ISO é criada). A integração contínua não é a mesma coisa com a entrega contínua. A entrega ainda é feita em diferentes momentos. A CI garante que o produto possa ser entregue, se necessário, nada mais.

Sempre que algo der errado, a equipe recebe uma notificação. Normalmente, nesse ponto, todo o trabalho é interrompido e todos os esforços são concentrados em garantir que o produto esteja de maneira estável. Nenhum envio e confirmação acontecem no repositório enquanto o sistema não está verde.

O IC garante que o produto esteja sempre em um estado estável e possa ser entregue a qualquer momento. Observe que estável não significa recurso completo. Também pode haver recursos semi-implementados, mas o sistema pode ser estável.

O IC geralmente está associado a metodologias ágeis, mas eu não conheço pessoalmente o histórico exato do IC.

Integração contínua significa: integrar o código em um produto que realmente é executado e pode ser testado acontece o tempo todo , não (como anteriormente era o caso) como uma atividade separada no final do ciclo de vida do desenvolvimento.

Requer que o processo de criação do aplicativo seja completamente automatizado, e um conjunto de testes automatizado e um servidor que construa o estado atual do código e execute o conjunto de testes nele. Isso deve acontecer diariamente ou mesmo após o check-in de cada código.

A vantagem é que há feedback imediato sobre alterações de código que causam erros de compilação (por exemplo, porque o desenvolvedor falhou ao verificar todas as alterações ou usa algum componente não presente no sistema de compilação) ou falhas nos casos de teste. Isso facilita muito a correção desses erros, pois você sabe qual alteração os causou e a pessoa responsável ainda tem novas lembranças do que eles fizeram.

Sem o IC, todos esses erros surgem juntos ao mesmo tempo durante o estágio de integração, o que os torna extremamente difíceis de corrigir.

Você pode ter um certo estilo de desenvolvimento: você faz checkout, codifica, compila, verifica, amaldiçoa, altera, compila, torce, confirma. Você só confirma o código de trabalho, talvez até de maneira menos granular, como no final do dia de trabalho ou quando um recurso é concluído. Você verifica suas dependências sempre que importa as bibliotecas de API.

Quando você começa a codificar junto com outras pessoas e quando há dependências mútuas, faz sentido adotar a integração contínua. Simplesmente porque você não pode conhecer o impacto das alterações nas pessoas que dependem do seu código e não recebe sinal toda vez que precisar atualizar suas importações.

Portanto, quando um de vocês faz uma alteração, os dois projetos devem ser construídos e testados juntos, ou seja, executados na API um do outro, construídos e testados com a nova biblioteca etc. Esses testes, seu código e o de outra pessoa, são chamados de testes de integração.

Por que contínuo? Porque é mais fácil delegar a coordenação da integração a um sistema que testa uma compilação limpa sempre que houver uma alteração em qualquer base de código do que organizar tudo isso para um humano. O sistema é capaz de escalar.

Existem dois aspectos na integração contínua.

1. A estratégia de controle da fonte de desenvolvimento, garantindo que os desenvolvedores possam integrar continuamente seu trabalho contínuo com o código estável de outros desenvolvedores.
2. A construção e o teste automáticos do código-fonte acionados por uma confirmação ao controle de origem

O ponto 1 é crítico. É a decisão de fazer com que as fusões que os desenvolvedores realmente executam sejam freqüentes, e de natureza pequena que torna muito mais provável que as fusões sejam bem-sucedidas.

O ponto 2 é as ferramentas e a estrutura necessárias para permitir que o ponto 1 ocorra com segurança, identificando rapidamente mesclagens que falharam ao quebrar o código existente.

Quão útil é isso?

Incrivelmente. Como desenvolvedor que trabalha em um projeto, permite que você gaste a maior parte do tempo concentrando-se no que está fazendo, e não se preocupe com o trabalho simultâneo do restante da equipe. Quando seu trabalho atual estiver concluído, você publicará suas alterações no restante da equipe e, nas próximas horas, todos eles mesclarão suas alterações no trabalho atual.

Sem isso, os desenvolvedores estão fazendo mesclagens de big bang. Normalmente, leva vários dias de trabalho e precisa mesclá-lo com todas as alterações feitas pelo resto da equipe de uma só vez. Quando uma mesclagem fica visivelmente ruim, o outro desenvolvedor provavelmente terá migrado para outro trabalho e estará começando a esquecer os detalhes para ajudar a desfazer a bagunça da mesclagem. Pior ainda, sem a criação e o teste contínuos, desde que o código seja compilado, os bugs de mesclagem podem aparecer no código e não serão detectados até que os testes (ou clientes) os encontrem.

O IC é útil quando você tem:

• Compilação de código
• Conjunto real de testes
• Relatórios baseados em seu código-fonte (cobertura de código, violência dos padrões de código etc.)
• Rotina que você executa periodicamente, após o código compilado com sucesso

A lista pode ser continuada.