I would like to view this page in
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.
Um servidor de CI funciona como um ponto central para coordenar todas as suas atividades de CI/CD. Usar um servidor de CI:
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.
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:
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.
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:
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.
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.
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.
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.
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:
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.
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.
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.
Entrega contínua, ou Continuous Delivery (CD) em inglês, é a prática de automatizar as etapas manuais necessárias do processo de build e lançamento de um software.
Como guias versus espaços, estratégias de branching representam um daqueles tópicos emocionantes que desencadeiam debates acalorados tanto online quanto offline.
O que exatamente é um pipeline de integração contínua/entrega contínua? E como você consegue um? Descubra neste artigo.