Instant Developer Studio e lavoro in gruppo

Documentazione
1

Utilizzando Instant Developer Studio e lavorando in più di una persona su un determinato progetto lo strumento ottimale da utilizzare è il TeamWorks, cioè il GitHub di Instant Developer.

Si può anche lavorare scambiandosi il progetto come si fa su Foundation ma con alcune differenze.

Vediamo i due casi.

Con TeamWorks

Per poterlo utilizzare abbiamo bisogno di una licenza di tipo TeamWorks o superiore, nella licenza Standard questo strumento non è utilizzabile.
Oltre a questo occorre avere un bucket su Google Cloud Platform.
L’utilizzo del TeamWorks di Studio è descritto nei due manuali:

Sull’utilizzo del TeamWorks vi consiglio di leggere il manuale.
Nella versione attuale 26.0 r7 sono presenti alcuni bug che sono risolti nella r8 in uscita la settima prossima.

Altra cosa importante è il concetto di Copia master del progetto che non è quello di Foundation ma indica il progetto locale che è stato caricato sul bucket.
Da questa copia si accettano le PR e quindi si fanno i merge delle modifiche effettuate sui fork.
Come indicato nel manuale è possibile avere più copie master assegnate a vari utenti in modo che più di una persona possa accettare le PR.
Altro consiglio è che chi opera sulla copia master qui faccia solo i merge delle PR ma che anche lui lavori su un fork della copia master.
Questo perché i commit fatti sulla copia master vanno subito sul server e non sono solo locali e quindi sporcano la versione che si sta confezionando.

Senza TeamWorks

Anche senza licenza TeamWorks è possibile lavorare su uno stesso progetto ma il metodo è un po’ più complicato o meglio meno agevole.

Su Foundation posso tenere la cartella del progetto su un disco di rete e aprire da più installazioni dell’IDE il file .idp (non in contemporanea) e lavorarci. In questo modo faccio la mie modifiche salvo e chiudo e il progetto è disponibile all’utilizzo da parte di un altro sviluppatore.

Su Studio questa cosa non è possibile perché ogni utente ha i propri progetti tutti nella stessa cartella e questi sono legati all’utente, sia che siano memorizzati nel percorso di default \Documenti\Instant Developer\<utente> che in una cartella indicata dall’utente che potrebbe anche essere un disco di rete.
Questa possibilità però non deve trarre in inganno in quanto la lista dei progetti e la loro lettura e aggiornamento sono legati all’installazione.

Quindi posso indicare il percorso dove memorizzare i mie progetti che potrebbe essere un Google Drive o un One Drive in modo da avere un backup automatico della cartella dei progetti ma non può essere la stessa per utenti diversi.

Se voglio passare un progetto su cui ho lavorato ad un altro utente devo esportarlo dalla Console di Studio e l’altro utente deve importarlo.
Se il progetto è già presente verrà importato rinominato con un progressivo.

2 Mi Piace
2

Vorrei capire meglio come lavorare in gruppo con il sistema stile GitHub a branch e patch request.

Con Foundation è piuttosto semplice, c’è il lock sull’oggetto e lo può modificare un solo sviluppatore per volta, quindi praticamente i conflitti sono azzerati.

Preciso che non stiamo lavorando con i branch, quindi sporchiamo la copia master.

Solitamente quando dobbiamo pubblicare in test l’applicazione, uno sviluppatore (solitamente quello che non ha lavori in sospeso) recupera tutta la copia master (get last version) e la pubblica sul server di test.

Poi abbiamo una postazione dedicata in cui facciamo cherry picking delle modifiche pronte per la produzione e pubblichiamo. Questo passaggio è molto delicato in quanto è possibile che ci sfugga qualcosa anche se a turno controlliamo manualmente tutte le differenze del progetto in modo da essere sicuri di aver importato le cose corrette e lasciato le cose in test.

