La stessa installazione di dev env su più macchine, nota anche come "ma ha funzionato sulla mia macchina"

• Utilizza percorsi relativi
• Script l'installazione di strumenti (usa versioni specifiche)
• Utilizza un gestore di pacchetti (ad esempio, NuGet) per garantire che tutti utilizzino le stesse librerie
• Se si scende lungo la rotta Docker, far distribuire lo sviluppo locale ai contenitori locali. Questo assomiglierà più strettamente agli ambienti di produzione.
• Non fare affidamento sull'ordine in cui i record DB vengono restituiti a meno che non sia esplicitamente indicato .

Ma immagino che il consiglio generale più prezioso sia:

• Script la configurazione del tuo ambiente di sviluppo
• Tutto ciò che non può essere copiato dovrebbe essere chiaramente documentato

"Hai appena fatto il tuo primo passo in un universo più grande".

Non è tutto su Sviluppo e Sviluppo (anche se questa è la parte "divertente"). Ora inizi a pensare a ciò che viene next :

• Distribuzione - il processo [automatizzato] [standardizzato] [es] con cui si sposta il codice da una macchina all'altra.
• Testing - [Automated] testing ( off del tuo box di sviluppo) è la tua più grande "rete di sicurezza" per cogliere molti di questi problemi.
• Protezione dell'ambiente di produzione ( da voi ) - le applicazioni eseguite in Live sono che fanno i vostri soldi. Cambiarle [ripetutamente] è costare i tuoi soldi. Trova l'equilibrio.
• Manutenzione - purtroppo, una parolaccia a troppi sviluppatori, ma un programma ottiene scritto una sola volta; sarà modificato molte volte.

Più in particolare:

Multiple Config files ... ... this tool? And what version ... Which Visual Studio version do you use?

Standardizzare.

Certo, è limitante e, possibilmente, frustrante quando non puoi "solo" scaricare il widget più recente e più grande con cui lavorare, ma rende un ambiente di lavoro più coeso e riduce notevolmente il tipo di problema di "mancanza di dipendenza" descrivere.
Il rovescio della medaglia, però, fai attenzione a non cadere troppo indietro sulla "Ruota del criceto degli aggiornamenti". In questo modo si nascondono tecnologie obsolete in cui hai investito troppo e con nessuno in giro per prendersene cura.

"Why does this work on my local machine but not on the prod server?"

Perché non è stato distribuito su e testato su un server di staging che ha impostato same come Production e che nessuno è autorizzato a " smanettare.

"what Database sorting-order do you use? Maybe that's the reason."

Richiedi sempre i dati nell'ordine che desideri con ogni query. La maggior parte degli RDBMS in questi giorni non garantisce l'ordine delle righe in nessun altro modo.

Man mano che i tuoi requisiti di dati crescono, potresti dover addestrare / portare qualcuno a fare una "panoramica" dei tuoi dati e come la gestisci, concordando e stabilendo alcune regole di base.

So we need a setup where each machine is "the same"

No, non lo fai. Hai bisogno di un server di build e un ambiente di sviluppo / test.

Ottieni Team City e costruisci ogni check in per il ramo di sviluppo. Se la compilazione fallisce, ripristina il commit e correggi il problema.

Ottieni Octopus e fallo distribuire build di successo sul server di prova. eseguire i test sul server di prova. Se falliscono il lavoro non è fatto.

Metti il tuo database nel controllo del codice sorgente, versione, compilalo e distribuiscilo come il codice sorgente.

Una volta che hai messo in atto questi passaggi nell'interesse di ogni dev per assicurarti che qualunque cosa facciano con la loro macchina, il codice che producono funziona quando è distribuito su un server "reale".

A volte gli sviluppatori Dev hanno bisogno di cose diverse sulle loro macchine. È così che aggiungi nuove cose senza romperle per tutti gli altri. Cercare di far usare a tutti lo stesso set di strumenti è solo un problema.