Dev Server vs Local Development

I vantaggi della gestione locale sono che puoi lavorare senza influenzare / ostacolare gli altri. I vantaggi di un server di sviluppo centrale è che puoi verificare come le tue modifiche influenzano e interagiscono con le modifiche che altri stanno facendo mentre vengono eseguite.
Idealmente vuoi avere entrambi. Sviluppa ed esegui i tuoi test unitari a livello locale in modo da poter isolare le modifiche finché non ti senti a loro agio, quindi integrarle nel server del team in modo da poter controllare l'integrazione delle modifiche prima che le cose vadano sui sistemi di test.

Un altro vantaggio di un server locale sul laptop è che puoi lavorare in remoto dove non hai accesso alla rete aziendale e quindi non puoi accedere al server di sviluppo.

In realtà ci sono 3 opzioni:

Sviluppo locale

• vantaggi:
  • facile da utilizzare con la maggior parte degli strumenti di sviluppo
  • nessuna necessità di connessione Internet
  • non interessa altri sviluppatori
• svantaggi:
  • dipende dal sistema operativo sottostante
  • potrebbe essere necessario eseguire tutti i tipi di servizi server sulla macchina locale
  L'ambiente
  • potrebbe essere abbastanza diverso dalla produzione

Macchina virtuale locale

• vantaggi:
  • abbastanza facile da utilizzare con la maggior parte degli strumenti di sviluppo, a patto di aver impostato correttamente la condivisione delle cartelle
  • nessuna necessità di connessione Internet
  • non interessa altri sviluppatori
  L'ambiente
  • potrebbe essere praticamente identico alla produzione
  • servizi server avviati / arrestati all'interno della macchina virtuale
>
• bit più risorse richieste (principalmente quantità di RAM, la CPU non è un problema con il moderno supporto per la virtualizzazione dell'hardware).
• alcuni strumenti di debug locali che collegano direttamente al server non funzioneranno

Server di sviluppo condiviso

• vantaggi:
  L'ambiente
  • potrebbe essere praticamente identico alla produzione
  • servizi server sul server
• svantaggi:
  • accesso remoto
  • modifiche che interessano altri sviluppatori
  • molto più difficile il debug (usando strumenti o log remoti)

Soluzione ottimale

Utilizza una delle opzioni di sviluppo locale e passa al server di sviluppo condiviso una volta completata la parte autonoma della funzionalità e hai verificato che il tuo codice non è completamente infranto.

Il tuo ambiente di sviluppo dipende davvero da come il tuo dipartimento IT / azienda è organizzato ed eseguito. In generale, sebbene il tuo ambiente di sviluppo sia chiuso, meglio è quello del tuo ambiente di produzione.

Se ad esempio stai sviluppando applicazioni desktop indipendenti che non richiedono l'accesso a Internet, ovviamente un ambiente di sviluppo locale è accettabile.

D'altro canto, se si sta sviluppando un'applicazione desktop che richiede la comunicazione con un server / database remoto ecc. e non si dispone di una connessione di rete per simulare questo lavoro, si potrebbero riscontrare bug aggiuntivi nella produzione a causa della latenza della rete, problemi di sicurezza .

Se stai sviluppando un'applicazione Internet / Cloud, mentre potresti aver bisogno di Internet per sviluppare l'applicazione, avrai bisogno di accedere per testare e verificare.

Btw non hai bisogno di una connessione Internet per avere un server di sviluppo solo una connessione di rete locale.

Fai entrambi,

Sviluppo locale fino a quando tutto ciò che stai lavorando è fatto e testato.

Spingi sul server condiviso alla fine della giornata ed esegui test di integrazione per assicurarti di non rompere nulla.

Perché?

• È più veloce da codificare localmente. Meno passaggi tra i test, meno preoccupazioni per l'integrazione.

• L'isolamento dei guasti è più semplice quando qualcosa si interrompe solo dopo averlo inviato al server condiviso. Sai che funziona bene a livello locale, quindi deve essere qualcosa a che fare con il modo in cui si integra con il server condiviso. Se lavorassi direttamente sul server condiviso, sarebbe particolarmente difficile restringere i bug.

Lo farei in questo modo:

Dopo che ciascuna persona ci ha trasferito le modifiche alla fine della giornata, vengono eseguiti tutti i test di integrazione e, in caso di esito negativo, si sa esattamente chi è il codice che ha interrotto il progetto. Ripristina le modifiche, risolvi il problema localmente, quindi prova a spingerlo di nuovo, ripeti fino a quando non passano tutti i test, quindi sulla persona successiva.

Molto dipende da come consegnate i vostri progetti. Alcuni argomenti per avere un ambiente di sviluppo centrale potrebbero essere:

Controllo di qualità: fino a che punto vuoi andare a testare? Gli ambienti di sviluppo locale hanno vincoli sulle funzionalità di test. Gli ambienti di test virtuali sono più adatti per test di carico e test di sistemi automatizzati.

L'infrastruttura centrale può aiutare ad accorciare il ciclo di consegna dei test di sviluppo. Quindi implementando una consegna continua.

Ulteriori vantaggi dal server di sviluppo centrale possono essere il controllo del codice sorgente, la gestione delle attività, le versioni centrali, ...