In ottica di passare a Studio (ma anche su Cloud) come bisogna organizzare questo sistema in modo da poter avere:

  • una copia master intesa come tutto quello che deve andare in produzione (ProgettoX_master)
  • una copia test con le modifiche di tutti gli sviluppatori (ProgettoX_testing)
  • una copia di sviluppo (ProgettoX_sviluppo) per ciascun sviluppatore, derivata da ProgettoX_master?
  • ogni copia di sviluppo ha un branch per ogni lavoro diverso (ProgettoX_LavoroA, ProgettoX_LavoroB,… ProgettoX_LavoroY)

Quello che non capisco è il giro delle PR, ossia:

Io sto lavorando su branch ProgettoX_LavoroY, ho finito lo sviluppo e quindi lo voglio unire alla mia copia di sviluppo “completa” ossia ProgettoX_sviluppo, faccio una PR.

Verifico che si comporti bene assieme al resto delle funzioni compilando la copia “completa”.

A questo punto lo voglio mandare alla copia di test, devo fare una PR dalla copia ProgettoX_sviluppo oppure riesco a recuperare la PR fatta in precedenza?

E quando ho finito il test di LavoroY e lo voglio pubblicare posso recuperare sempre la vecchia PR oppure devo fare una nuova PR da testing contenente tutto quello che era in test?

Se qualcuno può chiarirmi queste meccaniche lo ringrazio, perché io ho ancora la mentalità di Subversion, TW, Sourcesafe e tutti quei sistemi a lock… e infatti con GitHub mi sono sempre trovato male con progetti che contemplavano più di 2 livelli o branch di staging.

1 Mi Piace
3

Ciao, noi utilizziamo Instant Developer Cloud e siamo in due che sviluppiamo e abbiamo impostato i progetti in questo modo:

  • ProgettoX:
    • è il progetto che va in produzione e che viene installato; MAI modifiche in questo progetto;
  • ProgettoX-dev:
    • fork di ProgettoX, confluiscono tutti gli sviluppi dei programmatori;
    • eventuali hotfix urgenti, MAI sviluppo di nuovi funzioni;
    • quando tutte le modifiche sono stati “importate” si fa la Pull Request verso ProgettoX;
    • ProgettoX-dev → ProgettoX;
  • ProgettoX-dev-programmatore1/2/n-sviluppi:
    • fork di ProgettoX-dev: qui programmatore1/programmatore2/programmatoreN fa le sue modifiche, i nuovi sviluppi, ecc…
    • quando la modifica è terminata si fa la Pull Request verso ProgettoX-dev;
    • ProgettoX-dev-programmatore1/2/n-sviluppi → ProgettoX-dev → ProgettoX;
  • ProgettoX-dev-programmatore1/2/n-assistenze:
    • fork di ProgettoX-dev: qui programmatore1/2/n NON fa nuovi sviluppi MA corregge segnalazioni e bug senza intaccare eventuali sviluppi che sta facendo.
    • quando la modifica è terminata si fa la Pull Request verso ProgettoX-dev;
    • ProgettoX-dev-programmatore1/2/n-assistenza → ProgettoX-dev → ProgettoX;

Sostanzialmente ProgettoX-dev farà da “ponte” per passare le modifiche tra i vari programmatori prima di andare in produzione.

Noi non utilizziamo i branch perchè, aimè, fanno un po’ di casino e la gestione conflitti di TeamWorks non mi aggrada molto, preferirei una visualizzazione SideBySide che però non è prevista.

NOTA: programmatore1/2/n in realtà è il nome dello sviluppatore

5 Mi Piace
4

Grazie @2st_ddimo per la tua spiegazione, su Studio su può fare una cosa simile ora che è uscita la r8.

5

Come procedere al lavoro di gruppo su Instant Developer Studio.

