Ultrapassando os limites da entrega contínua, pode-se alterar fundamentalmente a maneira como as pessoas colaboram na criação de software. Christian Uhl apresentou na DevOpsCon Munich 2019 como a implantação de cada feature branch usando o GitLab e o Kubernetes os ajuda a obter feedback rápido dos product owners e stakeholders.
Uhl falou sobre como eles não acumulam mais os recursos que estão prontos para serem liberados. Cada branch é implantado em seu próprio ambiente e cada recurso vai direto para produção:
O benefício de implantar a menor unidade possível (em vez de um conjunto de coisas) é minimizar o risco. Acho que o livro Accelerate, da Nicole Forsgren, explica muito melhor do que eu poderia fazer, e certamente experimentamos um baixo nível de defeitos, como o livro promete.
A implantação do trabalho em cada branch foi uma decisão que eles tomaram depois que descobriram que muitos problemas ocorreram não porque eles criaram uma coisa quebrada (bugs), mas sim, a coisa errada (requisitos incompreendidos). Uhl mencionou que, quando eles mostram a interface do usuário de um branch implantado para o product owner or a stakeholder enquanto estão desenvolvendo, eles instantaneamente têm uma discussão mais significativa.
Uhl explicou como sua abordagem à entrega contínua afeta a maneira como eles fazem as análises de produtos:
Normalmente, uma revisão do produto é assustadora, porque trata-se de "meu recurso passará aos olhos do product owner?" Isso leva a tensões e compromissos. Agora, com todos se sentando juntos enquanto isso acontece, isso se tornou uma colaboração. Encontramos muitos ajustes e melhorias em nossas ideias no processo de desenvolvimento que não teríamos encontrado de outra forma. Estou muito orgulhoso de muitos dos recursos do matmatch.com e da rapidez com que podemos dar vida a ideias agora.
Na Matmatch, eles aproveitam a maioria das ferramentas fornecidas pelo GitLab e pelo Kubernetes. Cada branch é criado, dockerizado e, em seguida, implantado com um nome gerado. Além disso, alguns roteiros são criados. Com uma configuração de implantação declarativa, é questão de parâmetros para implantar um branch na feature1.domain.com em vez de no domain.com, explicou Uhl. Após concluir a revisão do código e a aprovação dos stakeholders, eles fazer o merge do branch para o master, e deletam o deploy.
O InfoQ entrevistou Christian Uhl, engenheiro chefe da Matmatch, após sua palestra na DevOpsCon Munich 2019.
InfoQ: Quais os fatores que o levaram a melhorar sua pipeline de entrega contínua? Qual foi a necessidade?
Christian Uhl: Somos uma startup e, como tal, temos uma espaço limitado (ou tempo para provar que podemos ser bem-sucedidos), e no início de tal empreendimento, você realmente não sabe o que seus usuários querem. Então, quase tudo que você constrói está errado, e você precisa mudar as coisas rapidamente para encontrar o pote de ouro.
Como exemplo, tínhamos um recurso inicial em que os engenheiros eram capazes de criar uma coleção de materiais como um "Projeto" e podiam compartilhá-los, mas descobrimos rapidamente que o uso era muito baixo. Posteriormente, criamos um recurso em que as pessoas podiam salvar materiais individuais, agora usados com muita frequência.
Para não ter nenhuma distração na criação de valor para o usuário, decidimos que a implantação de software deve ser totalmente automatizada e chata. Também precisamos descobrir o que funciona e o que não funciona super rápido. Não podemos esperar mais duas semanas após concluir um recurso para começar a registrar o comportamento do usuário.
InfoQ: Como são feitos os testes dentro do pipeline?
Uhl: Seguimos a pirâmide clássica de testes de unidade, integração, e testes de ponta a ponta. Tínhamos o cuidado de reduzir ao mínimo a quantidade de testes de ponta a ponta, mas ainda testando o núcleo fundamental da plataforma, basicamente as coisas que geram dinheiro. Esses testes são executados durante cada commit, e nada pode ser integrado antes de cada estágio ficar verde.
Como não há mais ambiente de staging antes que um recurso seja produzido, os desenvolvedores são incentivados a pensar cuidadosamente nos testes que escrevem - não há mais uma rede de segurança ou equipe de controle de qualidade para salvá-lo. Isso corresponde à ideia "você cria o código, você roda o código". O teste automatizado que criamos nos dá confiança suficiente para que nada importante seja quebrado. Com as ofertas de nuvem atualmente disponíveis, podemos fornecer uma máquina bastante poderosa para executar cada estágio de teste e descartá-la posteriormente, o que mantém nosso tempo de execução de teste em um nível aceitável.
Investimos muito na observabilidade do nosso sistema, para que possamos descobrir rapidamente quando ocorrem erros e corrigi-los. Rastreamos todos os erros ocorridos em nosso sistema e temos alertas para isso, para que possamos saber quando um novo recurso causa problemas. Além disso, verificamos antes do lançamento de um recurso que adicionamos algum rastreamento para descobrir se um recurso é aceito ou ignorado pelos usuários. No entanto, temos as ferramentas para reverter, mas honestamente, nunca as usamos. Guardamos para nossa paz de espírito.
InfoQ: Quais desafios teve ao construir seu pipeline de entrega contínua e como lidou com eles?
Uhl: Antes de tudo, é muito trabalho chegar ao ponto em que estamos. Tivemos que automatizar a implantação em si, o que já era um desafio, criar testes suficientes para termos confiança, e finalmente obter toda a configuração correta. Eu fui capaz de insistir nisso porque acreditava realmente no valor e na agilidade dos negócios que obteríamos, mas foi difícil justificar o tempo no estágio inicial de uma startup, quando há um milhão de outras coisas importantes a fazer. Não foi um grande desafio construir essa plataforma, apenas muitas pequenas coisas que precisávamos descobrir. Também esgotamos a capacidade nosso cluster Kubernetes mais de uma vez porque não deletemos tudo corretamente após o merge.
Mas, além dos problemas técnicos, havia muito medo no começo: implantar tudo diretamente na produção assustou as pessoas. Passei muito tempo explicando os benefícios que teríamos. Também começamos devagar, implantamos um serviço pequeno e não crítico o tempo todo antes de incluir os sistemas principais. Começar devagar ajuda muito.
Desde que fizemos essa jornada em 2017, as ferramentas melhoraram bastante. Eu acho agora é mais fácil do que nunca para começar - mas tivemos que tentar muito para aprender.