Executando verificação de segurança...
1
raryson
1 min de leitura ·

Removendo ambiente de desenvolvimento

Primeiramente. bom dia pessoal, tudo bem com vocês?
Segundamente. Vocês já tiveram a experiência de remover o ambiente de desenvolvimento e só ficarem com o ambiente de homologação e produção? Ou então já participaram de discussões sobre?
Alguém gostaria de opinar se acha positiva ou negativa essa ideia?

Eu particularmente acho uma boa pelos seguintes pontos:

  • Diminui o tempo do meu código ir para produção. Menos passos. Menos tempo.
  • Diminui o custo operacional da minha pipeline e de todos meus ambientes. Pois terei um ambiente a menos.

Pontos que vejo que podem ser um problema:

  • Aumentar bugs em ambiente produtivo caso o time não tenha uma cultura muito forte de testes unitários, funcionais e demos apresentáveis para o PO.
  • Aumentar a quantidade de vezes que serviços cross indisponibilizam outros times. (o que até que é um ponto bom, pois vai gerar a necessidade de pensar em soluções como testes de contratos e etc...)

Mas em resumo o que vejo é isso, se alguém quiser opinar e se ja passou por esse momento, fico feliz

Carregando publicação patrocinada...
1
1
raryson
Autor
Autor

Ainda tem o ambiente local, que é onde geralmente deveria estar sendo feito o código. E o ambiente de homologação que é onde o código é mergeado e testado. E por fim o ambiente produtivo, onde o código é usado na vida real.

Mas o ambiente de desenvolvimento que digo, é que geralmente empresas tem o seguinte fluxo de entrega de código:
Desenvolvimento local > Ambiente de desenvolvimento > Ambiente de homologação > Ambiente de produção.

Sendo desses:
Ambiente local: o seu ambiente de trabalho
Ambiente de desenvolvimento: lugar onde o dev pode mergear o seu código com approves de revisão de código e etc... Porém existe uma maior liberdade para esse ambiente ser quebrado.
Ambiente de homologação: cópia de produção ou maior tentativa de simular o ambiente produtivo.
Ambiente produtivo: produção, go live, rodando, ihaa.

1
Pilati

Entendi, numa empresa que trabalhei esse era chamado de testing. No qual os devs faziam merge e deixavam os QAs testarem.

Respondendo a pergunta inicial

Já trabalhei em uma empresa onde tinha o seguinte fluxo:

local -> testing -> homologation -> staging -> production

No meu trabalho atual tem o seguinte fluxo:

local -> production

O que vale é:

  • Qual a necessidade do seu projeto? a complexidade é tão alta a ponto de precisar criar um ambiente a mais / a menos?
  • Qual a maturidade da sua equipe para enviar códigos direto para o próximo ambiente?
    • Aqui se mede com a quantidade de vezes que um código "volta" para o passo anterior. Se voltar muito é porque:
      1- seus programadores dependem desse ambiente e estão confortáveis em jogar código ruim pra frente
      2- falta um processo de qualidade de código como code review
  • Esse ambiente está trazendo mais benefícios ou dor de cabeça?
1
user1

Desenvolvimento local > Ambiente de desenvolvimento > Ambiente de homologação > Ambiente de produção.

Cara, não sei se é alguma confusão de termos, mas para mim está estranho isso aí. Ao menos por onde eu já passei, é o seguinte:

  • Ambiente de desenvolvimento: É o onde o programador atua, é o ecossistema de IDE, editores, dependências de build e etc. Normalmente isso é na máquina do programador ou uma nuvem como o codespaces. Aqui na empresa estamos cada vez mais construindo os ambientes de desenvolvimento usando devcontainer pois é facilmente reproduzível.

  • Ambiente de homologação (ou stage): É um ambiente simular ao de produção, porém com as últimas alterações dos projetos para que os QA e clientes possam simular suas rotinas diárias e validar alterações.

  • Ambiente de produção: É o que nome diz.

1
raryson
Autor
Autor

Então, em todos locais que passei até hoje tem mais um nível de ambiente. Que é o que chamo de desenvolvimento. Que é um local que fica mais instável e que geralmente o dev tem acesso a infraestrutura para quebrar como quiser.

O que muda do ambiente de dev pra hml é que hml é mais fixo, com uma menor quantidade de chances de ter erro. Pois o que sobe para lá é algo já validado e testado em ambiente de desenvolvimento.

Mas ambiente local é onde tu coda, e não é o que eu to falando. Até por quê nem tem como remover a etapa de desenvolvimento local.