.
Artemis Diana / Getty Images
Uma das coisas mais importantes que aconteceram na evolução do desenvolvimento nos últimos anos é a ampla adoção da integração contínua e implantação contínua, ou CI/CD. (Às vezes, o “CD” significa “entrega contínua”, dependendo de com quem você está falando.)
É um conceito que descarta muitas ideias antigas sobre como os sistemas devem ser gerenciados e, em vez disso, oferece uma maneira de atualizar o código e integrar as alterações como implementações contínuas ao mesmo tempo em que garante que o novo código seja testado e se encaixe perfeitamente no que já está em execução. Um pipeline de CI/CD adequadamente arquitetado significa que você pode obter alterações de código em produção mais rapidamente e com menos erros. Mas como é isso na prática?
Parece Strong The One, porque adotamos um fluxo de trabalho de CI/CD para aproveitar ao máximo a flexibilidade oferecida pela hospedagem em nuvem sem servidor. Bem-vindo à terceira parte de nossa série de quatro partes sobre como hospedamos o Ars – aqui, vamos nos afastar do lado “ops” de “DevOps” e examinar mais de perto a parte “dev”. Junte-se a nós para dar uma olhada nos bastidores de como o Ars usa CI/CD em nossos aplicativos implantados e em nosso gerenciamento de infraestrutura!
O controle de versão não é opcional
Para o benefício das pessoas que fazem apenas a parte “ops” do DevOps, vamos obter uma definição de trabalho para “controle de versão”, já que o termo sustenta toda a nossa abordagem em relação à manutenção do código. Quando dizemos “controle de versão” neste contexto, estamos falando de um método pelo qual podemos rastrear as alterações feitas em nossa base de código de produção – ou seja, o repositório de arquivos que faz o Ars funcionar.
Garantir que a base de código de produção esteja sujeita a alguma forma de controle de versão é como ativar “rastrear alterações” no Word: o sistema de controle de versão mantém um registro de cada alteração feita em cada arquivo, juntamente com uma lista correlacionada de quem fez a alteração e quando aconteceu. O controle de versão é um componente crítico da maioria dos projetos de TI de grande escala e, em alguns casos, é até mesmo um requisito regulamentar obrigatório.
Mas o controle de versão é um problema difícil de resolver, e muitas das soluções que são comuns agora – incluindo e especialmente o Git – ainda são relativamente novas. Não faz muito tempo, houve uma época da qual não me lembro com carinho – uma época em que você editava o código em um editor de texto e depois o transferia por FTP para um servidor de produção. Esta foi uma era baixa e suja, repleta de alterações perdidas, falhas de produção e backups ad hoc com nomes como oops-1997-05-21.tar.gz. Para ter certeza, mesmo naqueles dias primitivos, havia magos barbudos que falavam de tecnologias inescrutáveis como CVS (Sistema de Versões Concorrentes, não a farmácia), mas tais coisas estavam visivelmente ausentes da experiência da maioria das pessoas dentro do universo florescente do desenvolvimento web. .
Embora muitos de nós provavelmente nos lembremos dos repositórios SVN (e com muitos pensamentos e orações para aqueles de vocês que ainda lidam com SVN), não foi até o Git que o controle de versão ganhou enorme popularidade. Por que? Em parte porque ferramentas como Git e GitHub simplificaram a criação e manutenção de repositórios – basta digitar alguns comandos e você está pronto para usar. A maioria dos desenvolvedores do mundo agora mantém repositórios de código no GitHub, e Ars não é exceção.
Como as mudanças fluem do GitHub para os aplicativos implantados?
Bem, começamos ativando nosso cliente FTP favorito, o Transmit. Estou brincando, estou brincando – mas o Transmit era (e aparentemente ainda é) um aplicativo incrível. De verdade, agora: começamos trabalhando em uma ramificação específica em um de nossos repositórios. Lembre-se de nossas parcelas anteriores que o Ars é composto por quatro aplicativos principais, cada um executando em seu próprio contêiner dentro das tarefas do AWS ECS:
- Arx: nossa configuração de desenvolvimento local do Docker Compose e contêiner do servidor Nginx
- Acta: O principal aplicativo do WordPress
- Civis: Nosso software de fórum de discussão
- Taberna: Nosso sistema de e-commerce e assinatura
Cada um desses aplicativos tem seu próprio repositório no GitHub. Quando grandes alterações são feitas, uma nova ramificação é criada. Eventualmente, essa nova ramificação de recurso será mesclada em uma ramificação de teste por meio de uma solicitação pull. Após o teste, a preparação será mesclada na ramificação principal com outra solicitação pull.
.
