Analisar a integração contínua
A integração contínua é uma das oito funcionalidades na taxonomia de DevOps.
Descubra por que a integração contínua é necessária
Em 23 de setembro de 1999, o Orbitador Climático de Marte guardou seus painéis solares para protegê-los de uma descida temporária na atmosfera superior de Marte.
Depois de entrar em órbita com sucesso, o satélite deveria retransmitir fotos de Marte para a Terra por vários anos. Mas o orbitador queimou na atmosfera marciana.
Um bug no software de controle de solo, que foi fornecido por terceiros, calculou o valor em uma unidade Imperial, libra-segundos. O software criado pela NASA esperava que o valor estivesse em uma unidade métrica, newton-segundos. Como esses valores não foram convertidos corretamente, pequenas discrepâncias na posição da nave espacial foram combinadas ao longo do curso de milhões de milhas.
A garantia de qualidade não observou o uso de uma unidade imperial no software externo, apesar de os padrões de codificação da NASA na época exigirem o uso de unidades métricas. Os cálculos também foram feitos manualmente em vez de usando o software fornecido, devido a erros de formato de arquivo e bugs diversos. Essa situação é um exemplo da necessidade da integração contínua.
Explorar a integração contínua
A integração contínua é uma mentalidade e uma estratégia de equipe. Além disso, o autor e palestrante Martin Fowler afirma que a integração contínua é uma prática de desenvolvimento de software em que os membros de uma equipe integram seu trabalho com frequência, geralmente cada pessoa faz a integração pelo menos diariamente, levando a várias integrações por dia.
Cada integração é verificada por um build automatizado (incluindo o teste) para detectar erros de integração o mais rápido possível.
Quando feita corretamente, essa abordagem leva a problemas de integração reduzidos ao capturá-los anteriormente no processo.
As metas da integração contínua são para:
- Aproveitar a colaboração
- Habilitar o desenvolvimento paralelo
- Minimizar a dívida de integração
- Atuar como um portão de qualidade
- Automatizar tudo!
Observação
Observe como as metas de integração contínua incluem a colaboração contínua, a entrega contínua e a qualidade contínua!
Mas o que acontece quando não há integração contínua? A falta de esforços de integração contínua geralmente pode resultar em:
- Ciclos de desenvolvimento longos
- Código sem compilação
- Em qualquer momento, o código-fonte pode não ser funcional
- Congelamento de código
- Falhas de build altas/contagens de bugs
- Branches de longa vida, causando esforços de mesclagem de vários dias
- Código ausente do controle do código-fonte
- Falhas de segurança encontradas tarde no ciclo de desenvolvimento
- Grande quantidade de dívidas técnicas
- Números de cobertura de código baixos ou ausentes
- Qualidade reduzida geral
- Comunicação e colaboração limitadas
- Código que não segue os padrões de codificação
- Nenhuma ou poucas revisões de código
- Testes feitos tardiamente no ciclo de desenvolvimento
- Em muitos casos, manual, se houver
Os pontos de integração são o loop de comentários rápidos usado para aprimorar o sistema. Quando o tempo dos pontos de integração tem um lapso, o projeto está com problemas. Veja o que Dantar Oosterwal diz sobre eles no livro The Lean Machine:
A epifania dos pontos de integração é que eles controlam o desenvolvimento de produtos. Eles são os pontos de aproveitamento para aprimorar o sistema. Quando o tempo dos pontos de integração tem um lapso, o projeto está com problemas.
Dantar Oosterwal, The Lean Machine
© Scaled Agile, Inc.
Caso tenha se perguntado se a sua equipe está realmente fazendo a integração contínua, essas perguntas podem ajudá-lo a determinar a resposta.
- Todos os desenvolvedores estão fazendo o desenvolvimento baseado em tronco?
- Todas as alterações em um tronco iniciam um processo de build?
- Quando o build e o teste falham, a equipe corrige o build em alguns minutos?
O desempenho também é influenciado pela presença ou ausência da integração contínua. Os dados coletados e analisados para o livro The Science Of DevOps – Accelerate – Building and scaling high performing technology organizations de Nicole Forsgren, Jez Humble e Gene Kim mostram que, quando a velocidade de comercialização de equipes de baixo desempenho aumenta, a qualidade diminui.
Mas equipes de alto desempenho podem manter a qualidade enquanto aumentam a velocidade de comercialização. Elas têm ciclos de implantação menores (e menos complexos) e usam a integração contínua para corrigir problemas imediatamente, aumentando o fluxo e a eficiência.
| 2017 | Equipes de alto desempenho | Equipes de desempenho médios | Equipes de baixo desempenho |
|---|---|---|---|
| Frequência de implantação | Vários por dia | 1 semana a 1 mês | 1 semana a 1 mês |
| Prazo de entrega de alteração | < 1 hora | 1 semana a 1 mês | 1 semana a 1 mês |
| MTTR | < 1 hora | < 1 dia | 1 dia a 1 semana |
| Taxa de falha de alteração | 0 a 15% | 0 a 15% | 31 a 45% |