Come deve essere archiviato il codice nel controllo versione?

19

Sviluppatore amichevole ? in modo che il programmatore possa rapidamente prendere l'ultimo e in grado di eseguire dal suo editor senza apportare molte modifiche? (come file di configurazione che puntano a dev DB..etc)

o

Dovrebbe essere favorevole alla produzione ? la fonte dovrebbe essere in un modo che sia facile da distribuire nell'ambiente di produzione e quando lo sviluppatore prende l'ultimo, dovrebbe apportare modifiche secondo le sue esigenze di sviluppo.

version-control

— Pavan GR
fonte

56

Perché scegliere Dovrebbe essere entrambi.

Il tuo ambiente di sviluppo dovrebbe essere configurato in modo che sia facile come fare un checkout, aprire, compilare, eseguire, eseguire il debug (ad esempio: nessun percorso assoluto!). Puoi farlo facilmente con le direttive di compilazione, la classe di configurazione + iniezione di dipendenza o persino trucchi come perso.config in ASP.NET

Lo script di build automatizzato deve essere sufficientemente personalizzato per occuparsi di configurazione di produzione specifica, pulizia, imballaggio ecc.

Che cos'è perso.config? Un veloce google non mi ha aiutato.

— Tim Murphy,

1

Nel file di configurazione dell'applicazione .NET, è possibile fare riferimento a un altro file di configurazione dell'applicazione che, una volta trovato, sovrascriverà le impostazioni specificate. Quindi è possibile creare un file dev.config che sovrascriva elementi come stringhe di connessione e altri elementi ed escluderlo dai repository.

5

+1: gli sviluppatori non dovrebbero pensare di ottenere la fonte corretta. Inoltre, l'implementazione della produzione non dovrebbe avvenire direttamente dal controllo del codice sorgente, ma con pezzi correttamente costruiti, testati e tracciabili . Questo processo dovrebbe essere completamente automatizzato.

9

Quando si tratta di un progetto open source in cui ci si aspetta che le persone contribuiscano, opterei sicuramente per gli sviluppatori.

La mia più grande antipatia per i progetti open source è che molto raramente il repository contiene tutte le dipendenze necessarie per costruire il codice (a volte per motivi pratici o legali), ma quando non lo fanno - alcuni non si preoccupano nemmeno di dirti quali dipendenze hai bisogno, o ancora più importante, di quale versione di essi hai bisogno. (e preferibilmente da dove trovarli)

A volte puoi passare più di mezza giornata a recuperare e compilare diversi altri progetti per costruire il progetto che stai cercando.

Naturalmente, questo è davvero rilevante solo per lo sviluppo su Windows.

— Mark H
fonte

1

Mi infastidisce. Lo trovi persino su OSS molto noto.

— Tim Murphy,

1

Ci sono sistemi che alleviano quel problema recuperando automaticamente le dipendenze. Ad esempio Apache Maven, Ivy o scons.

— sleske,

4

Entrambi, ma dipende dalla frequenza con cui realizzi la tua produzione. Per molte applicazioni personalizzate, le distribuzioni vengono eseguite manualmente e localmente. D'altro canto, lo sviluppatore impegna costantemente il codice, indipendentemente da quanto piccolo o grande sia il progetto. A mio avviso, penso che sia più importante assicurarsi che lo sviluppatore possa utilizzare correttamente il controllo della versione, quindi semplificare la sua vita in modo che abbiano il tempo di concentrarsi sul codice piuttosto che trovare la strada attraverso il controllo della versione.

— tia
fonte

Le distribuzioni di produzione dovrebbero essere un problema se si utilizza un motore di distribuzione continua per la compilazione.

1

Dovrebbe essere favorevole alla produzione, altrimenti è problematico mantenere build automatizzate.

— sharptooth
fonte

8

Perché? Uno script di build automatizzato può effettuare tutte le traduzioni necessarie per ristrutturare l'origine in un modulo distribuibile. Non disturbare mai le persone con qualcosa che l'automazione può risolvere.

— Joeri Sebrechts,

1

Sono tutto per ridurre l'attrito in modo che sia più facile portare a termine il lavoro, ma devi anche tenere conto delle modalità di guasto.

Se la versione del repository di origine è sempre configurata per l'uso in produzione, qual è il risultato della mancata riconfigurazione di uno sviluppatore prima di eseguire il sistema? Uno sviluppatore che esegue codice contro produzione.

Indipendentemente dal fatto che ci siano altri ostacoli nel modo in cui lo sviluppatore apporta modifiche casuali alla produzione, costruire in una modalità di fallimento che lo incoraggia a accadere sembra pericoloso.

Suggerisco che i valori predefiniti inclusi nel codice di commit siano sempre sicuri . Controlla anche i file di configurazione della produzione nel controllo del codice sorgente, se vuoi - lo faccio quasi sempre - ma tienili da qualche parte "non attivi".

— Bevan
fonte

0

Tendo a lottare per la produzione amichevole. Mantiene pulite le tue build e impedisce alle impostazioni estranee di renderle in produzione.

— Mike Clark
fonte

0

Sicuramente adatto agli sviluppatori, con script per automatizzare le modifiche per QA e produzione.

— William Payne
fonte

-1

Perché non avere un ramo (a seconda del controllo di versione che usi - io uso Git) per il codice distribuibile e altro per la versione pronta per lo sviluppatore? Sembra molto meglio e non è difficile da configurare.

È possibile lavorare e eseguire il commit delle modifiche e quindi unirle nella versione distribuibile.

— Ricardo Souza
fonte

Perché i rami di lunga durata sono costosi da gestire e tendono ad essere difficili da unire. Dovresti ricordarti di apportare tutte le modifiche su entrambi i rami. Molto meglio rendere entrambe le versioni uguali e / o avere uno script per generare l'artefcat distribuibile dal codice pronto per lo sviluppatore.

— bdsl,