Existem coisas que, de tão simples, são geniais. Essa ideia chegou até mim através do comentário de colega, um herói que não usa capa. Não é nada revolucionário, mas é algo que me deixou com a sensação de “por que eu nunca fiz isso antes?”.
⚠️ ATENÇÃO: Isso que vou compartilhar é um hackzinho, um “recurso técnico”, no português claro: uma gambiarra. E – como toda gambiarra – precisa ter cuidado na hora de usar.
Disclaimer feito, bora lá.
Em anos de desenvolvimento, eu sempre me condicionei a pensar “vou copiar o banco de staging para ter uma massa de dados”. Muitos desenvolvedores utilizam Seeds para esse propósito e fazem um ótimo trabalho com isso.
Sempre que surge um bug, meu mindset é: vamos descobrir como replicar isso em staging, para poder copiar o banco e investigar localmente.
Nenhum problema até que você tenha um banco enorme. Daqueles que você precisa ir fazer outra coisa enquanto está baixando e restaurando. É um tempo em que você pode dar uma olhada no backlog, ou talvez dar uma olhada nos PRs dos colegas, ou simplesmente ir tomar café… Mas convenhamos, seria mais produtivo já poder codar.
Bom, eis que eu estava copiando um banco monstruoso e comentei com o meu colega…
Eu: putz, tô baixando o banco, parece que vai demorar… 😩
Colega: porque você não conecta direto em staging?
Eu: como assim? 🤔
Colega: se o banco é enorme e você não vai editar nada, conecta direto em staging
Eu: como faço isso?
Colega:DATABASE_URL=`heroku config:get DATABASE_URL -a your-app` rails s
Simples assim, posso adicionar um byebug
onde eu quiser para investigar o problema 🥳!
Se você também usa o Heroku, tenho certeza que já tropeçou no comando heroku config
em algum momento para trabalhar com variáveis de ambiente. Eu mesmo já mencionei ele no primeiro artigo que escrevi no dev.to.
Eu já até cheguei a usar, para copiar uma ENV
que estava em staging para o meu .env.native
. Já até vi ele jogado em um makefile
em um script que já não lembro mais o que fazia…
Mas confesso que essa ideia nunca tinha me passado pela cabeça 🤦♂️
O mais interessante é que não precisamos nos limitar ao rails s
…
DATABASE_URL=`heroku config:get DATABASE_URL -a your-app` rails c
E nem sequer ao Rails:
psql -d `heroku config:get DATABASE_URL -a your-app`
Agora, se você, assim como eu, é bastante preguiçoso, pode criar aliases e funções no seu ~/.zshrc
:
alias stgdburl="heroku config:get DATABASE_URL -a your-app"
operate stgdb() {
export DATABASE_URL=`stgdburl`
"$@"
}
🧙 Magicamente os comandos passam a ser:
stgdb rails s
stgdb rails c
psql -d stgdburl
⚠️ ATENÇÃO: Antes de sair correndo e fuçando tudo isso, convém dar uma olhadinha no seu
config/database.yml
e dar uma lida na documentação do rails.
É importante saber como está a sua configuração para saber como a aplicação irá se comportar com a presença doDATABASE_URL
.
Como você já deve ter percebido, da para conectar em qualquer banco, inclusive prod.
Então, cuidado 😜