.env e .env.production 🖥️

Primeira vez que subi o projeto da empresa sozinha, quebrei o site.

Isso aconteceu comigo há duas semanas atrás, não fazia ideia do que era.

Perguntei ao sênior com o leve desepespero de um júnior achando que já tinha estragado tudo, e ele prontamente me respondeu: não tem o env.production.

Na minha cabeça só precisava do .env, nem sabia da existência do outro, então resolvi estudar um pouco sobre o assunto. Segue a importância, definição e porque você deveria, júnior, ter um antes de subir em produção para não passar o mesmo sufoco que eu passei.

ps: é de extrema importância que coloquemos esse arquivo no .gitgnore (se o projeto estiver no github, por exemplo) para não vazar as nossas credenciais do projeto. Se você acabou de começar na programação talvez ainda não precisou mexer com dados sensíveis, como senhas, chaves de acessos… Mas à medida que vamos progredindo precisamos manipular e guardar essas informações. E é aí que entra o .env, nele guardamos essas varíaveis de ambientes.

Instalação

Se estiver usando o node.js, podemos usar a biblioteca dotenv npm: npm install dotenv

yarn yarn add dotenv

O que é o .env.production?

Enquanto o .env é para configuraões padrões ou desenvolvimento o .env.production armazena valores que são aplicados quando a aplicação é executada em produção. Quando vamos subir um arquivo no filezilla, por exemplo, é importante que tenhamos o .env.production. Se você for iniciante, como eu, e ainda não sabe qual variável é para o desenvolvimento e qual é para produção, recomendo, copiar e colar o conteúdo do .env e colocar no .env.production! (mas claro, não se acomode, vá atrás de conhecimento para que aos poucos você consiga discernir e saber onde coloca cada um).

Bons estudos. Até o próximo bug.

1 Coríntios 10:31

sargento001 há 13 dias

Ótimo relato e muito importante para quem está começando! Esse tipo de situação é comum para quem está dando os primeiros passos com variáveis de ambiente, e entender a diferença entre .env e .env.production faz toda a diferença para evitar dores de cabeça.

Aqui vai um resumo do que você aprendeu e algumas dicas:

Diferença entre .env e .env.production: O arquivo .env geralmente é usado para desenvolvimento local, enquanto .env.production armazena as variáveis de ambiente específicas para produção. Essa separação ajuda a manter o ambiente de desenvolvimento isolado do ambiente de produção, onde as configurações e credenciais podem ser bem diferentes.

Evitar vazamento de dados sensíveis: Como você mencionou, é essencial incluir esses arquivos no .gitignore para evitar que senhas e chaves de API sejam expostas no GitHub ou em outro repositório. Isso previne o vazamento de dados sensíveis e aumenta a segurança do projeto.

Importância de variáveis de ambiente em produção: Em produção, essas variáveis configuram o acesso a bancos de dados, serviços externos e APIs, essenciais para o funcionamento do site. Sem um arquivo .env.production corretamente configurado, o site pode quebrar, como você vivenciou.

Parabéns por buscar entender o que aconteceu e compartilhar esse aprendizado!

nycolexavier há 13 dias

Obrigada por esclarecer mais sobre a importância dos dois! Sigo cheia de bugs aqui, o trabalho tem estado bem corrido, mas estou anotando tudo para compartilhar! 🦾

gpoleszuk há 19 dias

nycolexavier, sempre que vejo postagens escreverem "inclua o nome do arquivo x no .gitignore" fico pensando a responsabilidade que o git tem para não falhar nessa filtragem. Um bug e já era suas chaves. Será que não tem uma forma dessas credenciais nunca ficarem disponíveis no armazenamento, mas em variáveis do ambiente? Depois que sobe para o repositório, acho que fica no histórico de alterações. Qualquer edição posterior será apresentada no diff entre as versões.

valkhantech há 19 dias

e é por isso que gitignore seguro deve ser criado na inicialização do repositório, pq uma vez enviado... é isso mesmo, vai ficar no histórico. o github e outras ferramentas tem cofres de senha que em pipelinez de ci/cd substituiem a necessidade do .env. outros sistemas de automação tem suas particularidades.

crystian há 18 dias

Você pode usar direnv com um script .envrc usando source_env_if_exists /home/user/.envrc.local que somente busque as credencias em outro diretório, podendo centralizar as variáveis de ambiente e não deixá-las no projeto, ou usar o https://www.passwordstore.org/ com algum script para carregar as variáveis de ambiente quando tiver na raiz do projeto.

nycolexavier há 19 dias

nunca tive parado para pensar isso!! mas você tem toda razão, nunca tinha parado para pensar nisso, inconscientemente, acho que isso é algo de praxe na minha mente e que sempre vai dar certo. Preciso pesquisar mais sobre o assunto.

valkhantech há 19 dias

excelente relato, o que me surpreende é vc como junior fazer deploy em produção, na minha empresa somente tech lead e senior é que fazem deploy, um junior nunca deveria fazer deploy desassistido.

nycolexavier há 19 dias

nem me fala, na outra empresa também fazia isso sozinha, sendo estagiária, uma vez eu quebrei o servidor da empresa, por que o mouse travou e arrastou sozinho um arquivo pra dentro de outro, foi o suficiente para quebrar tudo, pensei que tinha concertado, fui dormir, estava trabalhando á noite. De manhã, mandei mensagem pro meu chefe explicando a situação. No outro dia, só 10 horas da manhã, no horário da daily, descobriram que está tudo fora do ar. Minha alma foi e voltou, meu chefe, arrumou em 5 segundos. Depois daquilo comecei a só mexer com as setas do teclado quando estivesse no fileZilla. Mas recentemente mudei de emprego, e colocaram um projeto todo na minha mão e mandaram eu subir o projeto toda vez que tem atualização, estou passando sufoco atrás de sufoco. Mas um dia eu aprendo!

valkhantech há 19 dias

um amigo meu fez isso recentemente, usando o touchpad do macos fez exatamente isso de arrastar, só descobri pq fui investigar ele fazendo a atualização e percebi a pasta fica do transparente. rimos muito kkk conselho, sempre faça backup e testes de atualização na maquina local se possível e depois só replicar, se der problema é não perder a calma, no pior cenario coloca uma mensagem de sistema em manutenção que é melhor do que a pessoa cair num erro genérico, quando vc coloca uma mensagem as pessoas tendem a ficar menos tensas pq sabe que tem gente olhando pra isso e parece ser algo programado.

nycolexavier há 19 dias

que bom saber que não estou sozinha nessa 😅 quanto ao backup não sei se tem essa possibilidade, mas posso ver com o pessoal aqui! e sobre a tela de manutenção, acho ótimo!! vou pensar em colocar o quanto antes, obrigada!

devjonatas há 19 dias

Legal, isso acontece, mas só fique desesperada se der update sem where no banco de produção rsrsrs. Legal em prod é uma um cofre de secrets como o Hashicorp Vault ali você coloca as variaveis de ambientes de cada servidor (se você tem mais de um ambiente) e só quem tem a senha consegue ver. Acredito que ainda não entra dentro do seu contexto mas, vale a pesquisa é bem legal.