Come possiamo evitare lo sviluppo guidato dall'IC ...?

Sto lavorando a un grande progetto open source guidato dalla ricerca, con un sacco di altri collaboratori regolari. Poiché il progetto ora è piuttosto grande, un consorzio (composto da due dipendenti a tempo pieno e pochi membri) è incaricato di mantenere il progetto, l'integrazione continua (CI), ecc. Non hanno tempo per l'integrazione di esterni contributi però.

Il progetto è composto da un framework "core", composto da circa mezzo milione di righe di codice, un gruppo di "plug-in" gestiti dal consorzio e diversi plug-in esterni, molti dei quali non sono ne sono nemmeno consapevole.

Attualmente, il nostro CI costruisce il core e i plugin gestiti.

Uno dei grandi problemi che affrontiamo è che la maggior parte dei contributori (e soprattutto quelli occasionali) non sta costruendo il 90% dei plugin mantenuti, quindi quando propongono di refactoring cambiamenti nel core (che in questi giorni avviene su base abbastanza regolare), hanno verificato che il codice si compili sulla propria macchina prima di effettuare una richiesta pull su GitHub.

Il codice funziona, sono contenti, quindi l'IC termina la compilazione e iniziano i problemi: la compilazione non è riuscita in un plug-in gestito dal consorzio, che il collaboratore non ha creato sulla propria macchina.

Tale plugin potrebbe avere dipendenze da librerie di terze parti, come ad esempio CUDA , e l'utente non vuole, non sa come, o semplicemente non può, per motivi hardware, compilare quel plugin rotto.

Allora - sia la soggiorni PR annuncio aeternam nel limbo di non-to-be-fuse PR - O il contribuente greps la variabile rinominato nel sorgente del plugin rotto, modificano il codice, spinge sul suo / la sua filiale, aspetta l'IC per completare la compilazione, in genere riceve più errori e reitera il processo fino a quando l'IC non è soddisfatto - O uno dei due permanenti già prenotati in eccesso nel consorzio dà una mano e cerca di riparare il PR sulla propria macchina.

Nessuna di queste opzioni è praticabile, ma non sappiamo come fare diversamente. Sei mai stato di fronte a una situazione simile dei tuoi progetti? E se sì, come hai gestito questo problema? C'è una soluzione che non vedo qui?

Lo sviluppo guidato da CI va bene! È molto meglio che non eseguire test e includere il codice non funzionante! Tuttavia, ci sono un paio di cose per rendere questo più facile per tutti i soggetti coinvolti:

• Stabilisci le aspettative: disponi di una documentazione di contributo che spieghi che l'IC spesso rileva ulteriori problemi e che questi dovranno essere risolti prima di unire. Forse spiega che è più probabile che i piccoli cambiamenti locali funzionino bene, quindi può essere sensato suddividere un grosso cambiamento in più PR.

• Incoraggia i test locali: semplifica l'impostazione di un ambiente di test per il tuo sistema. Uno script che verifica che tutte le dipendenze sono state installate? Un container Docker pronto per partire? Un'immagine di macchina virtuale? Il tuo runner di test ha meccanismi che consentono di dare la priorità ai test più importanti?

• Spiega come usare la CI da soli: parte della frustrazione è che questo feedback arriva solo dopo aver inviato una PR. Se i contributori configurano CI per i propri repository, otterranno un feedback precedente e produrranno meno notifiche CI per altre persone.

• Risolvi tutti i PR in entrambi i modi: se qualcosa non può essere unito perché è rotto e se non ci sono progressi verso la risoluzione dei problemi, chiudilo. Questi PR aperti abbandonati ingombrano tutto e qualsiasi feedback è meglio che ignorare il problema. È possibile esprimerlo molto bene e chiarire che ovviamente saresti felice di unirti quando i problemi saranno risolti. (vedi anche: The Art of Closing di Jessie Frazelle , Best Practices for Maintainers: Imparare a dire di no )

  Considera anche di rendere rilevabili questi PR abbandonati in modo che qualcun altro possa prenderli. Questo potrebbe anche essere un buon compito per i nuovi collaboratori, se i problemi rimanenti sono più meccanici e non richiedono una profonda familiarità con il sistema.

