Microservizi e librerie condivise

La tua seconda opzione è sicuramente la strada da percorrere. Scomponi le librerie comuni e installale sul tuo server PyPi locale.

L'opzione 1 è orrenda perché i miglioramenti alle librerie saranno difficili da propagare ad altri che potrebbero usarlo.

L'opzione 3 è simile all'opzione 1.

Lo schema comune è quello di impostare Jenkins in modo che quando si preme il master di un repository di libreria, esegua una compilazione python e la carica automaticamente sul repository PyPi. Una volta scritto questo script di build, non dovrai mai preoccuparti delle librerie di packaging e caricarle manualmente su PyPi. E con questa opzione, tutti gli aggiornamenti delle librerie saranno immediatamente disponibili per essere eventualmente aggiornati in altri microservizi.

Configurare il proprio server PyPi è molto semplice. Mi piace questa guida

Non è un tipo Python ma il server PyPi sembra l'opzione migliore. Un rapido googling dà l'impressione che sia analogo avere un repository Nexus per i java Java della squadra.

In realtà finchè viene implementato in una sorta di repository centrale (in ufficio / in team) con cui lo strumento di gestione delle dipendenze di scelta può lavorare (leggi e distribuisci), è una buona opzione.

L'opzione 1 è davvero la peggiore, non dovresti mai dover gestire manualmente le dipendenze. È un dolore. All'università, prima di conoscere Maven e quando pensavo che Git fosse troppo complicato, abbiamo fatto tutto manualmente, dall'unione del codice di tutti all'impostazione dei percorsi di classe, all'accettazione delle dipendenze. È stato un dolore, non vorrei seriamente che qualcuno passasse attraverso una minima parte di quel problema, specialmente in un ambiente di lavoro in cui l'efficienza è importante.

L'opzione 3 probabilmente funzionerebbe bene, ma non ha alcun vantaggio reale su un PyPi locale (oltre a essere forse più facile da configurare, ma i vantaggi di un vero sistema di gestione delle dipendenze sono molto migliori).

Prima di tutto dividere un monolite in microservizi sarà sempre difficile. Vedi Gestione dei dati decentralizzata - incapsulando i database in microservizi per un'idea del perché.

Detto questo, ci sono diverse ricette su come farlo relativamente bene. Uno di questi è link . Questo direbbe che dovresti mantenere ciascuna libreria e applicazione indipendentemente, quindi gestire le dipendenze in modo esplicito. Se segui questa strada, ti suggerisco strongMENTE di avere un semplice comando che aggiorni tutte le dipendenze a ciò che è attuale e lo esegui regolarmente per ogni micro-servizio. È importante avere un processo di rilascio sicuro in cui si bloccano le versioni delle librerie in produzione. Tuttavia, veramente , veramente non vuoi essere in una posizione in cui le dipendenze diventano obsolete e non sai cosa c'è là fuori.

Concentrati anche sul rendere le tue librerie di supporto il più precise e focalizzate possibile. Ci sarà sempre una spinta naturale per iniziare ad aggiungere materiale alle librerie principali per una facile condivisione. Fatelo e trascinerete rapidamente l'intero mazzo di spaghetti esistenti in librerie condivise e tornerete efficacemente al pasticcio che avete ora. È quindi meglio correggere i valori in eccesso.