Desafios do Mundo Real com Inner e Outer Development Loops

O CPS1 foi criado para atender a necessidade de mudança nas práticas de desenvolvimento de software. Nosso produto ataca diretamente esses desafios e aprimora os processos de desenvolvimento.

Acreditamos que, para alcançar escalabilidade na entrega de software, é necessária uma abordagem centralizada para gerenciar ambientes de desenvolvimento, abandonando o trabalho individual no laptop de cada desenvolvedor.

Para entender nossa visão para o CPS1, devemos compreender os conceitos de inner e outer development loops. Para aqueles não familiarizados com a terminologia, essas duas frases se referem a diferentes aspectos do fluxo de trabalho de desenvolvimento de software.

O inner loop envolve o ciclo de um desenvolvedor individual de codificar, construir e testar mudanças. Esse processo ocorre no computador do desenvolvedor, dentro de um ambiente local, permitindo feedback rápido até que o código esteja pronto para revisão como um pull request (PR).

Em contraste, o outer loop ocorre depois que um desenvolvedor envia o código para um repositório. Esta fase envolve a integração das mudanças na branch principal, geralmente acionando uma pipeline de CI/CD que testa e constrói o novo código, criando no final um artefato pronto para produção para deploy.

Embora a distinção entre o inner e o outer loops possa parecer simples, uma área cinzenta significativa geralmente existe entre eles. Isso pode criar atritos no fluxo de trabalho de desenvolvimento que são frequentemente negligenciados pelos desenvolvedores.

Vamos falar sobre cinco desafios comuns do inner e outer loop:

• Processo de build complicado
• Síndrome do "na minha máquina funciona"
• Longos atrasos para feedback
• Trocas de contexto custosas
• Desvio de configuração (configuration drift)

Processo de build complicado

A adoção de containers resultou em grandes ganhos em relação a operações, escalabilidade, aumento da densidade e melhor uso dos recursos computacionais.

Do lado do desenvolvedor, no entanto, com a adoção do desenvolvimento cloud-native e containerizado, o inner development loop geralmente fica mais lento, devido à necessidade de ferramentas extras e complexidade para lidar com containers, criando um fardo para os desenvolvedores que vai além da linguagem de programação e do framework de uma determinada aplicação.

A codificação permanece a mesma, mas ela precisa ser containerizada na etapa de build, exigindo que um desenvolvedor execute passos extras para testar as alterações de código.

Os scripts e as instruções para se executar um build localmente provavelmente diferem da sua configuração de CI/CD. Essencialmente, isso significa que o desenvolvedor não consegue construir adequadamente uma mudança de código no inner loop como em produção, estendendo o processo até o outer loop.

Exemplos desses passos extras incluem a construção de imagens de container e o manuseio do Kubernetes, como escrever manifestos e fazer deployments em um cluster. Embora o uso de ferramentas como kind ou K3s possa ajudar, isso cria um imposto para o desenvolvedor que não tem nada a ver com a codificação.

Síndrome do "na minha máquina funciona"

Mesmo que uma equipe adote uma linguagem de programação e um framework específicos, os desenvolvedores da mesma equipe terão várias preferências pessoais sobre como configurar seu ambiente de desenvolvimento local para o inner loop.

Se uma equipe tem 8 desenvolvedores, não seria surpreendente encontrar 8 combinações diferentes para rodar a mesma aplicação.

Testar no inner loop pode ser inviável ou insuficiente porque o laptop do desenvolvedor não possui os recursos ou o acesso necessários. Portanto, os desenvolvedores não podem validar a eficácia de seu código.

Além disso, as ferramentas do inner loop muitas vezes diferem significativamente da pipeline de CI/CD, o que significa que o processo de teste se estende para o outer loop, causando um lead time maior para as mudanças.

Algumas mudanças só são verificáveis passando pelo processo de CI/CD para construir e implantar em um ambiente de destino, devido a desafios como limitações de recursos do sistema local, requisitos do ambiente de staging ou necessidades de acesso à rede.

O outer loop torna-se uma dependência para testes confiáveis e uma dependência para o trabalho do inner loop.

Quando o outer loop é considerado, vemos constantemente desenvolvedores usando várias soluções alternativas juntamente com uma lista de processos não documentados para realizar seu trabalho e passar para a próxima tarefa, devido a várias limitações e restrições sobre o que pode realmente ser feito em seus ambientes de desenvolvimento locais, em comparação com um ambiente de dev/staging.

Longos atrasos para feedback

Enquanto está no inner loop, o desenvolvedor normalmente codifica, executa, testa, depura, antes que suas mudanças possam ser apresentadas e compartilhadas com outros membros da equipe.

Depois que um desenvolvedor termina uma determinada tarefa, o outer loop geralmente começa com o código sendo enviado para integração, incluindo a revisão de código e uma série de outras tarefas definidas em uma pipeline de CI/CD, para só então ser finalmente implantado em um ambiente de dev/staging para mais testes e validação de QA.

