Come convincere i collaboratori dei meriti degli ambienti di sviluppo locale

Usa un ambiente locale tu stesso. Immagino che tu abbia provato a evangelizzare, ora no. Quando qualcuno ti chiede perché lo fai, o quali sono le tue esperienze con il tuo arrangiamento, spiegali. Se si ottiene un convertito o due, probabilmente seguirà il riposo. Se nessuno vede i benefici, non ce ne sono (dubito), o davvero dovrebbe cercare un nuovo lavoro ..

Non preoccuparti di quello che fanno. Ti farà solo male alla testa. Tuttavia, se fossi in te, sarei alla ricerca di un lavoro, o almeno di una posizione diversa. Non sei compatibile con questa squadra e la tua frustrazione aumenterà solo.

OK, sono mezzo serio qui ...

Crea il tuo ambiente dev locale e blocca il server dev.

Probabilmente non dovresti farlo, ma sarebbe il modo più efficace per dimostrare i benefici di un ambiente di sviluppo locale. Mentre sono impegnati a chiacchierare con il server, non sono in grado di svolgere alcun lavoro di sviluppo, puoi sottolineare che puoi essere ancora produttivo.

Sembra che dovrebbe avere solo un impatto minimo sul tuo lavoro. Se è così, lo lascerei andare. Vi sono anche vantaggi in un ambiente di sviluppo condiviso, come una condivisione più rapida del codice, backup più facili del lavoro in corso, meno spese hardware, più facile standardizzazione dell'ambiente, meno tempi di installazione e manutenzione per singoli sviluppatori, ecc. Diverse persone hanno differenti preferenze su come gli piace lavorare, e non c'è niente di sbagliato in questo.

In genere il motivo per cui hai un sistema completamente separato è così che puoi modificare le librerie condivise.

Nel tuo ambiente di sviluppo comune, avrai quasi sicuramente qualcosa che è comune a tutti, un servizio di sistema o una versione di alcuni componenti (ad esempio un database) che non possono essere modificati. Quindi, quando vuoi apportare modifiche a quel componente condiviso, tutti gli altri sono influenzati fino a quando non hai finito, e anche allora - non puoi semplicemente ripristinare una versione precedente della base di codici senza ripristinare (cioè reinstallare il componente condiviso). / p>

Sulla tua casella di sviluppo, però, puoi fare ciò che ti piace senza interrompere il ragazzo facendo correzioni di bug sul vecchio codice, o il tipo che sta appena aggiornando una funzione che usa il sistema esistente.

Ad esempio, in un vecchio luogo avevamo alcuni sviluppatori PHP che codificavano su una macchina Linux condivisa che era "controllata" da un amministratore di sistema. Tutto andava bene se aggiornavano solo il codice dell'applicazione (che potevano fare nella loro home directory), ma c'erano alcuni servizi condivisi che non potevano essere aggiornati ... e quindi non lo erano mai, mai. Quando alla fine è arrivato il momento di aggiornare il sistema operativo, uno sviluppatore ha creato un nuovo box per lui e tutto è migrato in modo da poter apportare le modifiche necessarie - nota che questo è effettivamente un box per se stesso, una situazione che non sarebbe stata come disgregativo com'era se fosse stato in esecuzione localmente comunque.