Serviço constante
A entrega contínua (CD) é a prática de usar a automação para liberar o software em iterações curtas
O que é entrega contínua?
A entrega contínua é uma abordagem na qual as equipes lançam produtos de qualidade com frequência e previsão do repositório do código fonte para produção de maneira automatizada.
Algumas empresas lançam produtos elas mesmas, passando-os de uma equipe para a outra. Veja o diagrama abaixo. Em geral, os desenvolvedores estão na extremidade esquerda deste espectro e o pessoal de operações está na extremidade receptora. Há um atraso em cada entrega que leva a equipes frustradas e clientes insatisfeitos. O produto, por fim, é ativado por meio de um processo tedioso e propenso a erros que atrasa a geração de receita.
Figura 1: Lançamento manual de produtos aos clientes
Agora, confira o pipeline de entrega contínua abaixo. Ele ilustra como os desenvolvedores escrevem o código em seus laptops e confirmam essas mudanças para um repositório de código-fonte, como Bitbucket. Por código, queremos dizer o sistema em teste, os testes e a infraestrutura que vai ser usada para implementar e manter o sistema. Os Bitbucket Pipelines podem enviar o produto do teste para a plataforma de produção e ajudar os clientes a colocar as mãos nessas novas funções brilhantes.
Figura 2: Pipeline de entrega contínua fazendo lançamentos automatizados
Como funciona a entrega contínua?
Um pipeline de entrega contínua pode ter um portão manual logo antes da produção. Um portão manual exige intervenção humana e pode haver cenários em sua organização que exijam portões manuais em pipelines. Alguns portões manuais podem ser questionáveis, ao passo que outros podem ser legítimos. Um cenário legítimo permite que a equipe de negócios tome uma decisão de lançamento de última hora. A equipe de engenharia mantém pronta uma versão do produto que pode ser enviada após cada sprint e a equipe de negócios faz a chamada final para lançar o produto a todos os clientes ou a uma parte da população ou, ainda, talvez a pessoas que vivem em uma determinada localização geográfica.
A arquitetura do produto que flui pelo pipeline é um fator chave que determina a anatomia do pipeline de entrega contínua. Uma arquitetura de produto altamente acoplada gera um padrão de pipeline gráfico complicado, em que vários pipelines poderiam ficar presos antes de finalmente irem para a produção.
A arquitetura do produto também influencia as diferentes fases do pipeline e quais artefatos são produzidos em cada fase. O pipeline primeiro cria componentes — as menores unidades distribuíveis e testáveis do produto. Por exemplo, uma biblioteca criada pelo pipeline pode ser chamada de componente. Esta é a fase do componente.
Componentes frouxamente acoplados compõem subsistemas — as menores unidades implementáveis e executáveis. Por exemplo, um servidor é um subsistema. Um microsserviço em execução em um recipiente também é um exemplo de subsistema. Esta é a fase do subsistema. Ao contrário dos componentes, os subsistemas podem ser levantados e testados.
Uma vez que o pipeline pode ser ensinado com o fim de montar um sistema de sistemas de acoplamento fraco em instâncias que o sistema todo pode ser lançado como um todo. Esta é a fase do sistema.
A gente não recomenda esta composição onde subsistemas são combinados em um sistema. Veja a ilustração disso na Figura 3.
Figura 3: subsistemas tendo que ser montados em um sistema
Esta abordagem tudo ou nada faz com que o subsistema mais rápido vá na velocidade do mais lento. “A corrente é tão forte quanto seu elo mais fraco” é um clichê que usamos para avisar as equipes que são vítimas desse padrão de arquitetura.
Uma vez validado, o sistema montado é promovido à produção sem mais nenhuma modificação, na fase final, chamada fase de produção.
Note que essas fases são mais lógicas do que físicas e são criadas apenas para quebrar um problema grande em vários subproblemas menores. Você pode ter menos ou mais fases, dependendo de sua arquitetura e de seus requisitos.
Velocidade sem qualidade é inútil para os clientes. O teste contínuo é uma técnica em que testes automatizados são integrados com o pipeline de entrega de software e validam cada mudança que flui por ele. Os testes são executados em cada fase do pipeline para validar os artefatos produzidos nessa fase. Os testes de unidade e a análise de código estático validam componentes na fase de componentes do pipeline. Testes funcionais, de desempenho e de segurança validam subsistemas na fase de subsistema. Testes de integração, desempenho e segurança validam sistemas na fase de sistemas. Por último, testes de sanidade validam o produto na fase de produção.
Testes automatizados são integrados com o pipeline
A arquitetura monolítica de produtos, que a gente chama de Grande Bola de Lama, pode resultar em Grandes Bolas de Testes. A gente recomenda investir em microsserviços para que os artefatos implementáveis com independência possam fluir pelos pipelines sem precisar de um ambiente muito integrado para certificação. Além disso, os artefatos implementáveis com independência permitem que equipes mais rápidas não sejam sobrecarregadas pelas equipes mais lentas.
Valor de entrega contínua
O pipeline de entrega de software é um produto em seu próprio direito e deveria ser prioridade para os negócios, caso contrário, os produtos geradores de receita não deveriam ser enviados através dele. A entrega contínua agrega valor de três maneiras: melhora a velocidade, a produtividade e a sustentabilidade das equipes de desenvolvimento de software.
Velocidade
Velocidade significa velocidade responsável e não velocidade suicida. Os pipelines devem lançar produtos de qualidade aos clientes. A menos que as equipes sejam disciplinadas, os pipelines podem enviar código com defeito para a Produção, só que mais rápido! Os pipelines de entrega de software automatizados ajudam as empresas a responder melhor às mudanças do mercado.
Produtividade
Um pico na produtividade ocorre quando tarefas tediosas, como enviar um pedido de mudança para cada mudança que vai para produção, podem ser executadas por pipelines em vez de por pessoas. Isso permite que as equipes de Scrum foquem em produtos que despertam a atenção do mundo, em vez de drenar sua energia em logística. isso pode tornar os membros da equipe mais felizes, mais engajados em seu trabalho e fazer com que queiram ficar mais tempo na equipe.
Sustentabilidade
Sustentabilidade é fundamental para todas as empresas, não apenas as de tecnologia. "O software está consumindo o mundo” não é mais verdade — o software já consumiu o mundo! Cada empresa no final do dia, seja em cuidados de saúde, finanças, varejo ou algum outro domínio, usa a tecnologia para se destacar e vencer a concorrência. A automação ajuda a reduzir/eliminar tarefas manuais que são repetitivas e propensas a erros, posicionando, assim, a empresa para inovar melhor e mais rápido para atender às necessidades dos clientes.
Quem deve fazer a entrega contínua e quando?
Quando é um bom momento para adotar a entrega contínua? Foi ontem.
As equipes precisam de um único backlog priorizado no qual:
- a entrega contínua tenha sido adotada, em vez de relegada ao plano de fundo
- Os critérios de aceitação das histórias do usuário mencionem com destaque as abordagens automatizadas de entrega de software em vez de manuais e
- A definição de concluído (DoD) do sprint impeça que as equipes terminem sprints em que o lançamento manual dos produtos tenha sido feito
Entrega contínua é a coisa certa a fazer e, de vez em quando, requer que campeões iniciem a transformação. Às vezes, quando projetados sem erros, os pipelines de entrega contínua se pagam sozinhos.
Então, quem está envolvido?
Algumas empresas colocam pessoas inexperientes para projetar e implementar pipelines de entrega contínua e aprenderam da maneira mais dura que havia profundas complexidades envolvidas. Indicar membros júnior envia o sinal errado para as equipes e implica que a entrega contínua tem baixa prioridade. Recomendamos colocar um arquiteto sênior encarregado, que tenha uma profunda apreciação pela tecnologia e pelos negócios.
Além da entrega contínua
Onde quer que a gente esteja em nossa caminhada rumo ao tudo contínuo (integração, teste|, entrega, implementação, dados de análise etc.), ela não é nem uma checklist nem um destino e a melhoria contínua está no centro.
Cedo ou tarde, todos na empresa recebem um chamado quando os pipelines de entrega contínua estão sendo construídos. Executivos, engenharia, gerenciamento de produto, governança, risco, conformidade, InfoSec, operações, jurídico e o que mais tiver. Os pipelines corroem os silos e quebram paredes. A gente faz parte desta transformação, de um jeito ou de outro, e todos os contínuos são o novo normal!
Comece a usar a CI/CD
Para a prática de CI/CD, você pode usar ferramentas que automatizem o desenvolvimento, a implementação e os testes. Ferramentas específicas oferecem integração, outras oferecem desenvolvimento e implementação, enquanto outras oferecem testes.
A Atlassian oferece uma solução Open DevOps que garante processos completos de DevOps incluindo CI/CD. As equipes podem usar várias ferramentas de CI/CD, incluindo o Bitbucket Pipelines, um serviço de CI/CD integrado ao Bitbucket. Ele permite que você crie, teste e implemente seu código direto, com base no arquivo de configuração em seu repositório. O Open DevOps também se integra com outras ferramentas CI/CD incluindo Harness, GitLab, JFrog, Codefresh e CircleCI.
A seguir, há uma análise mais minuciosa das integrações Open DevOps. Verifique os tutoriais CI/CD de DevOps.
Registre-se para ter acesso a mais artigos e tutoriais sobre CI/CD e DevOps