Esse fluxo de trabalho típico resulta em interações de equipe que levam mais tempo devido à sua dependência do outer loop.

Os desenvolvedores não compartilham seu trabalho enquanto estão no inner loop, então outros membros da equipe não podem vê-lo até que seja enviado para o outer loop.

Um feedback valioso é adiado enquanto se aguarda as pipelines de CI/CD, o que atrasa o trabalho e retarda os lançamentos em produção.

Um cenário comum é que os desenvolvedores de frontend precisam esperar por pré-visualizações das mudanças do backend em um ambiente de staging compartilhado ou confiar em mocks e stubs. Por outro lado, os desenvolvedores de backend precisam esperar que as pipelines de CI/CD construam e implantem para verificar se seu código funciona corretamente quando existem dependências baseadas na nuvem.

Não é surpreendente que, na maioria das empresas, existam certamente várias mudanças que só podem ser minimamente testadas após serem implantadas em algum tipo de ambiente de dev/staging.

Trocas de contexto custosas

Quando o fluxo de trabalho de desenvolvimento atinge o outer loop, é onde ocorrem os gargalos mais severos, muitas vezes esperando que outros colegas de equipe avancem com o processo de desenvolvimento, especialmente as revisões de código.

Os desenvolvedores veem as revisões de código como uma das melhores oportunidades para compartilhar conhecimento e aumentar a qualidade geral da base de código.

As revisões de código acontecem no outer loop, e é comum que o processo eventualmente se torne um gargalo por vários motivos. Uma das causas é que os revisores precisam alterar seu ambiente de desenvolvimento local para executar adequadamente a aplicação e comentar sobre as novas mudanças no código.

O autor de um merge request pode iniciar outra tarefa enquanto espera, o que causará mais trocas de contexto. Esse vaivém entre o inner e o outer loops causa atrasos até que o código esteja realmente pronto para ser integrado.

Desvio de configuração (Configuration drift)

Tornar o inner loop (desenvolvimento local), o outer loop (ambientes remotos e CI/CD) e o ambiente de produção consistentes e previsíveis é absolutamente penoso e difícil.

A cadeia de ferramentas para o inner loop é normalmente configurada de forma totalmente diferente da cadeia de ferramentas nas pipelines de CI/CD.

Citando Matt Rickard, criador da ferramenta scaffold:

Um bom inner dev loop é rápido e correto. Em teoria, é fácil ser "correto": trabalhe em um ambiente o mais próximo possível da produção e execute um ciclo de build e deploy de produção a cada mudança. Isso geralmente é muito lento. "Correto" é tão importante porque evita bugs de reprodutibilidade que são notoriamente difíceis de rastrear e corrigir. - The Dev Inner Loop

Tornar o inner loop correto e rápido, como Matt afirmou, não é fácil. Geralmente, o inner loop será otimizado para um feedback rápido das mudanças, em vez de uma configuração mais semelhante à de produção, aproveitando ferramentas de melhoria de desempenho, como compilação em segundo plano na IDE ou recarregamentos automáticos da aplicação após reconstruções. Isso garante que não haja necessidade de esperar quando um desenvolvedor troca de contexto, como passar da IDE para o navegador para testar.

Isso, por sua vez, significa que você não pode ter confiança de que a alteração de qualquer configuração de desenvolvimento no inner loop não afetará o outer loop, como a pipeline de CI/CD e o ambiente de produção.

Como o CPS1 impacta os inner e outer development loops

O CPS1 é uma solução que simplifica a transição do desenvolvimento de software nativo em nuvem de ambientes locais baseados em laptops para a nuvem. Ele está disponível como um SaaS pay-as-you-go ou como uma opção instalável em sua conta na nuvem.

Ao gerenciar e alocar recursos de forma inteligente e automática, o CPS1 aprimora todo o seu processo de desenvolvimento, eliminando as restrições e limitações das configurações tradicionais baseadas em laptops, resultando em um fluxo de trabalho mais rápido.

Workspaces sob demanda

O CPS1 cria workspaces sob demanda e isolados usando nossa tecnologia de detecção que pode inspecionar instantaneamente seu código e definir com precisão requisitos como linguagens de programação, frameworks, bancos de dados e muito mais, sem a necessidade de qualquer configuração manual.

O workspace proporciona uma Developer Experience fluida para codificar, construir e testar aplicações complexas, incluindo microserviços, sem depender de pipelines de CI/CD ou deploys em ambientes de staging para testes adequados.

O único requisito é um navegador web, onde o desenvolvedor acessa uma IDE Visual Studio Code integrada ao seu workspace.

Ambientes de pré-visualização automatizados

Cada workspace pode ser usado para colaborar facilmente com colegas de equipe, compartilhando instâncias ativas e acessíveis do código em execução, contornando a necessidade de deploys e configurações de rede complexas.

O compartilhamento de workspaces reduz drasticamente o lead time para entregar