Per dipendere dal codice sorgente o dal binario?

Raccomando sempre le dipendenze binarie sulle dipendenze di origine. La maggior parte dei professionisti che elenchi per codice sorgente possono essere facilmente incorporati anche nelle dipendenze binarie.

In primo luogo, è molto veloce configurare un repository Nexus su un server locale. I vantaggi di avere un repo binario superano di gran lunga lo sforzo / costo di impostazione. Questo è quasi un prerequisito per il resto della mia risposta:)

Per le versioni pre-release, i tuoi progetti dovrebbero essere implementati -SNAPSHOT versioni nell'artificio. Può esserci una bella e chiara distinzione tra le versioni, ad esempio:

• projectA-3.2.0-SNAPSHOT : sviluppo attivo, può cambiare in qualsiasi momento
• projectA-3.2.0-RC1 : versione candidata
• projectA-3.2.0 : versione di produzione

Tutte queste versioni possono essere memorizzate insieme nel tuo artifactory. I tuoi progetti saprebbero esattamente a cosa si stanno compilando.

Per le patch, git è tuo amico. Inserisci il repository e inserisci un numero di versione patch, ad esempio projectA-3.2.1-FOR_PROJ_B . Notare il .1 che mostra una versione patch e anche il descrittore. Ciò renderà anche più semplice per il progetto riportare queste modifiche al master in un secondo momento.

Per il codice sorgente, puoi configurare il tuo strumento di generazione per generare un "vaso sorgente" e distribuirlo accanto al vaso binario nell'artificiale. La maggior parte degli IDE può cercare il nome del vaso di origine e scaricare automaticamente l'origine per te.

Un altro grande motivo per stare lontani dal codice sorgente è che sei legato al sistema di generazione, alle catene di strumenti e alle dipendenze in fase di compilazione del Progetto A. Se vedi un errore di compilazione nel Progetto B, devi prima indagare se Il progetto A o il progetto B hanno causato un errore. Se fosse il Progetto A, devi rintracciare le persone da quel progetto per sistemare la loro build. Ciò aggiunge un sovraccarico al tuo ciclo di build.

Vorrei fare affidamento sulla dipendenza binaria, perché quasi nessuna delle tue considerazioni a mio favore è senza critiche:

• se non si dispone di un gestore di archivi binari: va bene, ma non penso che sia difficile renderlo stabile. Nel livello più elementare, una cartella condivisa in cui possono scrivere solo le persone incaricate di decidere quale versione può essere utilizzata.

• se è necessario dipendere dalla versione di pre-release di un altro progetto: metacubed lo ha già coperto. O con il codice sorgente o le dipendenze binarie, dovresti mantenere una versione ben stabilita, anche se è pre-release. Ovviamente, quando si sviluppa in una versione preliminare, è probabile che sia necessario passare a una versione aggiornata spesso a causa della risoluzione dei bug.

• se hai bisogno di patchare un altro progetto: intendi che il tuo team aggiusterà il progetto fatto da un'altra squadra nella stessa casa? Direi che la strategia più sana è dire all'altro team i problemi che hai con il loro progetto.

• perché è più facile sfogliare il codice sorgente delle dipendenze in IDE: non dovresti aver bisogno di curiosare nel funzionamento interno delle tue dipendenze, perché significherà:

  • il progetto A è scarsamente documentato
  • i tuoi codificatori finiranno utilizzando "funzionalità non documentate" del progetto A che potrebbero scomparire senza preavviso a qualsiasi aggiornamento.