Per la prospettiva a lungo termine, i cambiamenti sembrano interrompere funzionalità non correlate così spesso che potrebbero significare che il tuo progetto attuale è un po 'problematico. Ad esempio, le interfacce dei plugin incapsulano correttamente gli interni del tuo core? Il C ++ semplifica la perdita accidentale di dettagli dell'implementazione, ma consente anche di creare astrazioni forti che sono molto difficili da utilizzare in modo improprio. Non puoi cambiarlo durante la notte, ma puoi guidare l'evoluzione a lungo termine del software verso un'architettura meno fragile.

La creazione di un modello di plug-in sostenibile richiede che il framework principale esponga un'interfaccia stabile su cui i plug-in possono fare affidamento. La regola d'oro è che puoi introdurre nuove interfacce nel tempo ma non puoi mai modificare un'interfaccia già pubblicata. Se segui questa regola, puoi riformattare l' implementazione del framework di base tutto ciò che desideri senza timore di rompere accidentalmente i plug-in, sia esso gestito da un consorzio o esterno.

Da quello che hai descritto, sembra che tu non abbia un'interfaccia ben definita, e questo rende difficile dire se una modifica interromperà i plugin. Lavora per definire questa interfaccia e renderla esplicita nella tua base di codice, in modo che i partecipanti sappiano cosa non dovrebbero modificare.

Ad essere sincero, non penso che tu possa gestirlo meglio - se i cambiamenti provocano la rottura di parti del tuo progetto mantenute, la CI dovrebbe fallire.

Il tuo progetto ha contributing.mdqualcosa o qualcosa di simile per aiutare i collaboratori nuovi e occasionali a preparare i loro contributi? Hai un elenco chiaro, quali plug-in fanno parte del core e devono rimanere compatibili?

Se è difficile costruire tutto su una macchina a causa di dipendenze, ecc., Potresti pensare di creare immagini docker pronte per l'uso come ambienti di compilazione utilizzabili dai tuoi collaboratori.

quindi quando propongono cambiamenti di refactoring nel core (che in questi giorni avviene su base abbastanza regolare), hanno verificato che il codice si compili sulla loro macchina prima di fare una richiesta pull su github.

Quindi penso che sia qui che può cadere lo stile sciolto dei progetti open source; la maggior parte dei progetti organizzati a livello centrale sono diffidenti nei confronti del refactoring di base, soprattutto quando attraversa un confine API. Se eseguono il refactoring di un limite API, di solito è un "big bang" in cui tutte le modifiche sono pianificate contemporaneamente con un incremento alla versione principale dell'API e viene mantenuta la vecchia API.

Proporrei una regola "tutte le modifiche all'API devono essere pianificate in anticipo": se arriva un PR che apporta una modifica all'API incompatibile all'indietro, da qualcuno che non è stato in contatto con i manutentori per concordare in anticipo il loro approccio, esso viene semplicemente chiuso e il mittente indica la regola.

Sarà inoltre necessario il versioning esplicito dell'API del plug-in. Ciò consente di sviluppare v2 mentre tutti i plug-in v1 continuano a essere compilati e funzionanti.

Vorrei anche mettere in dubbio un po 'di più il motivo per cui vengono apportati così tanti refactoring di base e modifiche API. Sono davvero necessari o solo persone che impongono il loro gusto personale al progetto?

Sembra che il processo di CI debba essere più rigoroso, più completo e più visibile ai partecipanti prima che aumentino un PR. Ad esempio, BitBucket ha una funzionalità di pipeline che lo consente, in cui gli si fornisce un file che definisce in codice il processo di creazione dell'elemento della configurazione e, in caso contrario, il ramo viene impedito dall'unione.

Indipendentemente dalla tecnologia, fornire build automatiche quando un contributore spinge verso una filiale fornirà loro un feedback molto più rapido su ciò che i guardiani devono cercare quando apportano modifiche e porterà a PR che non devono essere riparati dopo il fatto.

