Avalie o desempenho de CI/CD com métricas de DevOps

Um servidor de CI ou "servidor de build" coordena todas as etapas de um processo de CI/CD, desde o monitoramento do VCS em busca de alterações até a implantação de novas builds.

O uso de um servidor de CI pode ajudar você a otimizar seus processos de integração contínua e entrega/implantação contínua (CI/CD). Um servidor de CI é responsável pelo monitoramento do seu sistema de controle de versão (VCS), acionando tarefas automatizadas de build, teste e implantação, reunindo os resultados e iniciando o próximo estágio do pipeline.

Embora seja possível praticar a CI/CD sem um servidor de build, muitas equipes de desenvolvimento optam por usar uma ferramenta de CI para coordenar o processo e comunicar os resultados de cada etapa. Neste guia, veremos o que um servidor de CI faz e como ele pode ajudar você a tirar o máximo proveito da CI/CD.

Por que usar um servidor de CI?

Um servidor de CI funciona como um ponto central para coordenar todas as suas atividades de CI/CD. Usar um servidor de CI:

  • Garante que todos os commits passem pela CI/CD: ao integrar-se ao seu VCS, um servidor de CI garante que todas as alterações de código passem pelo seu processo automatizado de build, teste e implantação.-Nenhum esforço adicional é necessário por parte dos desenvolvedores individuais.
  • Permite que você coordene sua lógica de negócios: desde o nível de cobertura de teste que você deseja aplicar até o que constitui uma "aprovação" para cada estágio do processo de testes automatizados, um servidor de CI fornece uma única fonte confiável para os requisitos da sua organização.
  • Permite integração com a sua toolchain: assim como seu VCS e suas ferramentas de build, um servidor de CI pode se integrar a rastreadores de issues e plataformas de comunicação para fornecer atualizações automatizadas do processo de build, teste e implantação.
  • Mantém um registro de builds anteriores: ter um arquivo de artefatos de build é inestimável quando você precisa identificar o ponto em que um bug particularmente sutil chegou à sua base de código.
  • Permite que os envolvidos tenham visibilidade do progresso de lançamento: como uma fonte central confiável para o status de builds e implantações, você pode usar seu servidor de CI para manter toda a organização informada sobre o progresso.
  • Fornece um log de auditoria das alterações: é provável que seu workflow e sua lógica de negócios evoluam com o tempo. O uso de um servidor de CI pode fornecer um registro de como o seu processo de CI/CD mudou, para o caso de você querer reverter para uma implementação anterior.

Por sua vez, o uso de um servidor de CI ajudará você a aproveitar os diversos benefícios da CI/CD, inclusive o feedback rápido sobre alterações no seu código, a identificação antecipada de bugs e os lançamentos mais frequentes.

Por que usar um servidor de CI/CD

Como funciona um servidor de CI?

Embora o processo exato varie de acordo com a sua equipe e as exigências organizacionais, um servidor de CI normalmente executa as seguintes etapas:

  1. Integra-se ao seu sistema de controle de versão e monitora-o em busca de commits nos branches relevantes.
  2. Inicia uma série de tarefas de build e teste sempre que ocorrer o commit de uma alteração. Essas tarefas são distribuídas para outras máquinas no seu farm de builds ou executadas no próprio servidor de CI.
  3. Reúne os resultados dessas tarefas e usa esses dados para determinar se deve prosseguir para o próximo estágio do processo.
  4. Armazena os artefatos de build em um arquivamento central.
  5. Implanta a nova versão na produção.
  6. Fornece feedback durante todo o processo.
Como funciona um servidor de CI

Monitorar o controle de versões

No início de qualquer pipeline de CI/CD, está uma integração com um sistema de controle de versão ou de fontes.

Normalmente, um servidor de CI é configurado para recepcionar commits em um determinado branch e acionar uma nova execução do pipeline sempre que uma alteração é feita. Isso garante que, cada vez que um desenvolvedor compartilha suas alterações, estas sejam criadas e testadas para garantir que a base de código como um todo ainda funcione corretamente.

