Executando verificação de segurança...
6

.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

Carregando publicação patrocinada...
1

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.

1

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!

1

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.

1

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!

1

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.

1

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.

2

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.

1

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.

1

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.