DevX

Ao longo de muitos anos trabalhando com sistemas distribuídos, ambientes regulados e plataformas de alta criticidade, a percepção que se consolida é que a maior parte das discussões sobre Developer Experience costuma atacar sintomas, não causas.

Grande parte das iniciativas se concentra em criar portais, abstrações ou fluxos guiados, enquanto os problemas mais relevantes continuam presentes no dia a dia do desenvolvedor: ambiente inconsistente, baixa reprodutibilidade, dependência de terceiros e ausência de mecanismos que garantam corretude.

Esses problemas impactam diretamente a capacidade de entrega, a qualidade do software e o risco operacional.

Onde a fricção realmente se acumula

Se observarmos a jornada de um desenvolvedor dentro de um sistema minimamente complexo, a fricção tende a se concentrar em alguns pontos bem específicos.

O primeiro deles é o setup inicial. Não é raro encontrar cenários onde diferentes distribuições de uma mesma tecnologia apresentam comportamentos distintos. No caso de Java, por exemplo, não basta definir uma versão do JDK. Diferenças entre distribuições podem gerar efeitos colaterais difíceis de diagnosticar. Quando se soma isso a variações de sistema operacional, como desenvolvimento em Windows e execução em Linux, o resultado tende a ser imprevisível.

Além disso, é comum a necessidade de configuração manual de proxies, certificados e variáveis de ambiente. Muitas vezes esses passos não estão documentados de forma adequada, ou dependem de conhecimento acumulado informalmente por alguns membros do time. Esse tipo de dependência cria um sistema frágil, onde o onboarding deixa de ser um processo técnico e passa a ser um processo social.

Outro ponto recorrente é a impossibilidade de executar partes relevantes do sistema localmente. Plataformas que só funcionam em ambiente cloud, com acesso restrito ou alto custo de execução, acabam limitando a capacidade de iteração do desenvolvedor. Isso se agrava quando o comportamento observado localmente não reflete o ambiente real, especialmente em cenários que envolvem concorrência, latência ou carga.

Testes também sofrem com problemas estruturais. Ambientes compartilhados, massa de dados suja e ausência de isolamento tornam difícil confiar nos resultados obtidos. Em muitos casos, validar uma feature depende de coordenação entre múltiplas pessoas, o que reduz drasticamente a eficiência do ciclo de desenvolvimento.

A documentação, quando existe, frequentemente está dispersa e mal indexada. Ferramentas corporativas acabam acumulando conteúdo ao longo do tempo sem uma estratégia clara de organização. O efeito prático é que encontrar informação relevante passa a ser uma atividade custosa, e novamente a dependência de pessoas se torna inevitável.

Segurança como propriedade do sistema, não do indivíduo

Um ponto que costuma ser subestimado em discussões de DevEx é segurança.

Em muitos ambientes, aspectos críticos como certificados, gestão de credenciais e configuração de comunicação segura ainda recaem sobre o desenvolvedor. Isso introduz fricção e assume um nível de perfeição humana que não existe na prática.

Um paralelo útil pode ser feito com linguagens de programação. Em C ou C++, é possível escrever código seguro, desde que não se cometam erros. Em Rust, o próprio modelo da linguagem reduz drasticamente a possibilidade de erro, guiando o desenvolvedor para caminhos mais seguros por padrão.

Esse mesmo princípio pode ser aplicado ao ambiente de desenvolvimento.

Imagens de container devem ser previamente homologadas e já conter:

  • certificados atualizados
  • políticas de segurança aplicadas
  • configurações seguras de rede
  • dependências auditadas

O desenvolvedor não deveria precisar configurar esses aspectos manualmente.

Além disso, pipelines de build e deploy devem incorporar validações de segurança que não possam ser ignoradas facilmente. Isso inclui análise de vulnerabilidades, validação de dependências e enforcement de políticas.

Outro ponto crítico é o isolamento do ambiente de execução.

Todas as ferramentas e execuções de código devem ocorrer em ambientes isolados do host. Isso reduz riscos relacionados a:

  • ataques de supply chain
  • execução de código malicioso
  • vazamento de credenciais
  • contaminação entre projetos

Ferramentas como containers com Docker ou Podman são um primeiro nível de isolamento. Em cenários mais rigorosos, é possível utilizar abordagens adicionais como sandboxes baseadas em namespaces, virtualização leve ou ambientes descartáveis por projeto.

Esse isolamento também resolve um problema prático importante: evitar que dependências de um projeto afetem outro. Sem isolamento, é comum que versões de bibliotecas, runtimes ou ferramentas entrem em conflito, gerando comportamentos difíceis de prever.

Existe um ponto de atenção importante. O processo de homologação de imagens e ferramentas precisa ser rápido. Novas versões estáveis de linguagens e frameworks devem estar disponíveis em tempo adequado. Caso contrário, cria-se um incentivo para uso de versões antigas, o que aumenta risco e dificulta evolução.

Segurança efetiva depende de enforcement técnico aliado a agilidade.

O que funciona de verdade

Ao longo das diferentes experiências, alguns padrões se mostram consistentemente mais eficazes.

Setup automatizado, reprodutível e projeto auto contido

Ambientes onde o setup é automatizado e executado de forma consistente reduzem drasticamente o tempo de onboarding e a quantidade de erros iniciais.

Um aspecto importante aqui é tratar o projeto como auto contido. Isso significa que tudo o que é necessário para executar o sistema deve estar acessível a partir do próprio repositório.

Na prática, isso pode se materializar em algo simples como:

  • um Makefile ou Justfile com comandos padronizados
  • containers já definidos para dependências como banco, fila e cache
  • scripts que sobem toda a infraestrutura local com um único comando

