Roberto, che ovviamente è il benvenuto fa una domanda molto interessante:
Mini pull request: ma che dimensioni avranno?
La domanda è un po’ rognosa, perché è un po’ come chiedere quanto deve essere grosso un microservizio, la risposta ovviamente è quella odiosa in stile consulente: dipende :-)
Facciamo un esempio per capire quale è il problema:
- stato creando una nuova demo
- la nuova demo è composta da una decina di progetti C#
Il primo approccio:
- scrivete tutto
- aprite la Pull Request
un vostro collega arriva e si ritrova con
- circa 400 file
- una quarantina di commit
È un’impresa veramente ardua, anche se avesse piena padronanza del contesto. Figuriamoci se non l’ha.
Tenendo come esempio qualcosa di completamente nuovo, come una nuova demo, vediamo come internamente ci aspettiamo che le cose funzionino.
Collaborazione
Ovvio che il primo muro da abbattere è quello che ha portato alla richiesta di review solo alla fine. È quindi fondamentale che chi sta costruendo la demo in questione inizi a committare e richiedere review il prima possibile.
Questo impone un’organizzazione mentale e pianificazione del lavoro molto rigorosa perché ovviamente ogni commit deve essere in qualche modo auto-consistente e revisionabile.
Consistenza
La consistenza è il secondo punto fondamentale, se in un commit ci sono modifiche non coese tra loro, ma che toccano parti del codice totalmente indipendenti chi fa review fa molta più fatica a capire cosa sta succedendo.
Dimensioni
Queste prime due pratiche aiutano ad alleviare il problema da cui siamo partiti, ma ovviamente se arrivassero ad un certo punto del processo un altro paio di occhi siamo da capo a piedi.
Mergiamo, è tanto tempo che non lo facciamo… (cit.)
Paradossalmente dopo che ogni commit è stato revisionato potremmo mergiare la branch su cui stiamo lavorando sulla linea principale. Il che ovviamente introduce il problema che rischiamo di rompere la catena di deploy perché non c’è scritto da nessuna parte che quello che stiamo sviluppando sia rilasciabile.
Ecco quindi che ha molto senso introdurre il concetto di linea non di produzione (develop) o addirittura di linee dedicate a funzionalità specifiche (aka feature-branch). Cosa ci impedisce di avere:
- Branch: develop
- Branch: demo-fantastica (aperta da develop)
- Branch: infrastruttura-demo-fantastica (aperta da demo-fantastica)
- Una piccola serie di piccoli commit coesi
- 3/4 commit nel nostro caso è un buon numero
- 5/6 file toccati per commit nel nostro caso è un buon numero
Ogni volta che il reviewer dice che va bene mergiamo la branch su cui stiamo lavorando su demo-fantastica e ne apriamo una nuova, con un nome sensato, per andare avanti. Questo ci garantisce che quello che sta su demo-fantastica sia stato sottoposto a review, non è completo e magari non funziona ancora ma la review iniziale è stata fatta.
Diciamocela, se non riusciamo a tenere le cose in piccolo e per introdurre una modifica siamo obbligati a toccare un sacco di roba probabilmente abbiamo altri problemi, che ricadono sotto il simpatico cappello chiamato “debito tecnico”.