Alguns servidores de CI permitem que você dê um passo adiante e exija que os desenvolvedores façam o build e teste das alterações localmente antes que possam compartilhá-las em um branch de CI. Embora não garanta que a próxima etapa será aprovada com sucesso, isso ajuda a reduzir o número de builds interrompidas e os atrasos que elas podem causar. Outra opção é integrar o servidor de CI à sua ferramenta de revisão de código, para que cada commit passe por um estágio de revisão de código antes de ser compartilhado.

Aplicar essas camadas extras de lógica de negócios no início do processo ajuda a manter sua base de código limpa e pronta para lançamento, enquanto minimiza interrupções e atrasos no pipeline.

Gerenciar builds e testes

Sempre que uma alteração é detectada e uma execução de pipeline é acionada, o servidor de CI coordena as tarefas de build e teste. Normalmente, essas tarefas são alocadas a máquinas de build dedicadas, ou "agentes". Seus agentes de build fazem o trabalho pesado de executar builds e testes de acordo com as instruções recebidas do servidor de CI.

Outra opção é executar tarefas de build e teste no próprio servidor de CI. No entanto, isso pode resultar em contenção de recursos e redução do desempenho em bases de código movimentadas.

Ao usar seu servidor de CI para configurar a lógica para um estágio do seu pipeline, você poderá especificar uma gama de detalhes e regras. Por exemplo, você pode querer:

  • Executar todos os seus testes automatizados em commits no branch principal, mas executar um conjunto reduzido de verificações em branches de recursos.
  • Controlar quantas builds podem chamar um banco de dados de teste ao mesmo tempo.
  • Limitar as implantações em um ambiente de preparação a uma vez por semana para permitir testes manuais mais complexos.

Ser capaz de executar certas tarefas ao mesmo tempo usando diferentes agentes de build pode deixar seu pipeline mais eficiente. Isso é útil se você precisa executar testes em diferentes sistemas operacionais ou se está trabalhando em uma enorme base de código com testes que chegam a centenas de milhares, em que a única opção prática é a paralelização. No último caso, a configuração de uma build composta agregará os resultados, para que você possa tratar as tarefas como uma única etapa de build.

Um servidor de compilação que se integra à infraestrutura hospedada na nuvem, como a AWS, permitirá que você se beneficie de recursos elásticos e escaláveis para executar suas compilações e testes. Se suas necessidades de infraestrutura forem consideráveis, o suporte a agentes de build em containers e a integração com o Kubernetes permitirão que você gerencie seus recursos de build com eficiência, estejam eles na nuvem ou locais.

Definir condições de aprovação e falha

Uma parte fundamental de sua lógica de negócios envolve a definição do que constitui uma falha em cada estágio de seu pipeline de CI/CD.

Seu servidor de CI deve permitir que você configure várias condições de falha. Em seguida, ele verifica se esses critérios foram atendidos para determinar o status de uma etapa específica e decidir se deve prosseguir para o próximo estágio do pipeline.

Além das falhas evidentes, como uma build que retorna um código de erro ou testes que não são executados, você pode definir outras condições de falha com base nos dados coletados pelo seu servidor de build.

Exemplos incluem a diminuição da cobertura de testes em relação à build anterior (indicando que testes não foram adicionados para as últimas alterações no código) ou o aumento do número de testes ignorados em comparação com a última build bem-sucedida.

Essas métricas também servem como um aviso útil quando a qualidade do código pode estar se deteriorando. Ao disparar uma falha por esses motivos e limitar os usuários que têm permissão para ignorar essas falhas, você pode promover comportamentos desejáveis.

Armazene artefatos de build

Quando uma alteração é bem-sucedida, o servidor de CI armazena os artefatos do processo de build. Isso pode incluir binários, instaladores, imagens de container e quaisquer outros recursos necessários para implantar seu software.

Em seguida, você pode implantar os mesmos artefatos em ambientes de pré-produção para testes adicionais antes de finalmente implantá-los na produção. Isso garante que o mesmo resultado seja testado em todos os estágios e é muito mais confiável do que reconstruir o código-fonte antes de cada implantação. Em particular, ele evita o risco de perder dependências e introduzir outras inconsistências.

Manter um repositório de artefatos de builds bem-sucedidas também é útil quando você precisa reverter para uma versão anterior do seu software ou quando está tentando identificar quando um determinado problema foi introduzido.