Exemplo típico:

make setup
make up
make test

Esse tipo de abordagem elimina a necessidade de conhecimento implícito e reduz drasticamente a variabilidade entre ambientes.

Para garantir reprodutibilidade, ferramentas como Nix (via flakes) ou Devbox permitem declarar todas as dependências do projeto de forma explícita.

Nesse modelo:

  • o ambiente passa a ser versionado junto com o código
  • não há dependência do estado da máquina do desenvolvedor
  • migração entre máquinas se torna trivial

Isso resolve diretamente o problema clássico de drift de ambiente.

Sandbox e isolamento como padrão

Isolamento não deve ser opcional. Ele deve ser parte do modelo de desenvolvimento.

Executar código diretamente no host expõe o ambiente a riscos desnecessários:

  • vulnerabilidades em dependências
  • execução de código malicioso
  • conflitos entre projetos
  • contaminação cruzada de ambiente

O uso de containers com Docker ou Podman resolve parte do problema, mas pode ser expandido.

Ferramentas como Distrobox permitem criar ambientes de desenvolvimento completamente isolados, com integração controlada com o sistema host. Mas é necessário realizar algumas configurações adicionais, pois os defaults do Distrobox são muito permissivos, já que ele foi criado com mais foco em integração facilitada com o host, do que com isolamento forte.
Outra opção é a distro QubesOs, que possui um forticimo mecanismo de sandbox usando para virtualização com Xen. Mas querer hardware parrudo e tem um certo nível de curva de aprendizado.

Isso possibilita:

  • múltiplos ambientes independentes por projeto
  • diferentes versões de linguagens coexistindo sem conflito
  • execução segura de ferramentas e código

Esse tipo de isolamento também é relevante do ponto de vista de segurança, especialmente em cenários de supply chain.

Execução local próxima do ambiente real

A capacidade de executar localmente uma versão representativa do sistema muda completamente a dinâmica de desenvolvimento.

Ambientes baseados em containers permitem simular:

  • serviços dependentes
  • topologias básicas
  • fluxos de comunicação

Mesmo que não seja possível reproduzir carga ou escala real, isso já elimina grande parte das dependências externas no ciclo de desenvolvimento.

Ambientes efêmeros e isolamento por desenvolvedor

A possibilidade de criar ambientes isolados sob demanda melhora tanto desenvolvimento quanto testes.

Cada desenvolvedor pode subir sua própria instância da aplicação e de suas dependências, evitando conflitos com outros desenvolvedores.

Esse modelo favorece:

  • validação paralela de features
  • eliminação de ambientes compartilhados como gargalo
  • maior previsibilidade nos testes

Para testes, o conceito de ambiente efêmero é ainda mais importante. Criar, usar e descartar ambientes permite trabalhar sempre com massa de dados limpa e previsível.

Segurança embutida na infraestrutura

Segurança eficaz depende de estar incorporada na base do sistema.

Alguns padrões importantes:

Imagens homologadas

Imagens de container devem ser:
  • auditadas
  • pré-configuradas com certificados
  • atualizadas automaticamente
  • mantidas pela organização

Isso reduz a necessidade de configuração manual e evita erros comuns.

TLS e certificados automatizados

A terminação TLS não deveria ser responsabilidade da aplicação.

Um padrão mais robusto é utilizar sidecars ou proxies que:

  • gerenciam certificados automaticamente
  • realizam rotação e refresh
  • centralizam políticas de segurança

Isso reduz complexidade no código e evita falhas de configuração.

Service discovery e comunicação

Da mesma forma, descoberta de serviços e comunicação entre componentes pode ser simplificada com sidecars.

Isso permite:

  • reduzir acoplamento entre serviços
  • padronizar comunicação
  • evitar configuração manual de endpoints

Autonomia com limites bem definidos

Autonomia sem limites gera inconsistência. Controle excessivo gera gargalos.

O ponto de equilíbrio está em automações que embutem padrões diretamente nas ferramentas.

Ao invés de depender de aprovação manual:

  • pipelines já validam contratos
  • templates já seguem padrões
  • infraestrutura já nasce com configuração correta

Isso elimina a necessidade de gatekeepers para tarefas operacionais.

Monorepo como facilitador de DevEx

Em sistemas com múltiplos serviços, o uso de monorepo pode trazer ganhos relevantes.

Principais benefícios:

Visibilidade

Todo o sistema está acessível no mesmo repositório. Isso facilita entendimento, debugging e evolução.

Ambientes isolados por desenvolvedor

Com todos os componentes disponíveis, é possível subir versões específicas do sistema localmente ou em ambientes isolados.

Compartilhamento de interfaces e bibliotecas

Interfaces e shared libs podem ser evoluídas de forma coordenada, sem necessidade de publicação e versionamento constante de artefatos.

Isso reduz:

  • atrito de integração
  • problemas de compatibilidade
  • overhead de gestão de dependências

Conclusão

Developer Experience eficaz depende de um conjunto de propriedades estruturais:

  • ambientes reprodutíveis
  • isolamento consistente
  • segurança embutida
  • automação com limites claros
  • redução de dependência de terceiros

Projetos auto contidos, com setup determinístico e execução isolada, reduzem significativamente a fricção no dia a dia do desenvolvedor.

Ao incorporar segurança e padrões diretamente na infraestrutura e nas ferramentas, é possível aumentar autonomia sem abrir mão de controle.

Esse tipo de abordagem reduz erros, acelera entregas e melhora a qualidade do sistema de forma consistente.

Por hoje é isto ...

Artus