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


12

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?


É automação, não automotion.
Florian Margaine

Ele é construído na minha máquina e não é bom o suficiente, pois depende de rotações para fazer sempre a coisa certa. Coisas como novas dependências ou outras mudanças nos membros da equipe combinadas com as suas agora quebram um teste.
Andy

Respostas:


15

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.


Então, podemos admitir que ferramentas como o TeamCity, que permitem criar algo a partir de um VCS remoto, podem ser consideradas como um servidor de IC? Como mesclar códigos de desenvolvedor das filiais VCS e criar a última versão a partir da ferramenta de automação predial?
Mfrachet

1
Não estou familiarizado com o TeamCity, mas parece ser um servidor de IC . A maior parte da minha experiência é com o Jenkins CI , incluindo implantações automatizadas.

@Skahrz, se você deseja implantações automatizadas, tem opções como BuildMaster (também um servidor de CI) e Octopus Deploy.
Andy

Você está descrevendo construções contínuas em vez de integração contínua. Este último também exigem a verificação de que as coisas realmente funcionam quando colocados juntos ..
Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersen você está correto, obrigado. Atualizei minha resposta para mencionar o teste com o CI.

0
  • 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:


-2

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 .


2
este não parece oferecer nada substancial sobre pontos apresentados e explicados na resposta anterior
mosquito
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.