Implantar builds

Embora o nome "servidor de CI" sugira que seu uso é limitado à integração contínua, a maioria dos servidores de CI também oferece suporte para entrega contínua e implantação contínua.

Depois de produzir seus artefatos de build e executar um conjunto inicial de testes durante a fase de integração contínua, a próxima etapa é implantar esses artefatos em ambientes de controle de qualidade para testes adicionais. Isso é seguido pela preparação, que dá aos envolvidos a chance de experimentar a nova build. Em seguida, se tudo parecer funcionar corretamente, você normalmente libera a versão em produção.

Você pode usar um servidor de CI para armazenar e gerenciar parâmetros para cada ambiente no seu pipeline. Isso permite que você especifique se os seus scripts de implantação serão acionados automaticamente com base no resultado do estágio anterior.

Fornecer feedback

Uma função central de um servidor de CI é fornecer feedback rápido em cada estágio de build e teste. Os servidores de CI que se integram ao seu IDE ou à sua plataforma de comunicação podem notificar você sempre que uma de suas alterações causar falha no pipeline, sem exigir o monitoramento constante do seu progresso.

Os servidores de build também podem:

  • Oferecer relatórios em tempo real sobre builds e testes que estão em andamento e notificar sobre o status das etapas de build concluídas.
  • Integrar-se a ferramentas de rastreamento de issues, para que você possa ver os detalhes das correções que foram incluídas em um commit e investigar rapidamente a causa de uma falha.
  • Agrupar estatísticas sobre a frequência de implantação, o tempo até a próxima falha e o tempo médio até a resolução, para ajudar você a medir e aprimorar seu processo de desenvolvimento.
  • Fornecer insights sobre o uso e o desempenho do servidor de CI e das máquinas de build, que você pode usar para otimizar seus pipelines.
O que os servidores de build podem fazer

Você deve criar seu próprio servidor de CI?

Criar seu próprio servidor de CI pode parecer uma opção atraente. Ao projetar sua própria solução, você pode adaptá-la às suas necessidades e evitar custos de licença.

Entretanto, a criação de uma ferramenta personalizada é apenas o início do processo. Uma vez instalado, você precisará investir tempo para mantê-lo atualizado, incluindo resolver quaisquer bugs que possam surgir e desenvolver novos recursos à medida que as exigências evoluírem.

Também vale a pena considerar o esforço envolvido na integração de um servidor de CI com a sua toolchain. Embora seu projeto inicial funcione com o sistema de controle de versão, o rastreador de issues, as ferramentas de build e as frameworks de teste que você usa atualmente, o que acontece na hora de migrar para um novo produto ou tecnologia?

Embora a criação de seu próprio servidor de CI ofereça a flexibilidade de criar uma ferramenta sob medida para o seu caso de uso, o esforço inicial e a manutenção contínua exigem um compromisso significativo e contínuo.

Concluindo

Um servidor de integração contínua desempenha um papel vital na implementação do seu pipeline de CI/CD, coordenando e acionando as várias etapas do seu processo e agrupando e entregando dados de cada estágio. Dê uma olhada no nosso Guia para ferramentas de CI/CD para dicas sobre como escolher o servidor de CI ideal para sua organização.

Como o TeamCity pode ajudar

O TeamCity é um servidor de CI que oferece integrações com todos os principais sistemas de controle de versão, incluindo Git, Perforce, Mercurial e Subversion, além de vários serviços de hospedagem. Você também encontrará amplo suporte para uma grande variedade de ferramentas de build e frameworks de teste, bem como integrações com IDEs, rastreadores de issues, plataformas de mensagens e gerenciadores de container.

Você pode hospedar seu servidor de CI localmente ou em uma nuvem de sua escolha com o TeamCity Professional ou Enterprise, ou ainda optar pelo TeamCity Cloud para obter uma solução totalmente gerenciada. Um conjunto flexível de acionadores de pipeline permite que você configure processos de CI/CD para atender às suas necessidades, incluindo commits pré-testados, suporte a branches de recursos e builds programadas. Depois de configurar a lógica do pipeline por meio da interface do usuário, você pode armazenar sua configuração como código para um processo de CI/CD com total controle de versão.