Automação de compilação versus automação de implantação versus integração contínua

Eu quero me tornar mais eficiente e quero usar as ferramentas de operações com eficiência.

Com isso em mente, eu queria aprender mais sobre a integração contínua, mas parece que há muitas coisas diferentes a respeito.

Na verdade, estou trabalhando com trajes Jetbrains no meu trabalho (IntelliJ, WebStorm ...), então eu queria continuar usando-os e queria usar o TeamCity, que parecia ser uma ótima ferramenta com muitos plugins para integração contínua.

Meu problema é que não sei quais são as diferenças entre:

• automação predial (TeamCity é esse tipo de software): Eu sei que podemos construir nosso aplicativo com um repositório VCS remoto e é ótimo, mas qual é o principal objetivo disso? Que tipo de informação é importante ao fazer isso? Na verdade, eu já sei se meu software cria ou não localmente e também meus colegas de equipe. Então, qual é o objetivo de usá-lo sem implantar a automação?

• implantação de automação (o TeamCity parece não fazer isso facilmente)

• integração contínua (que parece ser uma conjunção dos dois acima)
• entrega contínua (o que é isso exatamente? por que é diferente da integração contínua?)

Você pode me ajudar a entender um pouco mais isso?

A Wikipedia fornece resumos muito bons da maioria desses termos. Aqui está a minha opinião sobre eles:

• A automação de compilação está automatizando como o software é compilado, em vez de invocar manualmente o compilador. Isso seria realizado através de ferramentas como, por exemplo, Make ou Ant .

• A automação de implantação está levando o software construído e implantando ou instalando-o em um sistema de teste ou produção.

• Integração contínua significa que um processo automatizado construa seu software continuamente enquanto os desenvolvedores fazem check-in do código e executam testes de unidade para garantir que o código ainda funcione. Por exemplo, a cada 15 a 30 minutos que um servidor pode acordar, verifique o VCS para novos check-ins, atualize e construa o projeto se alguma alteração foi feita. Além de executar as etapas de compilação, esta também é uma ótima oportunidade para executar testes de unidade automatizados e verificações de qualidade de código .

• A entrega contínua é uma combinação de todos os conceitos anteriores, nos quais a criação do software também é implementada em um sistema de teste, opcionalmente com testes realizados e relatórios gerados.

No mínimo, você precisa ter automação de compilação, ou seja, um script de compilação de algum tipo. Isso permite que você clique em um botão ou emita um comando para criar seu projeto. O benefício disso é reduzir os erros das etapas de execução manual. Ambientes de construção complexos podem envolver a geração de código (pense em DAOs de configurações, código de interface como JAXB ), compilação de código, empacotamento, personalização de metadados etc. Com muitas coisas para fazer, você precisa de uma lista de verificação: por que não fazer a lista de verificação ser seu script de construção e use uma ferramenta para executá-lo? Reduz erros e fornece consistência.

O próximo passo é o CI: é realmente bom ter, mas não é estritamente necessário. Ajuda a identificar problemas de construção desde o início. Se você tiver vários desenvolvedores fazendo check-in de código ao longo do dia e talvez não sincronizando seus próprios espaços de trabalho constantemente, existe o risco de que suas alterações interfiram entre si. Refiro-me especificamente a erros de código estático, não a conflitos de controle de versão. Um servidor de criação de IC reduzirá esse risco.

Finalmente, temos as etapas de implantação. A idéia aqui é economizar tempo e reduzir erros ao implantar software manualmente. Assim como a automação de compilação, existem centenas de maneiras de estragar uma implantação de software. Pessoalmente, fiquei até tarde no escritório para corrigir problemas de implantação manual em muitas ocasiões, quando precisamos de um sistema funcional para os clientes que chegarem amanhã no local. A automação de vários sistemas apresenta mais riscos: em vez de um sistema possivelmente travar ou apresentar erros estranhos, agora temos váriossistemas que podem dar errado. No entanto, esse risco é muito menor do que alguém perdendo uma etapa de uma lista de verificação ou emitindo o comando errado e estragando uma implantação. Se tiver sorte, você pode simplesmente restaurar um backup do banco de dados e reiniciar, se tiver azar, um erro poderá causar o funcionamento incorreto do sistema. É um defeito de software? O técnico não definiu uma configuração corretamente? Isso leva tempo para diagnosticar, tempo que você pode não ter e tempo que não precisa ser gasto se você automatizar o processo.

• Integração Contínua é a prática de mesclar todas as alterações de desenvolvedores em uma linha principal compartilhada várias vezes ao dia. Essa prática agora é tão onipresente que pode não parecer tão significativa, embora tradicionalmente as equipes trabalhem no software por semanas ou até meses isoladamente. O resultado foi "inferno da integração" quando fluxos de trabalho separados foram mesclados. A Integração Contínua é normalmente usada com construções automatizadas da linha principal compartilhada para encontrar problemas antecipadamente, mas é mais sobre confirmações frequentes e fluxo de trabalho do desenvolvedor do que sobre devops.

• As compilações automatizadas são valiosas para detectar problemas que podem fazer com que a compilação seja transmitida localmente, mas falham no servidor de compilação (por exemplo, você esqueceu de fazer check-in de um arquivo, as dependências no servidor de compilação não coincidem). O fato de o servidor de compilação detectar esses problemas significa que você pode corrigi-los antes dos colegas de equipe.

• A Entrega Contínua envolve a implantação, execução e teste contínuos do seu software. Embora as compilações automatizadas garantam que o software seja compilado (e os testes de unidade sejam aprovados), isso não significa que os scripts de implantação ainda funcionem ou que o software seja executado de ponta a ponta. O objetivo da Entrega Contínua é ter uma série de verificações que garantam que a linha principal permaneça em um estado adequado para implantação na produção.

• A Implantação Contínua é o próximo passo lógico - implantar automaticamente todas as confirmações que passam com êxito pelo pipeline de entrega contínua. Há vários benefícios nessa prática, mas para mim a idéia principal aqui é que confirmações pequenas e frequentes são menos arriscadas.

Eu recomendo a leitura deste livro para obter mais informações:

• Entrega contínua: versões confiáveis ​​de software por meio da automação de compilação, teste e implantação

O Teamcity, como muitas das ferramentas de construção, é apenas um aplicativo central que permite executar muitas tarefas diferentes. Isso inclui executar compilações como compilações de IC, compilações de versão completa e permite executar implantações. Se você estiver usando o teamcity para chamar ant ou nant para executar o msbuild em um arquivo de solução, também poderá chamar scripts nant que executarão implantações. Pode exigir um pouco de script, mas não é difícil.

Usamos teamcity e bamboo para ICs completos, ICs de banco de dados e implementamos no ambiente INTegration. Em seguida, usamos teamcity para compilações completas de versões e criação de scripts de migração de banco de dados automaticamente. Eles são verificados no SVN por meio de trabalhos em teamcity que chamam para scripts nantes. Para as implantações, você adivinhou, usamos teamcity para chamar nant para executar tarefas de implantação. Isso funciona bem, já que o agente do teamcity conversa com o servidor do teamcity e o agente pode existir em um dos servidores em um local da DMZ, o que ajuda a mover o código além dos firewalls, etc. Portanto, basta o teamcity ou o bambu para lidar com todo o cenário .