Como o IC pode ser usado para idiomas interpretados?

Eu nunca usei um sistema de integração contínua (IC) antes. Eu codifico principalmente em MATLAB, Python ou PHP. Nenhum deles possui uma etapa de criação e não vejo como um IC pode ser usado para o meu trabalho. Um amigo de um grande projeto de uma grande empresa me disse que o idioma não importa.

Não vejo como o IC seria útil para mim se eu não tiver uma etapa de construção. Eu posso pensar no CI como um ambiente de teste que executaria testes de unidade. Estou esquecendo de algo?

Integração contínua como termo refere-se a duas idéias distintas.

O primeiro é um fluxo de trabalho: em vez de todos em uma equipe trabalharem em seu próprio ramo e, depois de algumas semanas de programação, tentar mesclar suas mudanças na linha principal, essas mudanças são integradas (quase) continuamente. Isso permite que os problemas apareçam mais cedo e evita alterações incompatíveis. No entanto, isso exige que possamos verificar facilmente se uma alteração "funciona".

É aí que entra a segunda idéia, que se tornou muito mais popular. Um servidor de IC é um ambiente limpo, onde as alterações são testadas o mais rápido possível. O ambiente limpo é necessário para que a construção seja reproduzível. Se funcionar uma vez, deve sempre funcionar. Isso evita problemas "mas funcionou na minha máquina". Em particular, um servidor de IC é valioso quando o software é executado em sistemas diferentes ou em configurações diferentes e você precisa garantir que tudo funcione.

A falta de uma etapa de construção é irrelevante. No entanto, o IC só faz sentido se você tiver um conjunto de testes. Este conjunto de testes deve ser automático e não deve ter falhas. Se os testes falharem, o desenvolvedor apropriado deve receber uma notificação para que possa corrigir o problema que apresentou ("interromper a compilação", mesmo quando não houver compilação como compilação).

Acontece que esse servidor é valioso para mais do que apenas testar. De fato, a maioria dos softwares de CI é realmente ruim para executar testes em várias configurações, mas boa para gerenciar todos os tipos de tarefas. Por exemplo, além dos testes de unidade "contínuos", pode haver um teste completo como uma construção noturna. O software pode ser testado com várias versões do Python, diferentes versões da biblioteca. Um site pode ser testado para links mortos. Podemos executar análises estáticas, verificadores de estilo, ferramentas de cobertura de testes etc. sobre o código. Documentação pode ser gerada. Quando todos os conjuntos de testes forem aprovados, o processo de empacotamento poderá ser iniciado para que você esteja pronto para lançar seu software. Isso é útil em uma configuração ágil, na qual você deseja um produto implantável (e demonstrável) o tempo todo. Com o surgimento de aplicativos da web, há também a ideia de implantação contínua: Se todos os testes forem aprovados, podemos enviar automaticamente as alterações para a produção. Obviamente, isso exige que você esteja realmente confiante em sua suíte de testes (caso contrário, você terá problemas maiores).

É verdade que você não tem necessidade específica de um sistema de IC para executar compilações e verificar se essas compilações estão corretas, mas isso é apenas parte do que trata o IC.

O objetivo do IC é detectar erros o mais rápido possível, porque, de um modo geral, quanto mais cedo um erro for detectado, mais barato será o reparo. Para esse fim, no caso de uma etapa de construção não ser necessária, um sistema de IC ainda pode automatizar o uso de ferramentas de análise de código, implantação em um ambiente de teste, unidade / integração / regressão / outros testes que você pode automatizar e outras etapas você pode executar automaticamente para verificar se há erros.

A integração contínua executa mais do que uma compilação do código. Se isso foi tudo o que fizemos, não precisaríamos de tantas ferramentas!

Algumas outras tarefas que posso pensar de imediato que um pipeline de integração contínua geralmente executa:

• Executando testes automáticos. (O Python possui diversas bibliotecas de teste automatizadas e o PHP possui pelo menos algumas. Não posso falar com o MATLAB.)
• Empacotando o software para distribuição. Ao automatizar esse processo, você garante que ele seja feito de maneira exata, consistente e repetível todas as vezes. Nenhum passo será esquecido; gerar esse pacote de distribuição leva no máximo um clique. (Agrupar seu aplicativo Python como uma roda é uma ótima idéia!)
• Marcação de marcos confirmados. Sempre que você cria um pacote para produção, provavelmente deseja marcá-lo.
• Números de versão com incremento automático. Normalmente, esse seria apenas o número da "compilação" e não as partes mais significativas, mas pode ser bom identificar exclusivamente uma compilação específica, para que você saiba o que é implantado onde.

Indo um pouco mais além da linha de fronteira da "integração contínua" em sentido estrito, você também pode fazer o seguinte:

• Tenha um processo automatizado para configurar um sistema operacional e instalar suas dependências.
• Implantação automática de cópias do software (útil principalmente para aplicativos da Web ou software distribuído por um gerenciador de pacotes). Algumas equipes realmente usam isso para implantar na produção (entrega contínua), mas mesmo se não o fizer, você ainda pode aproveitar isso para implantar cópias extras do código que não sejam de produção. Para alguns projetos em que trabalho, temos uma cópia para os desenvolvedores testarem seu código antes de disponibilizá-lo para o controle de qualidade, uma cópia para testar o controle de qualidade e uma cópia mais "estável" para fins de demonstração.

O ponto é simplesmente este: existem tarefas que você deve executar periodicamente no processo de desenvolvimento de software, além de apenas escrever o código. Ao automatizar essas tarefas e executá-las em um servidor, você obtém

• Processo consistente (você não terá Stan e Sally fazendo coisas de maneiras diferentes.)
• Conhecimento dos processos registrados no código (quem pode ler os scripts pode aprender as etapas envolvidas na implantação, em vez de Sally ser a única que faz ou sabe como.)
• Duplicação de processos mais simples (simples de implantar várias cópias do site: você apenas fornece uma nova configuração!)
• Testes mais detalhados (Bob testou apenas sua página, mas suas alterações quebraram a página de Sally. Sally esqueceu de confirmar um arquivo. Stan adicionou uma nova dependência que deve ser instalada ao lado do aplicativo, mas não a percebeu porque é instalada automaticamente pelo IDE Eu já vi tudo isso de uma forma ou de outra.)

E provavelmente alguns outros benefícios que nem sequer vêm à mente.

Pode não ser necessário compilar as soluções, mas o IC ainda pode ajudá-lo, alterando os caminhos dos arquivos / pastas de configuração, etc.

Digamos que você implemente seu código Python em 5 servidores de controle de qualidade diferentes e precise apontá-lo para bancos de dados de controle de qualidade diferentes e, depois que o teste automatizado for executado (acionado pelo CI), promovendo a construção para produção e implantando-o com alterações de configuração apropriadas para cada servidor de produção .