I problemi di progettazione sarebbero utili da risolvere, ma sono ortogonali a questo problema.

Il codice funziona, sono contenti, quindi l'IC termina la compilazione e iniziano i problemi: la compilazione non è riuscita in un plug-in gestito dal consorzio, che il collaboratore non ha creato sulla propria macchina.

Tale plug-in potrebbe avere dipendenze da librerie di terze parti, come ad esempio CUDA, e l'utente non desidera, non sa come, o semplicemente non può, per motivi hardware, compilare quel plug-in rotto.

La tua soluzione è semplice: abbassa la barriera al contributo .

Il modo più semplice per (1) accelerare il ciclo di modifica-compilazione-test e (2) uniformare le differenze di ambiente è fornire server di build :

• Prendi macchine robuste: 24, 48 o 96 core, 2 GB di RAM / core, SSD, per accelerare la compilazione.
• Assicurati che abbiano l'hardware giusto: FPGA, scheda grafica, qualunque cosa sia necessaria.
• Crea un'immagine Docker con tutte le librerie software necessarie preinstallate.

E quindi apri quei server di build ai collaboratori. Dovrebbero essere in grado di accedere in remoto in una nuova immagine Docker e modificare-compilare-test in remoto su questa macchina.

Poi:

• Non hanno scuse per non creare / testare i plugin mantenuti: hanno tutto a disposizione.
• Non devono attendere un lungo feedback con PR guidati da CI: hanno una compilazione incrementale e la possibilità di eseguire il debug (piuttosto che indovinare).

In generale, i server di compilazione possono essere condivisi tra più collaboratori, tuttavia quando sono coinvolte periferiche hardware speciali può essere necessario che un collaboratore utilizzi tali periferiche da soli.

Fonte: lavorando su software che utilizza FPGA, dato il prezzo degli animali e la varietà di modelli di cui abbiamo bisogno, non trovi ogni modello di FPGA installato su ogni macchina dello sviluppatore.

Se contribuire al core senza modificare alcun contratto può rompere il software dipendente, suggerisce che:

• I contratti delle tue interfacce possono essere ambigui. Forse l'aggiunta di attributi alle funzioni e i parametri delle funzioni aiuterebbe ad esporre vincoli aggiuntivi al codice client per rendere più chiari i contratti. O se stai applicando modifiche che violano il contratto, forse l'adozione del controllo delle versioni semantico può aiutare.
• I test unitari non coprono abbastanza dei possibili scenari di chiamata.

Entrambi i problemi dovrebbero essere facili da risolvere, ma dici che il core team potrebbe non avere la capacità di farlo. Un'opzione sarebbe quella di chiedere aiuto alla comunità per affrontare il problema.

Nessun altro sembra aver sollevato questo come una potenziale soluzione.

• elenca tutti i plugin a cui puoi accedere.
• eseguire tutti i test definiti da questi plugin
• registra tutte le richieste / risposte / interazioni tra il core e tutti i plugin
• memorizzare quelle registrazioni, ora si tratta di test di compatibilità approssimativi.

Quando si sviluppa il core, incoraggiare gli sviluppatori a eseguire questi test di compatibilità. In caso contrario, non effettuare il check-in.

Ciò non garantirà al 100% la compatibilità, ma colpirà molti più problemi e presto.

Un vantaggio secondario è che queste registrazioni possono evidenziare quali interfacce vengono utilizzate attivamente e quali funzionalità vengono utilizzate attivamente.

Ho difficoltà a comprendere la situazione così come sembra: l'IC crea un solo ramo?

C'è un motivo per cui non è possibile creare più di un ramo con l'elemento della configurazione?

La soluzione più semplice a questo problema sarebbe quella di consentire a qualsiasi collaboratore di eseguire la build CI sul proprio ramo di funzionalità .

Quindi è sufficiente una compilazione CI riuscita sul ramo della funzione per poter accettare la richiesta pull di quel ramo.