Integração Contínua
- Manter um único repositório de código.
- Automatize a Build
- Faça sua Build ser auto-testável
- Cada um lança suas modificações todos os dias
- Cada commit deve atualizar o repositório principal em uma máquina de integração
- Mantenha a Build rápida
- Teste em uma cópia do ambiente de produção
- Torne fácil para qualquer um ter o último executável.
- Todos podem ver o que esta acontecendo.
- Automatize a Implantação do Sistema
Fonte: http://www.pedromendes.com.br/2009/03/04/traducao-do-artigo-sobre-integracao-continua/
Martin Fowler é um importante engenheiro de software. Ele é autor do artigo Continuous Integration, um marco sobre esse assunto, que você pode acessar pelo seguinte link.
https://martinfowler.com/articles/continuousIntegration.html
Vamos analisar as alternativas.
(a) automatize o processo de Build.
Correto. Para a integração contínua funcionar, é necessário que o processo de Build (compilação, integração, testes) seja todo automatizado. Os desenvolvedores só se preocupam em fazer o CHECK-IN do código correto no repositório com seus respectivos testes.
(b) cada modificação salva deve gerar um Build automaticamente.
Correto. Cada modificação salva é um CHECK-IN no repositório. Após cada CHECK-IN é desejável que rode uma Build automaticamente.
(c) execute os testes finais no ambiente de produção.
Errado. Na verdade, os testes finais devem rodar antes, em um ambiente de homologação ou pré-produção. Somente após esses testes passarem com sucesso é que se poderia fazer uma publicação do sistema em produção.
(d) garanta que o Build seja rápido.
Certo. Uma das premissas é de que a Build rode continuamente. Para que isso seja viável, ela tem que ser rápida.
(e) mantenha um repositório de fontes unificado.
Correto. O repositório de códigos-fonte deve ser unificado. É nele que serão feitos todos os CHECK-INs e a partir dele que o processo de build obterá a versão mais atualizada do código.
Resposta: C