Atividade Desplugada

O que acontece quando a internet cai no meio de um deploy

Você já ficou preso num problema porque o servidor de build não conseguia puxar uma dependência e o link de internet tava instável. Isso é realidade em muitos ambientes corporativos, especialmente quando se trabalha com CI/CD em máquinas que ficam em redes internas ou datacenters com conectividade questionável. A prática de realizar atividade desplugada — ou seja, trabalhar offline, sem depender de conexão constante com a nuvem — tornou-se quase obrigatória em times que precisam de previsibilidade. Em termos técnicos, atividade desplugada envolve manter cópias locais de todas as ferramentas, repositórios, containers e pacotes que seu pipeline precisa. O conceito é simples, mas a execução costuma ser dolorosa porque exige disciplina e planejamento prévio. Eu tenho uma memória específica sobre isso: há alguns anos, estávamos num projeto onde o container registry privado caiu por 6 horas seguidas durante uma janela de release crítica. Nosso pipeline parou completamente porque cada stage tentava fazer pull de uma imagem que simplesmente não existia localmente. A solução que funcionou foi ter um mirror local dos containers mais usados, configurado via Harbor ou Docker Registry com caching. Isso reduziu o tempo de recover de horas para minutos.

Como configurar atividade desplugada no seu fluxo de trabalho

O primeiro passo é identificar todas as dependências externas do seu projeto. Não apenas as bibliotecas do código — pense também em containers de build, imagens base, ferramentas de lint, scanners de segurança e até certificados TLS que podem ser baixados automaticamente. Liste tudo. Anote versões exatas. Versione essa lista junto com o código. Depois, configure mirrors locais. Para packages npm, use um registry como Verdaccio ou Nexus Repository. Para Python, um mirror PyPI como Pulp ou Bandersnatch funciona bem. Containers ficam em um registry local tipo Harbor, Docker Registry ou GitLab Container Registry com pull-through cache. O tempo médio de configuração inicial gira em torno de 2 a 4 horas por stack, dependendo da complexidade. Depois disso, o ganho é contínuo. Outro ponto crucial é o sistema de versionamento das imagens base. Muitos times copiam imagens diretamente do Docker Hub sem congelar tag. Isso funciona até o dia em que alguém atualiza uma imagem base com breaking changes. Eu resolvi isso usando Kaniko ou Buildah com imagens fixadas por digest SHA256, não por tag. Assim, mesmo que a tag mude, o build continua produzindo o mesmo resultado. Isso economiza horas de debugging em pipelines que antes quebravam aleatoriamente.

Limitações que ninguém comenta

Atividade desplugada não é bala de prata. Existem cenários onde ela simplesmente não funciona bem. Se seu projeto depende de APIs externas em tempo real — como verificação de fraudes, processamento de pagamento ou serviços de ML rodando na nuvem — você não consegue desligar disso. Nesses casos, o melhor é isolar a parte que precisa de conexão e manter o resto offline. Separe clear boundary entre o que roda localmente e o que precisa de rede. Outro problema real é a drift de versão. Com o tempo, seu mirror local acumula pacotes desatualizados e vulneráveis. Eu recomendo um script de manutenção semanal que varre as dependências e sinaliza atualizações críticas. Gasta cerca de 15 minutos por semana e evita surpresas desagradáveis. Sem esse cuidado, sua atividade desplugada vira uma caveira de bibliotecas abandonadas que ninguém quer revisar. Há ainda o aspecto cultural. Times acostumados a instalar pacotes sob demanda precisam se adaptar a uma cultura de "tudo deve estar disponível localmente antes de começar". Isso significa documentar bem, criar runbooks e treinar novos integrantes desde o primeiro dia. Do contrário, alguém vai tentar fazer pip install direto e vai reclamar que o ambiente não funciona.

No final, activity offline reduz drasticamente a variabilidade dos seus builds. Em vez de depender da sorte da conectividade, você controla exatamente o que está sendo empacotado. O investimento inicial é real — talvez um dia inteiro para preparar o ambiente da primeira vez — mas o retorno aparece nas próximas semanas, quando seu pipeline para de quebrar por motivos que nada têm a ver com o código que você escreveu.