Integração contínua

No mundo de hoje, Integração contínua é um tema de grande relevância e interesse para um público amplo. Seja uma pessoa influente, uma questão social, uma data importante ou um tema atual, Integração contínua tem captado a atenção de muitas pessoas em diferentes contextos. Neste artigo exploraremos a fundo todas as facetas e aspectos relacionados a Integração contínua, com o objetivo de fornecer uma perspectiva mais ampla e abrangente sobre este tema. Desde a sua origem até ao seu impacto na sociedade, abordaremos detalhes relevantes que contribuirão para enriquecer o conhecimento e compreensão de Integração contínua. Nesta linha, mergulharemos numa viagem de descoberta e investigação que nos permitirá aprofundar a importância e relevância de Integração contínua no mundo de hoje.

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

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)

Executar testes localmente

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

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

  1. ↑ Fowler, Martin (1º de maio de 2006). «Continuous Integration». Consultado em 9 de janeiro de 2014 
  2. ↑ Booch, Grady (1991). Object Oriented Design: With Applications. : Benjamin Cummings. p. 209. ISBN 9780805300918. Consultado em 18 de agosto de 2014 
  3. ↑ Beck, K. (1999). «Embracing change with extreme programming». Computer. 32 (10): 70–77. ISSN 0018-9162. doi:10.1109/2.796139 
  4. ↑ Duvall, Paul M. (2007). Continuous Integration. Improving Software Quality and Reducing Risk. : Addison-Wesley. ISBN 978-0-321-33638-5 
  5. ↑ Cunningham, Ward (5 de agosto de 2009). «Integration Hell». WikiWikiWeb. Consultado em 19 de setembro de 2009 
  6. ↑ «What is Continuous Integration?». Amazon Web Services 

Ligações externas