Come lavorare in team su InDe Cloud

[d.termini]

Ne avevamo discusso nell’ultima riunione ma non avendo ancora visto movimento riguardante questo tema inizio suggerendo alcuni punti di discussione.

1. Predisposizione del team
   Su InDe Cloud è tutto gestito a permessi, anche se un progetto è salvato nell’organizzazione, il progetto che ho creato e in cui posso effettuare delle modifiche è mio e posso farle solo io.
   I collaboratori possono clonare il progetto e lavorare per conto loro e poi richiedere l’integrazione delle modifiche.
   Questo significa che se io non sono disponibile gli altri collaboratori non possono fare molto.
   Come si può risolvere questo problema?

2. Struttura del progetto e debug in team
   Per progetti semplici o fino a frontend-backend lo sviluppo non è problematico.
   Quando in un progetto però si ha la necessità di avere più applicazioni, ad esempio una che gira in server session, il backend, diversi frontend già si rende complicato lo sviluppo e il debug per un singolo sviluppatore in quanto l’IDE non consente di avviare più di una applicazione per volta se non in modalità FeBe.
   Se poi si ha necessità di provare anche la sincronizzazione tra due sessioni diverse è praticamente impossibile.
   Come si può gestire un progetto di complessità elevata e debuggarlo in team?

3. Teamworks, branching, recupero delle modifiche
   A differenza di InDe Foundation, su TW Cloud non sembra che ci sia la possibilità di prendere solo alcune modifiche da un branch ma bisogna per forza prendere tutto fino all’ultimo commit.
   Bisognerebbe per ogni modifica creare un branch a sé stante, con il rischio di perdersi nei meandri delle versioni, oltre a rischiare di generare modifiche concorrenziali o incompatibili sullo stesso codice.
   Questo è abbastanza limitante, come si può gestire tutto ciò?

4. Installazione e manutenzione delle applicazioni installate
   Premesso che le applicazioni vengano installate nel server di proprietà dell’organizzazione, è lo stesso discorso del punto 1, l’applicazione installata a quanto pare per molte funzioni la può gestire solo il proprietario.
   Sicuramente questo punto si risolve assieme al punto 1.

[giuseppe.lanzi]

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:

1. per vedere il codice di un progetto devi avere il permesso LEGGI.
2. per forkare un progetto devi avere il permesso EFFETTUA FORK sul progetto e CREA nelle impostazioni del profilo utente.
3. per installare devi avere permesso LEGGI sul server.
4. per effettuare query di update/delete devi avere permesso MODIFICA sul server.
5. 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 è:

1. Io gestisco progetto production e installo in produzione da questo progetto.
2. Io gestisco fork staging e installo in ambiente di test da questo progetto.
3. 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:

1. Ogni sviluppatore fa la pull request dal suo for staging dev a fork staging, io effettuo il merge e installo in test.
2. 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.
3. Ogni sviluppatore prova anche i commit dei colleghi, perché fanno tutti fetch. Quindi la casistica di test delle modifiche di estende.
4. 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.
5. 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.
6. 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:

1. Ogni sviluppatore può avere più fork autonomi e diversi, e può lavorare tranquillamente su ognuno.
2. Ogni volta che un ramo di modifica è pronto si può fare la Pull Request con solo quelle modifiche.
3. Ogni Pull Request può essere accettata o rifiutata isolatamente.
4. Ogni sviluppatore fa una fetch prima della pull request, così i conflitti li gestisce lui (e non il capo progetto che sennò impazzisce).

[giuseppe.lanzi]

Ho aggiunto la parte Teamworks, branching, recupero delle modifiche, al mio commento precedente.

[r.bianco]

Ciao Giuseppe,
espongo un caso e una domanda relativa.

Abbiamo il progetto master, che è quello che andrà nel server di produzione.
Abbiamo il fork di test, derivante da master, che è quello che andrà nel server di test.
Abbiamo il fork di sviluppo 1, derivante da test.
Abbiamo il fork di sviluppo 2, derivante da test.

Sviluppo 1 e sviluppo 2 finiscono il lavoro ed eseguono pull request.
Nel progetto test, viene eseguito il fetch di entrambe le pull request e viene pubblicato nel server di test.
Il test da esito positivo per le modifiche introdotte dallo sviluppatore 1, ma non quelle dello sviluppatore 2.
Come faccio a portare nel progetto master solo la parte dello sviluppatore 1?