Integrazione di generatori di codice nella pipeline CI / CD

1

Nella mia azienda, attualmente sto lavorando a un progetto con alcuni servizi web (REST) coinvolti. Lo sviluppo si basa sulla specifica OpenAPI e sugli strumenti Swagger . La piattaforma di destinazione è una piattaforma cloud interna basata su OpenShift.

Poiché utilizziamo una pipeline CI / CD nel nostro processo di sviluppo del software (più o meno l'intera Atlassian Toolchain, Artifactory, ecc.) sorge la domanda se sia possibile integrare perfettamente una fase di generazione del codice nella pipeline.

Il processo di sviluppo dell'API in questo momento è fondamentalmente simile a questo:

  • Scrivi / modifica le specifiche API
  • Conferma modifiche in SCM
  • Convalida le specifiche e genera documentazione API

Il processo di sviluppo (ad esempio il server) rispetto alle specifiche API è simile a questo:

  • Generazione locale / aggiornamento degli stub del server
  • Impegna in SCM
  • Il codice server viene quindi implementato rispetto agli stub generati e controllati

La domanda è, se questa è la soluzione ideale per lavorare con un generatore di codice in generale. Ho la sensazione sottile che la generazione locale di codice non sia la soluzione migliore qui, poiché è necessario aggiornare regolarmente l'SCM con gli stub di nuova generazione per essere aggiornati con le modifiche alle specifiche API.

Un'idea che mi è venuta in mente è quella di fare ad es. uso di un gestore di repository artefatto (come Artifactory). Il processo di compilazione potrebbe quindi creare una libreria di stub del server in base alle specifiche API che viene inserita nel gestore degli artefatti. Gli sviluppatori possono utilizzare il loro sistema di build locale per aggiornare la dipendenza. Tuttavia, questo processo potrebbe essere eccessivo.

Dato che non sono riuscito a trovare buone risorse sull'integrazione dei generatori di codice in un processo di sviluppo software utilizzando pipeline CI / CD, sono molto interessato alle migliori pratiche qui (o forse c'è una buona soluzione specifica per il mio esempio precedentemente descritto ?).

    
posta Matthias Preu 16.05.2018 - 18:51
fonte

1 risposta

2

Should the local build environment of a developer be responsible to do code generation?

Sì. Dove altro lo faresti? Se non lo fai lì, il tuo programma non funzionerà correttamente nell'IDE. Se il tuo programma non funziona correttamente nell'IDE, non puoi testarlo e eseguirne il debug localmente.

Ad esempio, utilizziamo Fody.PropertyChanged per generare codice un'implementazione INotifyPropertyChanged per le nostre classi View Model. La generazione del codice viene avviata come parte del processo di creazione dell'IDE.

Il nostro server di build ripete questo processo di generazione del codice quando esegue la sua build e test.

Should generated code be part of the project's code repository?

No. Non l'hai scritto. Lo scopo di un repository di codice è quello di memorizzare, mantenere e tenere traccia del codice che scrivi. Il codice generato da uno strumento non è interessante in questo modo. Il codice che genera il codice potrebbe essere.

Non memorizziamo il codice generato da Fody, perché l'intero punto di questa generazione di codice è di astrarre quei dettagli. L'attributo [AddINotifyPropertyChangedInterface] che attiva questa generazione di codice è invece memorizzato nel controllo del codice sorgente.

Supponendo che il codice generato "si prenda cura di se stesso" non è necessario memorizzarlo nel controllo del codice sorgente, ma ci sono delle eccezioni. Ad esempio, potresti ancora archiviare gli script SQL generati da uno strumento come Sql Server Management Studio nel repository di codice, se non hai un passaggio automatico che sincronizzi le modifiche del database per te.

    
risposta data 17.05.2018 - 17:06
fonte