CI/CD em Ambiente de Homologação e Produção

[joaomariagomes]

Boa tarde,

Tenho dois ambientes, Produção e Homologação com um banco de Dados de Homologação e outro para produção. Me deparei com seguinte problema...
Tenho uma equipe trabalho em um projeto, esse projeto tem uma String de Conexão com o Banco de Dados, o projeto fica armazenado em um repositório o qual os Devs buscam as atualizações do código, como é uma única String, quando um desenvolvedor atualiza o código apontado para o ambiente de homologação e outro desenvolvedor não prestar atenção e manda esse código para a breanch de produção e automaticamente e dado build temos um problema pois o ambiente de produção fica apontado para o banco de Homologação.

Gostaria da ajuda dos amigos para saber como posso solucionar essa situação?

[wilsongomes-swe]

String de conexão em código e versionado no repo está bem errado em minha opinião, a stringd e conxão deve entrar como uma variável de ambiente na máquina em que vai rodar, assim prod tem sua própria variável de ambiente que aponta para banco de prod e homolog/staging/tests tem sua própria variável de ambiente que aponta para o banco que ele usa, a string de conexão em dev, que não deve ser o banco de homolog, pode estar versionado em um .env para facilitar a vida, mas este .env nunca deve ir para prod ou homolog.

Espero ter ajudado,
abraços!

[fiuzagr]

@joaomariagomes , vc precisa trabalhar com variáveis de ambiente, como @wilsonneto-dev pontuou. Evite versionar essas strings de conexão, pois qualquer um que tiver acesso ao repositório tbm terá acesso total aos bancos de prod/hml.

O arquivo .env, que seria versionado junto com o código, ficaria com a string do banco local/dev (isso nunca mudaria):

STRING_BD=mysql://localhost...

Os servidores prod/hml, teriam essa variável definida no próprio server, num script de inicialização, garantindo que somente os servidores saberiam conectar no banco:

export STRING_DB=mysql://production...

Caso fosse necessário conectar da máquina local em um servidor (não deveria precisar, o melhor seria ter uma forma de copiar o banco para o banco local - dump), vc poderia invocar o comando de start passando a variável de ambiente:

STRING_DB=mysql://homolog.com npm start

Você também pode usar essa última forma nos servidores, para inicializar o server, com isso vc sempre força o valor correto para cada ambiente (nesse caso não precisa daquele export explicado ali em cima):

# em prod
STRING_DB=mysql://production.com npm start

# em homolog
STRING_DB=mysql://homolog.com npm start

Com isso, essa variável ficaria disponível no seu código Node.js em process.env.STRING_DB.

[maucrvlh]

Outro ponto que considero importante e ajuda a evitar o problema de sistema de prod/homol acessando recursos que não deveriam é criar políticas de acesso nos seus ambientes. Por exemplo, no kubernetes, você pode criar NetworkPolicies e definir quais serviços podem se comunicar, em diferentes níveis de contexto (Pod, Deployment, Namespace etc) Caso seus ambientes estejam rodando bare metal, pode fazer uso de configurações de firewall do próprio sistema operacional pra atingir esse objetivo. Fazendo isso, mesmo que por ventura algum sistema de prod tente acessar um serviço de homol, ou vice-versa, as restrições de acesso bloquearão essa tentativa de conexão. Em sáb., 10 de jul. de 2021 às 10:07, Guilherme ***@***.***> escreveu:

…

@joaomariagomes <https://github.com/joaomariagomes> , vc precisa trabalhar com variáveis de ambiente, como @wilsonneto-dev <https://github.com/wilsonneto-dev> pontuou. Evite versionar essas strings de conexão, pois qualquer um que tiver acesso ao repositório tbm terá acesso total aos bancos de prod/hml. O arquivo .env, que seria versionado junto com o código, ficaria com a string do banco local/dev (isso nunca mudaria): STRING_BD=mysql://localhost... Os servidores prod/hml, teriam essa variável definida no próprio server, num script de inicialização, garantindo que somente os servidores saberiam conectar no banco: export STRING_DB=mysql://production... Caso fosse necessário conectar da máquina local em um servidor (não deveria precisar, o melhor seria ter uma forma de copiar o banco para o banco local - dump), vc poderia invocar o comando de start passando a variável de ambiente: STRING_DB=mysql://homolog.com npm start Você também pode usar essa última forma nos servidores, para inicializar o server, com isso vc sempre força o valor correto para cada ambiente (nesse caso não precisa daquele export explicado ali em cima): # em prod STRING_DB=mysql://production.com npm start # em homolog STRING_DB=mysql://homolog.com npm start Com isso, essa variável ficaria disponível no seu código Node.js em process.env.STRING_DB. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2116 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4IS4JNA25ABPNG7TTBEJLTXBHZ3ANCNFSM5ABCNPYQ> .