Integração Contínua - Requisitos
A seguir está a lista dos requisitos mais importantes para integração contínua.
Check-In Regularly- A prática mais importante para que a integração contínua funcione adequadamente são os check-ins frequentes no tronco ou linha principal do repositório de código-fonte. O check-in do código deve acontecer pelo menos algumas vezes por dia. O check-in regularmente traz muitos outros benefícios. Isso torna as alterações menores e, portanto, menos propensas a interromper a compilação. Isso significa que a versão mais recente do software para a qual reverter é conhecida quando um erro é cometido em qualquer construção subsequente.
Também ajuda a ser mais disciplinado quanto à refatoração de código e a se limitar a pequenas mudanças que preservam o comportamento. Isso ajuda a garantir que as alterações que alteram muitos arquivos tenham menos probabilidade de entrar em conflito com o trabalho de outras pessoas. Ele permite que os desenvolvedores sejam mais exploradores, experimentando ideias e descartando-as, revertendo para a última versão confirmada.
Create a Comprehensive Automated Test Suite- Se você não tiver um conjunto abrangente de testes automatizados, uma compilação aprovada significa apenas que o aplicativo pode ser compilado e montado. Embora para algumas equipes isso seja um grande passo, é essencial ter algum nível de teste automatizado para fornecer a confiança de que seu aplicativo está realmente funcionando.
Normalmente, existem 3 tipos de testes realizados em Integração Contínua, nomeadamente unit tests, component tests, e acceptance tests.
Os testes de unidade são escritos para testar o comportamento de pequenas partes do seu aplicativo isoladamente. Geralmente, eles podem ser executados sem iniciar todo o aplicativo. Eles não atingem o banco de dados (se seu aplicativo tiver um), o sistema de arquivos ou a rede. Eles não exigem que seu aplicativo seja executado em um ambiente de produção. Os testes de unidade devem ser executados muito rápido - todo o seu pacote, mesmo para um aplicativo grande, deve ser executado em menos de dez minutos.
Os testes de componentes testam o comportamento de vários componentes de seu aplicativo. Como os testes de unidade, eles nem sempre exigem a inicialização de todo o aplicativo. No entanto, eles podem atingir o banco de dados, o sistema de arquivos ou outros sistemas (que podem ser eliminados). Os testes de componentes geralmente demoram mais para serem executados.
Keep the Build and Test Process Short - Se demorar muito para construir o código e executar os testes de unidade, você encontrará os seguintes problemas.
As pessoas vão parar de fazer uma compilação completa e vão executar os testes antes de fazer o check-in. Você começará a obter mais compilações com falha.
O processo de integração contínua levará tanto tempo que vários commits teriam ocorrido no momento em que você pudesse executar o build novamente, então você não saberá qual check-in interrompeu o build.
As pessoas farão o check-in com menos frequência porque têm que ficar sentadas por muito tempo esperando o software ser construído e os testes executados.
Don’t Check-In on a Broken Build- O maior erro da integração contínua é verificar uma compilação quebrada. Se o build falhar, os desenvolvedores responsáveis estão esperando para consertá-lo. Eles identificam a causa da quebra o mais rápido possível e corrigem. Se adotarmos essa estratégia, estaremos sempre na melhor posição para descobrir o que causou a quebra e consertar imediatamente.
Se um de nossos colegas fez um check-in e, como resultado, quebrou a compilação, então, para ter a melhor chance de consertá-lo, eles precisarão de uma correção do problema. Quando essa regra é quebrada, inevitavelmente leva muito mais tempo para que a construção seja corrigida. As pessoas se acostumam a ver a construção quebrada, e muito rapidamente você entra em uma situação em que a construção permanece quebrada o tempo todo.
Always Run All Commit Tests Locally Before Committing- Sempre certifique-se de que os testes projetados para o aplicativo sejam executados primeiro em uma máquina local antes de executá-los no servidor CI. Isso é para garantir que os casos de teste corretos sejam escritos e se houver alguma falha no processo de CI, é devido aos resultados do teste com falha.
Take Responsibility for All Breakages that Result from Your Changes- Se você confirmar uma alteração e todos os testes que você escreveu passar, mas outros falharem, a compilação ainda está danificada. Normalmente, isso significa que você introduziu um bug de regressão no aplicativo. É sua responsabilidade - porque você fez a alteração - corrigir todos os testes que não foram aprovados como resultado de suas alterações. No contexto da CI, isso parece óbvio, mas na verdade não é uma prática comum em muitos projetos.