Devops

Projeto autoral de DBRE com PostgreSQL: ambiente reproduzível, recuperação, alta disponibilidade, métricas, logs e alertas validados.

Projeto autoral para estudar Protheus em Docker com configuração versionada, automação operacional e práticas iniciais de DevOps.

Depois de organizar o ambiente, automatizar sua preparação e exercitar o backup e a restauração do PostgreSQL, faltava responder a uma pergunta: o que pode ser validado continuamente sem distribuir os artefatos do Protheus nem iniciar o ERP? A quinta parte do Protheus Docker Lab encerra esta série com um workflow de integração contínua para a configuração versionada e os scripts do projeto. Ela também registra os limites dessa automação, porque um pipeline aprovado não significa, sozinho, que o ambiente Protheus está funcional. ...

Depois de automatizar a configuração local , precisamos saber o que acontece com os dados quando o ambiente para, volta ou tem seus contêineres recriados. A Parte 4 do Protheus Docker Lab já está publicada. Ela reúne o inventário de persistência, o backup do PostgreSQL, um ensaio de restauração em banco separado e a rotina de manutenção. Este artigo acompanha a versão 4310980 do repositório . As evidências citadas são as documentadas na execução de 12/09/2026. ...

Versão de referência: este artigo foi revisado com base no commit 3dfe986 , que registra a automação e a validação local da terceira parte do Protheus Docker Lab. Um ambiente reproduzível não deveria depender de uma lista de comandos lembrada apenas por quem o criou. Depois de organizar os serviços e arquivos do Protheus Docker Lab , a etapa seguinte foi transformar o procedimento documentado em um fluxo operacional pequeno, previsível e seguro para os arquivos locais. ...

Versão de referência: este artigo foi revisado com base no commit 77562cd , que registra o estado validado da segunda parte do Protheus Docker Lab. No primeiro artigo da série, Construindo um laboratório Protheus com Docker , montei um ambiente de desenvolvimento composto por PostgreSQL, DBAccess, License Server e AppServer. Colocar os serviços em execução foi a primeira etapa. A seguinte foi transformar um arquivo Compose funcional em um projeto que eu pudesse entender, validar, recriar e evoluir. ...

Ao iniciar um projeto com determinadas tecnologias, é comum encontrarmos uma ferramenta capaz de criar automaticamente uma estrutura básica de aplicação. No ecossistema Node.js, por exemplo, o NestJS permite iniciar um novo projeto com um único comando: npx @nestjs/cli@latest new minha-api Esse comando cria a estrutura inicial, instala as dependências e entrega uma aplicação pronta para execução. Durante um curso de Docker e Docker Compose, percebi que os exemplos práticos utilizavam justamente essa abordagem. A aplicação em si não era o foco principal da aula. Ela servia apenas como base para estudar imagens, containers, volumes, redes e orquestração com Docker Compose. ...

No Lab 01, construímos a fundação: uma instância PostgreSQL reproduzível, persistente e validada com Docker. Mas subir um banco saudável é apenas o primeiro passo. Para testar backup, replicação, observabilidade ou performance, precisamos de uma base que se aproxime de um cenário real: usuários com responsabilidades diferentes, schemas bem definidos, extensões operacionais, relacionamentos, índices e dados suficientes para exercitar o ambiente. Esse é o objetivo do Lab 02 do PostgreSQL Reliability Lab. ...

Durante muitos anos, desenvolver para o ERP Protheus significava preparar manualmente todo o ambiente de desenvolvimento. Instalar banco de dados, configurar DBAccess, ajustar License Server, preparar AppServer, copiar arquivos de configuração e validar dependências costumava fazer parte do processo. Cada máquina acabava se tornando um ambiente único, com pequenas diferenças difíceis de rastrear. Embora esse modelo ainda seja comum em muitos projetos, ele fica distante de práticas que hoje considero essenciais em Engenharia de Software: ambientes descritos como código, configuração versionada, automação operacional e capacidade de recriar o laboratório de forma previsível. ...

Recentemente, participei de um desafio do curso de DevOps da Rocketseat. O objetivo era analisar o cenário de uma empresa fictícia e propor melhorias com base no modelo CALMS e nas Três Maneiras do DevOps. À primeira vista, o exercício parecia ser sobre automação, CI/CD e deploys. Porém, ao analisar o caso, ficou claro que os principais problemas não estavam relacionados à falta de ferramentas, mas à forma como as equipes trabalhavam. ...