O que é integração contínua?

CI, CD e implantação contínuas são partes cruciais do ciclo de vida de lançamento do software, inclusive dos processos de DevOps.

Como regra geral, a CI é usada em conjunto com o desenvolvimento ágil de software, o que ajuda uma organização a compilar tarefas em uma lista e um mapa de produtos. Depois de descritas, as tarefas são exibidas aos diferentes membros da equipe para que sejam executadas. Em seguida, os vários códigos são mesclados em um repositório principal de códigos.

A CD é a segunda parte do processo. Ela envolve o agrupamento de código que, então, estará pronto para ser entregue aos usuários finais. Geralmente, essa etapa do processo executa ferramentas automatizadas que geram um artefato, o que o deixa pronto para ser implantado para os usuários finais a qualquer momento.

Como a fase final do processo, a implantação contínua inicia automaticamente o produto de software para os usuários finais, o que significa que ele passou com sucesso nas fases de integração e entrega. A automação utiliza scripts ou ferramentas que transferem o produto de software para servidores públicos ou outros meios de distribuição pública. Em um ambiente altamente automatizado e bem governado, essas implantações ocorrem automaticamente assim que o produto é entregue (portanto, são contínuas). Por outro lado, algumas equipes ou alguns produtos podem ser implantados em momentos específicos ou após a conclusão de outros processos e verificações.

Diminuir a burocracia dos códigos pode ajudar os fluxos de trabalho ágeis e de DevOps a funcionar com eficácia e estabilidade, desde o desenvolvimento de um novo código até o final do ciclo. A CI poderá ajudar uma empresa a se dimensionar quando ela eliminar as dependências que atrapalham o desenvolvimento de recursos individuais. Embora um desenvolvedor trabalhe em um silo, ele pode fazer isso sabendo que seu código será integrado ao restante do repositório de códigos.

As decisões de negócios recebem um feedback mais rápido sobre as decisões de negócios, o que pode ajudar as equipes de produtos a testar suas ideias e a trabalhar melhor com o design iterativo de produtos. As mudanças podem ser rápidas, medidas e bem-sucedidas, e os bugs podem ser abordados e corrigidos rapidamente.

As equipes de engenharia podem se comunicar melhor e ser responsabilizadas, o que permite uma melhor comunicação em uma equipe de DevOps. As equipes têm a oportunidade de ver e comentar sobre o código escrito por outros membros da equipe, o que também oferece a oportunidade de colaborar em futuros códigos com outros desenvolvedores.

O código é executado por meio do software de controle de versão, como Apache subversion ou git, e o histórico de confirmação do código de software é confirmado para que possa ser alterado, se necessário.

Os desenvolvedores criam seus códigos e eles passam pelo sistema de histórico de versões. Em seguida, o código é devolvido à fase de criação para compilação.

O software é submetido a testes, incluindo o teste de unidades que testa as unidades do software. A fase de preparação começa após os testes bem-sucedidos, o que significa que o software está pronto para ser implantado no processo de preparação. Aqui, o código é visualizado e finalizado antes da fase final de teste.

Depois que o software está no ambiente de preparação, ele passa por testes automatizados que são elaborados para o software. Assim que o software passar nos testes automatizados, ele será enviado para a fase de implantação.

Após a realização dos testes automatizados, o software é implantado na produção. Se houver algum erro durante a fase de teste ou a implantação posterior, o software retornará ao procedimento de controle de versão e será inspecionado em busca de erros. Se algum erro for identificado, eles serão corrigidos.

Cada artefato necessário para criar um projeto deve ser colocado em um repositório central de códigos. Isso permite que as mudanças integradas sejam mantidas, em vez de manter versões individuais simultaneamente.

O ideal é que haja um único comando que possa criar um sistema. Isso inclui automatizar a integração, que é implantada em um ambiente semelhante ao produto. Há muitos casos em que o script compila binários ao gerar páginas da Web, mídia de distribuição, estatísticas e páginas de sites.

Todos os testes devem ser executados para confirmar que o projeto está se comportando da maneira esperada.

A chance de mudanças conflitantes pode ser exponencialmente reduzida quando todos estão sempre comprometidos. A adesão diária ajuda os desenvolvedores a identificar quaisquer problemas ou mudanças necessárias no código e, nesse ponto, eles comunicam as mudanças — o acúmulo de trabalho de uma semana poderia contribuir para a sobrecarga ou a não detecção de problemas e, por isso, o comprometimento diário é necessário.