Vediamo insieme come si può organizzare il lavoro utilizzando i fork.

  • progetto-x:
    • è il progetto che va in produzione e che viene installato;
    • MAI modifiche in questo progetto;
    • prog-1 che ha creato il progetto lo carica sul bucket e possiede la copia master.
  • progetto-x-dev:
    • fork di progetto-x effettuato da prog-1;
    • confluiscono qui tutti gli sviluppi dei programmatori;
    • eventuali hotfix urgenti, MAI sviluppo di nuovi funzioni;
    • quando tutte le modifiche sono stati “mergiate” si fa la Pull Request verso progetto-x;
    • prog-1 che ha creato il fork lo carica sul bucket in modo che anche questo progetto sia forkabile.
  • progetto-x-dev-prog-1/2/n-sviluppi:
    • fork di progetto-x-dev: qui prog-1/prog-2/prog-n fa le sue modifiche, i nuovi sviluppi, ecc…
    • quando la modifica è terminata si fa la Pull Request verso progetto-x-dev;
  • progetto-x-dev-prog-1/2/n-assistenze:
    • fork di progetto-x-dev: qui prog-1/2/n NON fa nuovi sviluppi MA corregge segnalazioni e bug senza intaccare eventuali sviluppi che sta facendo.
    • quando la modifica è terminata si fa la Pull Request verso progetto-x-dev;

La differenziazione tra sviluppi e assistenze non è essenziale ma può essere utile a ricordarsi per cosa hai fatto il fork.

Nel caso di sviluppi paralleli di un programmatore questo può fare più fork di progetto-x-dev e lavorarli separatamente oppure all’interno dello stesso fork utilizzare dei branch locali di cui farà il merge sul suo branch master prima di fare le PR a progetto-x-dev.

Da ricordare:

  • la vera copia master è quella che è sul bucket, la copia locale sul proprio PC è un fork con privilegi speciali per mergiare le PR e occhio che i commit fatti su questo in locale vanno subito sul bucket
  • se sono il programmatore che possiede la copia master anche io faccio un fork per fare sviluppo
  • se sono presenti più programmatori con copia master in locale e uno di essi mergia una PR gli altri devono fare Fetch per riallinearsi l bucket
  • se sono su progetto-x-dev come copia master e la copia sul bucket è stata aggiornata con le PR da un altro programmatore che ha l’autorizzazione ad avere la copia master dovrò fare Fetch e potrebbe capitare che dopo l’operazione il bottone Fetch sia di nuovo verde perché qualcuno potrebbe avere allineato una PR su progetto-x. In questo caso la prima Fetch viene dal bucket progetto-x-dev e la seconda dal bucket progetto-x.

Facciamo un esempio:

Faccio un fork di progetto-x-dev per aggiungere la gestione della login ad una app e lo chiamo progetto-x-dev-svil-login così mi ricordo anche dal nome da dove deriva e per cosa lo faccio (uso svil invece che sviluppi che è più corto).

2 Mi Piace
6

Vi ringrazio per la spiegazione e per gli esempi chiari.

Mi manca però un caso: la copia di test con tutto dentro, che non è progetto-x-dev perché poi alcune cose potrebbero non finire in pubblicazione perché devono tornare in sviluppo. Questa la chiamiamo progetto-x-test che potrebbe essere una versione “sorella” di progetto-x-dev, ma semplicemente muore lì, non si fanno PR da qui, serve solo a raccogliere tutto e poi pubblicarlo su un server di test.

Quindi dovrei fare PR verso -test e non verso -dev, ma poi come la recupero la PR su -dev?

7

Lo sviluppatore esegue il test sulla sua copia Liv.2 e, se positivo, passa il codice a Liv1. progetto-x-test.
Il product owner esegue il test su Liv1. progetto-x-test e, se positivo, da l’ok allo sviluppatore per passare le modifiche dal suo Liv.2 a Liv1. progetto-x-dev.

C’è da capire se questo doppio giro porta realmente un vantaggio oppure no. Forse se si hanno rilasci continui potrebbe essere vantaggioso… non saprei.

1 Mi Piace
8

Diciamo che servirebbe la funzione rebase (mi sembra) che permette di switchare ramo dell’albero su GitHub.

Io ho il progetto -x-dev-nuovafunzione legato a -x-dev dove faccio le mie modifiche, voglio metterle in test e faccio un rebase della working copy su ramo -test, faccio PR e la metto assieme a tutte le altre robe da installare su server di test.

Quando è stata testata se tutto ok torno a spostarmi su -x-dev e rifaccio la PR lì, altrimenti correggo e rimetto in test.

Adesso come adesso TW di InDe cloud/studio non permette di spostarsi orizzontalmente, a meno che non mi sia sfuggito qualcosa.

1 Mi Piace