Integrare correttamente un IDL in più repository git

6

IDL come Protobuf , flatbuffers , Cap'n Proto o Risparmio consentire la comunicazione su interfacce standardizzate tra progetti altrimenti indipendenti.

Molto spesso, questi progetti saranno sviluppati in repository separati e mentre richiedono tutti i file generati dalle definizioni dell'interfaccia, nessuno di questi è la fonte chiara per tali interfacce.

Allora, dove dovrebbero risiedere le definizioni dell'interfaccia? In che modo questo influenza la costruzione / il controllo delle versioni?

La mia idea era che i file IDL si trovavano in un repository separato, ma che cosa allora? Lo faccio un sottomodulo di ogni repo che ha bisogno di loro? Posso clonarli insieme agli altri e quindi includerli quando necessario? Dove inserisco i file generati, nel caso in cui vengano commessi con ciascuno dei repository client?

    
posta iFreilicht 26.11.2017 - 17:27
fonte

1 risposta

5

Le definizioni dell'interfaccia dipendono da tutti i progetti che usano quell'interfaccia. Come gestisci questa dipendenza dipende dalla natura del progetto.

es. se le definizioni di interfaccia sono condivise tra progetti liberamente correlati, le definizioni di interfaccia dovrebbero avere versioni con versione chiaramente definita. Il codice generato può essere specificato come dipendenza tramite il gestore pacchetti della tua lingua. In particolare, questo pacchetto potrebbe essere una libreria di alto livello per l'utilizzo della tua interfaccia piuttosto che solo binding di basso livello. Dove possibile, questa è la soluzione ideale.

Se l'IDL non ha release chiare, se tutti i progetti sono evoluti insieme (dallo stesso team), o se è necessario rigenerare i binding per ogni progetto dipendente in ogni caso (ad esempio perché usano lingue diverse), quindi includendo il IDL tramite git submodule è una soluzione decente, indipendente dalla lingua. Sarà necessario integrarlo manualmente nel processo di compilazione e impedire esternamente eventuali conflitti di versione. Un Submodule attacca uno specifico commit del repository incluso. Se si desidera aggiornare la descrizione dell'interfaccia, è necessario estrarre manualmente e impegnare la nuova versione per il sottomodulo in ciascun progetto dipendente. Tieni presente che alcuni strumenti di creazione potrebbero richiedere una configurazione aggiuntiva per i sottomoduli, specialmente se l'origine del sottomodulo non è disponibile pubblicamente.

La clonazione separata della descrizione dell'interfaccia potrebbe funzionare, ma significa che i progetti non sono più legati a una specifica versione dell'interfaccia che rende più difficile il debugging: le dipendenze dovrebbero essere esplicite. D'altra parte, l'aggiornamento della descrizione dell'interfaccia è più semplice: estrarre il repository clonato, quindi ricostruire tutte le dipendenze.

Non dovresti impegnare i file generati. Ciò rende inutilmente difficile rigenerare i binding se si modificano le definizioni dell'interfaccia:

  • Il diff conterrà sia le modifiche effettive che le modifiche nei file generati.
  • I file generati potrebbero essere modificati manualmente.
  • L'IDL potrebbe essere modificato senza rigenerare i binding.

Se crei un pacchetto che viene utilizzato come dipendenza dai tuoi progetti, è possibile archiviare artefact, ma è diverso dal commit dei file generati al controllo del codice sorgente.

    
risposta data 26.11.2017 - 20:18
fonte

Leggi altre domande sui tag