As confirmações precisam ser criadas com a versão de trabalho atual para verificar se estão funcionando corretamente. Normalmente, a ACI (Automated Continuous Integration, integração contínua automatizada) é usada, mas também pode ser feita manualmente. A ACI usa um daemon para observar o sistema de controle de revisão em busca de quaisquer alterações feitas e, em seguida, executa o processo de criação automaticamente.

Todas as criações devem ser as mais rápidas possíveis para evitar quaisquer problemas com a integração ou para identificar problemas rapidamente.

Um ambiente de teste pode criar falhas em um sistema testado se for implantado em um ambiente de produção. A configuração de uma réplica do ambiente de produção pode impedir falhas, pois um ambiente de produção pode ser diferente de um ambiente de teste. Um ambiente de preparação separado deve ser uma versão dimensionável que mantém composições de conjuntos de tecnologia, ao mesmo tempo em que reduz os custos.

As partes interessadas e os testadores podem precisar ver o trabalho; portanto, será melhor manter as criações prontamente disponíveis para reduzir a quantidade de retrabalho necessária se um recurso precisar ser recriado. Os testes antecipados também podem eliminar a possibilidade de continuar cometendo erros durante o processo.

Se uma criação for interrompida, geralmente será fácil retomá-la. A CI ajuda uma equipe a identificar as mudanças que foram feitas e o membro da equipe que fez as mudanças, o que pode ajudar na transparência e na produtividade.

Mesmo após o término de uma criação, a maioria dos sistemas de CI executará scripts. É possível escrever um script para implantar o aplicativo em um servidor de teste em tempo real que esteja disponível para todos verem. A CI exige que o software seja implantado em produção com automação adicional para evitar regressões ou defeitos.

É recomendável sempre desenvolver e aprimorar a cobertura de testes assim que um projeto for estabelecido no pipeline de CI. Deve haver testes que acompanham todos os novos recursos que avançam pelo pipeline de CI para verificar se o novo código está funcionando como esperado.

As pull requests são uma parte crucial da CI; a maioria dos desenvolvedores de software pratica um processo de pull request e revisão de código. Uma pull request é uma excelente oportunidade para iniciar o pipeline de CI a fim de executar as etapas da aprovação automatizada. A aprovação manual também é adicionada no momento de uma pull request, quando uma parte não interessada pode realizar uma revisão do código. Isso oferece a oportunidade para que as partes não interessadas identifiquem edições ou aprovem ou neguem a pull request.

É fundamental otimizar a velocidade de execução do pipeline de CI, pois ele é um processo muito usado. Os atrasos no fluxo de trabalho podem acumular problemas durante os crescentes lançamentos de recursos, tamanhos de bases de código e tamanhos de equipes. Sempre meça o pipeline de CI para garantir que ele seja otimizado.

Quando há um pipeline de CI mais rápido, há um loop mais rápido de feedback de CI. Os desenvolvedores têm a oportunidade de aplicar mudanças e testar uma experiência do usuário, corrigir bugs rapidamente e aumentar a velocidade de execução para obter vantagens em relação à concorrência e uma qualidade superior.

Você pode utilizar a CI/CD ao criar aplicativos na plataforma ServiceNow. Você também pode conectar suas ferramentas de CI/CD ao produto de DevOps da ServiceNow para vincular o trabalho que está avançando pelo pipeline de CI/CD ao trabalho gerenciado na ServiceNow. O produto ServiceNow DevOps pode oferecer muitos benefícios ao processo de CI/CD, independentemente de você estar criando na plataforma ServiceNow ou fora da ServiceNow, em ferramentas como Azure DevOps, GitLab ou Jenkins.

Gerencie alterações de código de maneira eficaz para vários desenvolvedores ao usar a integração de repositório Git e faça uma conexão entre itens de trabalho, como históricos de usuário e as confirmações no repositório. Com a conexão adicional de confirmações com os resultados de testes e mudanças na ServiceNow, você obtém uma visão completa e de ponta a ponta do pipeline.

Automatize a criação, a aprovação e a implantação de mudanças e avance do desenvolvimento e dos testes à produção com mais rapidez e eficiência.

Entregue aplicativos mais rapidamente para ajudar as equipes a iterar mais rapidamente com base no feedback, com antecedência e com frequência.

Gere relatórios de todo o pipeline ou do fluxo de valor, da idealização à produção. Comunique-se entre equipes, compare o desempenho de diferentes ferramentas e identifique e resolva gargalos.