Come devono essere condivise le interfacce comuni tra i repository di controllo dei sorgenti?

2

Ho codice che rappresenta l'interfaccia per una libreria che viene utilizzata da una varietà di client interni . In che modo questo codice di interfaccia deve essere esposto a questi client interni che vivono in repository di controllo del codice sorgente diversi?

L'interfaccia dovrebbe essere relativamente stabile, ma è in fase di sviluppo (come la maggior parte dei client interni), quindi è importante mantenere le modifiche comunicate, così come limitare al minimo le modifiche. Normalmente, mi limiterei a fare riferimento direttamente agli altri moduli, ma la natura separata lo rende problematico.

    
posta Telastyn 31.07.2012 - 02:00
fonte

1 risposta

3

Ci sono molti modi e in realtà dipende dalla tua libreria / configurazione.

In genere puoi fare riferimento ad altri repository, ad es. con submodules per git o per esempio externals e svn. Questa è la soluzione più semplice e probabilmente anche più hacki in quanto si fa riferimento direttamente alla libreria e i client dovrebbero costruirli.

Puoi fornire pacchetti binari per la tua biblioteca, ad es. gems / eggs / debs / rpms / ... e basta fare riferimento al processo di creazione o presumere che sia presente al runtime. Questo secondo me è un approccio abbastanza pulito.

Lascia che il tuo buildsystem gestisca le dipendenze, ad es. fai affidamento su maven o usa altri strumenti come bundler / carton / openembedded o altri strumenti simili per la tua lingua. Possono scaricare e creare automaticamente le tue dipendenze.

    
risposta data 31.07.2012 - 05:09
fonte

Leggi altre domande sui tag