Integração contínua
Na engenharia de software, integração contínua (IC), do inglês 'continuous integration (CI), é a prática de mesclar todas as cópias de trabalho dos desenvolvedores em uma linha principal compartilhada, várias vezes ao dia.[1] Grady Booch propôs pela primeira vez o termo IC em seu método de 1991,[2] embora ele não tenha defendido a integração várias vezes ao dia. A programação extrema, Extreme Programming (XP) em inglês, adotou o conceito de IC e defendeu a integração mais de uma vez por dia - talvez até dezenas de vezes ao dia.[3]
Justificativa[editar | editar código-fonte]
Ao iniciar uma mudança, um desenvolvedor obtém uma cópia da base de código atual com a qual trabalhar. À medida que outros desenvolvedores enviam o código alterado para o repositório de código-fonte, esta cópia deixa gradualmente de refletir o código do repositório. Não apenas a base de código existente pode mudar, mas um novo código pode ser adicionado, bem como novas bibliotecas e outros recursos que criam dependências e conflitos potenciais.
Quanto mais o desenvolvimento continuar em um branch sem se fundir de volta à linha principal, maior será o risco de vários conflitos de integração[4] e falhas quando o branch do desenvolvedor for eventualmente fundido de volta. Quando os desenvolvedores enviam código para o repositório, eles devem primeiro atualizar seu código para refletir as mudanças no repositório desde que fizeram sua cópia. Quanto mais mudanças o repositório contém, mais trabalho os desenvolvedores devem fazer antes de enviar suas próprias mudanças.
Eventualmente, o repositório pode se tornar tão diferente das linhas de base dos desenvolvedores que eles entram no que, às vezes, é chamado de "inferno de fusão" (merge hell) ou "inferno de integração" (integration hell),[5] onde o tempo que leva para integrar excede o tempo que levou para fazer suas alterações originais.[6]
Fluxos de trabalho (workflows)[editar | editar código-fonte]
Executar testes localmente[editar | editar código-fonte]
A Integração Contínua deve ser usada em combinação com testes de unidade automatizados, escritos por meio de práticas de desenvolvimento orientado a testes. Isso é feito executando e passando todos os testes de unidade no ambiente local do desenvolvedor antes de se enviar (commit) à linha principal. Isso ajuda a evitar que o trabalho em andamento de um desenvolvedor interrompa a cópia de outro desenvolvedor. Onde necessário, recursos parcialmente completos podem ser desabilitados antes de confirmar, usando alternadores de recursos, por exemplo.
Compilação de código em Integração Contínua[editar | editar código-fonte]
Um servidor de compilação compila o código periodicamente ou mesmo após cada envio (commit) e relata os resultados aos desenvolvedores. O uso de servidores de compilação foi introduzido fora da comunidade XP (programação extrema) e muitas organizações adotaram IC sem adotar todo o XP.
Referências
- ↑ Fowler, Martin (1º de maio de 2006). «Continuous Integration». Consultado em 9 de janeiro de 2014
- ↑ Booch, Grady (1991). Object Oriented Design: With Applications. [S.l.]: Benjamin Cummings. p. 209. ISBN 9780805300918. Consultado em 18 de agosto de 2014
- ↑ Beck, K. (1999). «Embracing change with extreme programming». Computer. 32 (10): 70–77. ISSN 0018-9162. doi:10.1109/2.796139
- ↑ Duvall, Paul M. (2007). Continuous Integration. Improving Software Quality and Reducing Risk. [S.l.]: Addison-Wesley. ISBN 978-0-321-33638-5
- ↑ Cunningham, Ward (5 de agosto de 2009). «Integration Hell». WikiWikiWeb. Consultado em 19 de setembro de 2009
- ↑ «What is Continuous Integration?». Amazon Web Services
Ligações externas[editar | editar código-fonte]
- «Continuous Integration» (wiki). C2 (a collegial discussion)
- Richardson, Jared. «Continuous Integration: The Cornerstone of a Great Shop» (introduction)
- Flowers, Jay. «A Recipe for Build Maintainability and Reusability». Consultado em 28 de maio de 2006. Cópia arquivada em 25 de junho de 2020
- Duvall, Paul (4 de dezembro de 2007). «Developer works»
- «Version lifecycle». MediaWiki
- «Continuous Integration in the Cloud» (PDF). CrossTalk. 2016[ligação inativa]
- «Continuous Integration Introduction». Katalon. 2019
- Bugayenko, Yegor. "Why Continuous Integration Doesn't Work"
