Padrões de nomeação de ambiente no desenvolvimento de software?

Atualmente, meu projeto está sofrendo de problemas de nomeação de ambiente. Pessoas diferentes têm suposições diferentes sobre quais ambientes devem ser nomeados ou o que os nomes designam, e isso causa confusão ao discuti-los. Pesquisei um pouco e não encontrei nenhum padrão por aí.

Os termos incluem "Local", "Sand", "Dev", "Test", "User", "QA", "Staging" e "Prod" (além de mais algumas perguntas sobre as quais pessoas diferentes)

Não estou procurando apenas opiniões, mas se houver uma que todo mundo tenha, eu aceito - estou tentando encontrar definições avançadas por algum tipo de autoridade, mesmo que não seja oficial.

Aqui estão os ambientes que usamos atualmente:

1. Ambiente no PC do desenvolvedor
2. Ambiente compartilhado, onde os desenvolvedores fazem upload diretamente do código para autoteste
3. Ambiente compartilhado, onde os padrões e a funcionalidade são testados por pessoas de controle de qualidade
4. Ambiente compartilhado, onde o código concluído e o controle de qualidade são aprovados pelos solicitantes do projeto
5. Ambiente que espelha o ambiente final como uma verificação final e para se preparar para a implantação
6. Ambiente final em que o código está em uso

Eu sei como eu os chamaria, mas há algum tipo de padrão nisso? Desde já, obrigado.

Não existe apenas um padrão fixo, mas realmente não há um padrão fixo. As dependências entre o que você está construindo e a escala na qual você pode se dar ao luxo de replicá-lo vão determinar como deve ser a aparência de um tipo de projeto para outro.

Já trabalhei com apenas um ambiente e até 13.

Na sequência que você descreve, eu normalmente os via com o nome de algo como

1. local ou dev, se você não usar dev na próxima etapa
2. dev ou integração se esta for a primeira implementação após mesclagens
3. teste ou controle de qualidade
4. ou aceitação ou controle de qualidade se você não usou o controle de qualidade na etapa 3
5. pré-produção, preparação ou desempenho, se for uma etapa de desempenho para aprovação final
6. prod

Meu conselho seria concordar com os nomes, propósitos e critérios para entrar e sair de cada produto ou projeto, quando você perceber que precisa de um 7º ambiente ou apenas 5 em um caso por algum outro motivo no futuro, discuta novamente com O time.

Se você tem membros da equipe que estão se preocupando com a semântica dos nomes, sempre pode soltá-los e se referir a eles como prod menos seis a prod menos um com um gerente que simplesmente se recusou a deixar sua equipe de controle de qualidade testar em um ambiente que não foi nomeado "QA"

Se você deseja nomear os próprios servidores, geralmente sugiro nomeá-los pela autoridade sob quem eles estão. Geralmente isso é algo como:

• máquinas dev podem ser manipuladas por desenvolvedores
• Máquinas de controle de qualidade não podem ser manipuladas pelos desenvolvedores, mas também não são monitoradas pelo suporte à produção
• máquinas de prod são negócios de suporte de prod

a maioria das pessoas acaba usando esses tipos de nomes como prefixos ou sufixos, para que você tenha uma cadeia como "devsqllweb" "qasqlweb" "prodsqlweb" ou algo parecido.

Acho que, vindo de um setor mais estruturado e regulamentado, a opção de nomear um servidor é um luxo que não tenho. Nossos servidores são nomeados de acordo com a política de TI da empresa - portanto, o nome do host real da máquina não é algo que podemos controlar.

O que fizemos foi a rota de nomes e aliases de DNS. A regra é a primeira letra que identifica a função geral do servidor no processo de desenvolvimento (a zona)

• p = produção
• d = desenvolvimento
• s = estadiamento
• t = teste

Em seguida, temos um nome máximo de três letras para identificar o papel da máquina

• app = application
• db = banco de dados
• web = frontend / web
• kas = armazenamento em cache

Seguindo por um numeral se houver várias máquinas nessa zona. Nós o publicamos no servidor de documentação interno e o fornecemos como parte de qualquer nova documentação para projetos e durante o estágio de inicialização.

Estes são para os servidores que fazem parte do processo de desenvolvimento. Para máquinas de suporte, temos uma política mais liberal; e quando precisamos provisionar um novo servidor auxiliar, solicitamos às equipes de desenvolvimento o nome de sua preferência.

Isso levou a alguns interessantes, meus dois favoritos são cerberus (proxy interno) box e hades (servidor de documentação / intranet)

Tenho certeza de que essa não é uma prática recomendada, mas é isso que usamos e funciona para nós.

Não há definição fixa. Alguns são usados ​​pela prática comum (que você listou). Se você quiser dar a cada ambiente o nome de um personagem em Toy Story, você pode (mas não o recomendará).

O que eu faria é criar um glossário para a empresa, no qual damos os nomes que gostaríamos de usar.