Standard di denominazione dell'ambiente nello sviluppo del software?

Non solo non esiste uno standard fisso, ma non esiste un modello fisso. Le dipendenze tra ciò che stai costruendo e la scala a cui puoi permetterti di replicare dettano ciò che deve avere questo aspetto da un tipo di progetto all'altro.

Ho lavorato con un solo ambiente e fino a 13.

Nella sequenza che descrivi normalmente li vedrei nominati come

1. local o dev se non usi dev nel passaggio successivo
2. dev o integrazione se questa è la prima distribuzione dopo l'unione
3. test o controllo qualità
4. uat o accettazione o QA se non hai utilizzato il QA nel passaggio 3
5. pre-prod, staging o performance se si tratta di un passaggio di prestazioni per l'approvazione finale
6. prod

Il mio consiglio sarebbe quello di concordare i nomi, gli scopi e i criteri per entrare e uscire per ogni prodotto o progetto, quando ti rendi conto che hai bisogno di un settimo ambiente o ne hai solo bisogno in un caso per qualche altra ragione in futuro discuti di nuovo con il team.

Se hai membri del team che si appendono alla semantica dei nomi, puoi sempre lasciar perdere i nomi e fare riferimento a loro come prode da meno sei a prod e uno con un manager che semplicemente si è rifiutato di lasciare che il suo staff del QA test in un ambiente che non è stato denominato "QA"

Se stai cercando di dare un nome ai server, di solito suggerisco di nominarli in base alla loro autorità. Di solito questo va qualcosa come:

• le macchine dev possono essere manipolate dagli sviluppatori
• Le macchine QA non possono essere manipolate dagli sviluppatori ma non sono monitorate dal supporto di produzione
• le macchine prod sono attività del supporto prod.

la maggior parte delle persone finisce per usare quei tipi di nomi come prefissi o suffissi in modo da avere una catena come "devsqllweb" "qasqlweb" "prodsqlweb" o qualcosa del genere.

Credo che provenire da un settore più strutturato e regolamentato l'opzione di nominare un server sia un lusso che non ho. I nostri server sono denominati in base al nostro criterio IT aziendale, quindi il nome host effettivo della macchina non è qualcosa che possiamo controllare.

Quello che abbiamo fatto è andato via il percorso dei nomi e degli alias DNS. La regola è la prima lettera identifica il ruolo generale del server nel processo di sviluppo (la zona)

• p = produzione
• d = sviluppo
• s = staging
• t = test

Quindi abbiamo un nome massimo di tre lettere per identificare il ruolo della macchina

• app = applicazione
• db = database
• web = frontend / web
• kas = memorizzazione nella cache

Seguito da un numero se ci sono più macchine in quella zona. Lo pubblichiamo sul server di documentazione interno e lo forniamo come parte di qualsiasi nuova documentazione per i progetti e durante la fase di avvio.

Questi sono per quei server che fanno parte del processo di sviluppo. Per le macchine di supporto abbiamo una politica più liberale; e quando dobbiamo fornire un nuovo server ausiliario chiediamo ai team di sviluppo di trovare un nome che preferiscono.

Questo ha portato ad alcuni interessanti, i miei due preferiti sono cerberus (proxy interno) box e hades (server di documentazione / intranet)

Sono sicuro che questa non è una buona pratica, ma questo è ciò che usiamo e funziona per noi.

Non esiste una definizione fissa. Ce ne sono alcuni usati dalla pratica comune (che hai elencato). Se vuoi dare ad ogni ambiente il nome di un personaggio in Toy Story, puoi (non lo consiglierò comunque).

Quello che vorrei fare è creare un glossario per l'azienda, in cui daremo i nomi che vorremmo usare.