As tecnologias nativas da nuvem nos permitiram executar sistemas cada vez maiores e mais complexos em escala. Os contêineres garantem que as unidades de implantação sejam empacotadas de maneira organizada e consistentes em todos os tempos de execução. O Kubernetes ajuda a garantir que esses contêineres estejam íntegros e disponíveis para usuários sob diferentes cargas. E as pilhas de monitoramento oferecem uma visibilidade incrível do desempenho e do comportamento dos sistemas.
Mas à medida que as empresas investiam recursos na adoção dessas tecnologias, a experiência do desenvolvedor (DevEx) era frequentemente deixada de lado.
As empresas estão a acordar para o facto de que, embora os seus sistemas de produção sejam mais capazes, os seus processos de entrega ficaram mais lentos. “Chefe de experiência do desenvolvedor” agora é um título comum, e empresas maiores têm até equipes inteiras de experiência do desenvolvedor (muitas vezes, mas nem sempre, sobrepostas às equipes de plataforma).
O que levanta a questão: pelo que essas equipes deveriam se esforçar? Qual é o novo padrão ouro para a experiência do desenvolvedor no desenvolvimento nativo da nuvem? Com quem eles se comparam? E quais ferramentas estão disponíveis?
Na Garden, pensamos no Kubernetes DevEx desde o dia zero, mesmo que às vezes seja considerado um “problema do dia 2”. Com base no que aprendemos e nas equipes com as quais trabalhamos, desenvolvemos um modelo de maturidade de desenvolvimento nativo da nuvem para equipes que executam Kubernetes em produção. Cada nível tem prós e contras, e as equipes precisam decidir qual é o seu ponto ideal.
Talvez você coloque toda a sua fé em contratos rígidos de API. Ou talvez você ainda não tenha chegado lá. De qualquer forma, você deve ter todos os recursos para implantar sua pilha em um ambiente semelhante ao de produção – afinal, é assim que ela funciona na produção.
Agora é um bom momento para pensar em transferir os recursos restantes e capacitar as equipes para interagir com um sistema totalmente executado em um ambiente de área restrita.
Você tem um único ambiente de preparação ou teste de aceitação do usuário (UAT) onde as alterações são implantadas antes de serem implementadas na produção. Este é um ótimo primeiro passo, mas é provável que a carga de manutenção seja alta e as equipes estejam se atrapalhando ou as mudanças estejam na fila e retardando o processo de entrega.
Isso é surpreendentemente comum, e trabalhamos com muitas equipes muito capazes, cuja maior fonte de frustração é um ambiente de teste na fila. Ou pior, aquele que não tem fila, mas sim versões diferentes que se sobrepõem.
Isso pode ser um grande gargalo e, para a maioria das equipes, vale a pena avançar para o próximo nível.
Nesse nível, cada solicitação pull cria um ambiente de visualização isolado, semelhante ao de produção. Esses ambientes podem ser compartilhados com as partes interessadas e testados por engenheiros de garantia de qualidade (QA).
Um grande benefício é que isso abre a porta para a execução adequada de integração e testes ponta a ponta. Eles exigem ambientes isolados de produção e, nesse nível, você os possui.
Isso é muito útil, mas seus desenvolvedores provavelmente estão frustrados, presos em ciclos intermináveis de commit-push-wait. Se um teste de ponta a ponta for instável (como costuma acontecer), seus desenvolvedores estão enviando commits vazios para reativar o pipeline.
Se estiver quebrado, eles estão fazendo um esforço para consertar as coisas e esperando pelo melhor. Dependendo da velocidade dos seus pipelines, dias inteiros podem ser perdidos nesse ciclo de empurrar e orar.
Os engenheiros também podem ter dificuldade para escrever e manter testes de integração e ponta a ponta, devido aos lentos ciclos de feedback.
Isso é semelhante à etapa anterior, exceto que a criação do ambiente é deslocada um passo à esquerda.
Qualquer pessoa agora pode criar ambientes isolados sob demanda sem acionar um pipeline de CI. Isso permite que os desenvolvedores inspecionem e interajam com seus sistemas conforme eles codificam. Além do mais, eles podem executar integração e testes completos sob demanda, eliminando muitos atritos de seus fluxos de trabalho.
Estamos fazendo um grande progresso, mas o problema com esse fluxo de trabalho é que a ativação do ambiente pode demorar um pouco, especialmente porque as alterações no código provavelmente exigirão uma reconstrução completa. Você pode contornar isso acessando o serviço em execução e fazendo as alterações lá, mas isso é um DevEx abaixo da média e as alterações serão perdidas se o pod for reiniciado.
Isso ainda é uma melhoria em relação à necessidade de passar pela CI, mas podemos fazer melhor.
Nesse nível, os engenheiros desenvolvem em um ambiente totalmente remoto, isolado e semelhante ao de produção. Eles fazem alterações no código localmente e essas alterações são sincronizadas em tempo real com os serviços em execução, sem exigir reconstrução ou reimplantação.
Geralmente há uma compensação entre o realismo e a velocidade do ciclo de feedback – mas aqui você tem o seu bolo e também o está comendo.
Os URLs para instâncias de desenvolvimento também são exclusivos, para que os desenvolvedores possam compartilhar rapidamente seu trabalho enquanto ele está em andamento ou dar uma olhada no que outros estão fazendo. É ótimo para colaboração, pois os desenvolvedores podem inspecionar recursos e logs em outros namespaces e ajudar seus colegas de equipe.
É trabalhoso chegar a esse nível, mas abre a porta para alguns fluxos de trabalho realmente interessantes e capacita todos na equipe com as ferramentas e capacidades que apenas as operações tinham antes.
Agora você está fazendo coisas realmente avançadas. Tudo é remoto, inclusive o código que você está escrevendo. Você pode trabalhar em qualquer dispositivo, em qualquer lugar, e todo o seu ambiente é cuidadosamente selecionado.
Existem muitos produtos realmente interessantes como Coder, Gitpod e GitHub Codespaces para desenvolvimento remoto. Mas falta-lhes a automação necessária para criar, implantar e testar sistemas distribuídos e microsserviços.
Combine os fluxos de trabalho do nível 4 usando ferramentas como Garden com ferramentas de desenvolvimento remoto como Coder, e você poderá alcançar a iluminação do Kubernetes DevEx.
Alcançar o nirvana do desenvolvimento nativo da nuvem tem tanto a ver com a jornada quanto com o destino, mas ferramentas como o Garden podem tornar mais fácil do que você jamais imaginou ser possível chegar à parte boa.
Se você quiser um atalho para o nível 5, criamos um projeto de exemplo com Garden e Coder para que você possa usar os ambientes de produção sob demanda do Garden e a plataforma de desenvolvimento remoto auto-hospedada do Coder juntos. Isso significa que você poderá desenvolver um sistema de qualquer complexidade de forma totalmente remota, com feedback instantâneo que parece local.
Capacitar sua equipe de desenvolvimento com as mesmas ferramentas e recursos que você já possui em produção e CI não apenas acelera a entrega, mas também espalha o conhecimento.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
