Standard di denominazione ambientale nello sviluppo di software?

Il mio progetto è attualmente affetto da problemi di denominazione ambientale. Diverse persone hanno ipotesi diverse su quali ambienti dovrebbero essere nominati o su cosa designano i nomi, e sta causando confusione quando ne discutono. Ho fatto un po 'di ricerche e non ho trovato alcun standard là fuori.

I termini includono "Local", "Sand", "Dev", "Test", "User", "QA", "Staging" e "Prod" (oltre ad alcuni altri di cui diverse persone hanno chiesto)

Non cerco solo opinioni, anche se ce n'è una là fuori che "tutti" hanno, lo prenderò - sto cercando di trovare definizioni avanzate da una sorta di autorità, anche se non è ufficiale.

Ecco gli ambienti che attualmente utilizziamo:

1. Ambiente sul PC dello sviluppatore
2. Ambiente condiviso in cui gli sviluppatori caricano direttamente il codice per l'autotest
3. Ambiente condiviso in cui gli standard e le funzionalità sono testati dagli addetti al controllo qualità
4. Ambiente condiviso in cui il codice completato e verificato dal QA è approvato dai richiedenti il ​​progetto
5. Ambiente che rispecchia l'ambiente finale come controllo finale e preparazione per la distribuzione
6. Ambiente finale in cui il codice è in uso

So quello che avevo li chiamo, ma c'è una sorta di standard su questo? Grazie in anticipo.

Non solo non esiste uno standard fisso, ma in realtà non esiste un modello fisso. Le dipendenze tra ciò che stai costruendo e la scala alla quale puoi permetterti di replicarlo determineranno come deve essere questo da un tipo di progetto all'altro.

Ho lavorato con un solo ambiente e ben 13.

Nella sequenza che descrivi, di solito li vedrei nominati come qualcosa del genere

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

Il mio consiglio sarebbe quello di concordare i nomi, gli scopi e i criteri per entrare e uscire da ciascuno per ogni prodotto o progetto, quindi quando ti rendi conto che hai bisogno di un settimo ambiente o ne hai bisogno solo 5 in un caso per qualche altro motivo in futuro, discuti di nuovo con Il gruppo.

Se hai membri del team che si stanno bloccando sulla semantica dei nomi, puoi sempre rilasciare i nomi e riferirli come prod meno sei attraverso prod meno uno con un manager che si è semplicemente rifiutato di lasciare che il suo staff addetto al controllo qualità in un ambiente che non è stato chiamato "QA"

Se stai cercando di nominare i server stessi, di solito suggerisco di nominarli in base all'autorità sotto la quale si trovano. Di solito questo va qualcosa come:

• le macchine di sviluppo possono essere manipolate dagli sviluppatori
• Le macchine di controllo qualità non possono essere manipolate dagli sviluppatori, ma non sono monitorate dal supporto di produzione
• le macchine prod sono attività di supporto

molte persone finiscono per usare questi tipi di nomi come prefissi o suffissi in modo da avere una catena come "devsqllweb" "qasqlweb" "prodsqlweb" o qualcosa del genere.

Immagino che da un settore più strutturato e regolamentato l'opzione di nominare un server sia un lusso che non ho. I nostri server sono nominati in base alla nostra politica IT aziendale, quindi il nome host effettivo della macchina non è qualcosa che possiamo controllare.

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

• p = produzione
• d = sviluppo
• s = messa in scena
• 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

A seguire 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 bootstrap.

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.

Ciò ha portato ad alcuni interessanti, i miei due preferiti sono box e proxy cerberus (proxy interno) (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 daremmo i nomi che vorremmo usare.