Grazie @d.termini, bel set di domande. Cerco di dare la mia esperienza diretta. Perché oltre a guidare il team di sviluppo della console, lo faccio con la console stessa e senza avere alcuna scorciatoia rispetto alle possibilità dei nostri utenti. Certo c’è ancora da fare e tante cose sono migliorabili, ma probabilmente ci sono anche già molte soluzioni adottabili.
Rispondo un punto per volta, così ci riesco, altrimenti mi serve troppo tempo per scrivere la risposta.
Ora pubblico la risposta alla prima domanda, appena riesco pubblico anche le altre.
Predisposizione del team
Su IDC è tutto gestito a permessi, anzi direi a permessi multipli:
- per vedere il codice di un progetto devi avere il permesso LEGGI.
- per forkare un progetto devi avere il permesso EFFETTUA FORK sul progetto e CREA nelle impostazioni del profilo utente.
- per installare devi avere permesso LEGGI sul server.
- per effettuare query di update/delete devi avere permesso MODIFICA sul server.
- ecc. ecc.
Quando si installa un’app sul server, questa viene riconosciuta per nome. Quindi se usi sempre lo stesso nome sovrascrivi la precedente e sennò ne fai un’altra copia. Lo stesso per il DB.
Per lavorare in team è sufficiente usare fork e commit. Io ho una struttura così:
progetto production → fork staging → fork staging dev.
In particolare la gestione dei progetti è:
- Io gestisco progetto production e installo in produzione da questo progetto.
- Io gestisco fork staging e installo in ambiente di test da questo progetto.
- Ogni sviluppatore (io compreso) ha un fork staging dev, o addirittura di più se sta lavorando a più progetto.
Per il merge delle modifiche ci sono queste condizioni utili:
- Ogni sviluppatore fa la pull request dal suo for staging dev a fork staging, io effettuo il merge e installo in test.
- Ogni sviluppatore fa fetch prima della pull request, risolvendo gli eventuali conflitti. In questo modo i conflitti sono gestiti dagli sviluppatori che li causano e non dal gestore del progetto.
- Ogni sviluppatore prova anche i commit dei colleghi, perché fanno tutti fetch. Quindi la casistica di test delle modifiche di estende.
- Ogni commit deve essere pensato come protetto per andare in produzione in qualsiasi momento. Se c’è una nuova funzionalità deve essere spenta con un parametro.
- Quando una staging è stabile, faccio la pull request su production master, si prova che vada tutto (cosa però già fatta anche in ambiente di test) e si installa su production.
- Se c’è da fare una fix urgente in produzione si fa un fork production master dev, e si lavora a quel livello ma allo stesso modo.
Per quanto riguarda l’installazione in caso di mia assenza, uno qualunque dei miei colleghi potrebbe installare la console al posto mio, direttamente dal suo progetto o da un fork production master dev creato apposta. Basta avere il permessi di lettura sul server. L’installazione avverrà dal suo progetto anziché dal mio, ma funzionerà allo stesso modo.
Al mio ritorno sarà possibile verificare la pull request e riportare tutto sul master.
Teamworks, branching, recupero delle modifiche
La gestione di fork, commit e gestione delle modifiche sono un argomento complesso. Quella che descrivi è l’operatività tipica di git. Nella maggior parte dei casi di fa push e fetch sempre all’ultimo commit. Anche l’estensione di Visual Studio Code, per intenderci, di default fa così: salva tutti i commit, manda tutto e prende tutto.
Io mi trovo bene come faccio nel progetto console: un fork per ogni ramo di modifica che ho in lavorazione (e chi lavora con me fa lo stesso). Questo porta a questo:
- Ogni sviluppatore può avere più fork autonomi e diversi, e può lavorare tranquillamente su ognuno.
- Ogni volta che un ramo di modifica è pronto si può fare la Pull Request con solo quelle modifiche.
- Ogni Pull Request può essere accettata o rifiutata isolatamente.
- Ogni sviluppatore fa una fetch prima della pull request, così i conflitti li gestisce lui (e non il capo progetto che sennò impazzisce).