# Instant Developer Studio e lavoro in gruppo **URL:** \ **Category:** Documentazione\ **Created:** [3 Settembre 2026, 2:01pm UTC](https://community.instantdeveloper.com/t/instant-developer-studio-e-lavoro-in-gruppo/938 "2026-09-03T14:01:47Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![paolo.giannelli](https://community.instantdeveloper.com/user_avatar/community.instantdeveloper.com/paolo.giannelli/32/12_2.png) [@paolo.giannelli](https://community.instantdeveloper.com/u/paolo.giannelli)\ **Post date:** [3 Settembre 2026, 2:01pm UTC](https://community.instantdeveloper.com/t/instant-developer-studio-e-lavoro-in-gruppo/938/1 "2026-09-03T14:01:47Z")
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: - [Guida alla migrazione a IDS](https://doc.instantdeveloper.com/F2516CEA-BCF3-4E79-8D10-8A990CEA0A4A.htm?LANG=ITA) - [Guida all’uso di IDS](https://doc.instantdeveloper.com/35E31157-826A-4148-929E-4EF76039301F.htm?LANG=ITA) 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\` 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. ---
**Author:** ![d.termini](https://community.instantdeveloper.com/user_avatar/community.instantdeveloper.com/d.termini/32/199_2.png) [@d.termini](https://community.instantdeveloper.com/u/d.termini)\ **Post date:** [4 Settembre 2026, 7:14am UTC](https://community.instantdeveloper.com/t/instant-developer-studio-e-lavoro-in-gruppo/938/2 "2026-09-04T07:14:40Z")
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. ---
**Author:** ![2st\_ddimo](https://community.instantdeveloper.com/letter_avatar_proxy/v4/letter/2/ea5d25/32.png) [@2st\_ddimo](https://community.instantdeveloper.com/u/2st_ddimo)\ **Post date:** [8 Settembre 2026, 1:41pm UTC](https://community.instantdeveloper.com/t/instant-developer-studio-e-lavoro-in-gruppo/938/3 "2026-09-08T13:41:31Z")
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 ---
**Author:** ![paolo.giannelli](https://community.instantdeveloper.com/user_avatar/community.instantdeveloper.com/paolo.giannelli/32/12_2.png) [@paolo.giannelli](https://community.instantdeveloper.com/u/paolo.giannelli)\ **Post date:** [8 Settembre 2026, 2:23pm UTC](https://community.instantdeveloper.com/t/instant-developer-studio-e-lavoro-in-gruppo/938/4 "2026-09-08T14:23:20Z")
Grazie @2st_ddimo per la tua spiegazione, su Studio su può fare una cosa simile ora che è uscita la r8. ---
**Author:** ![paolo.giannelli](https://community.instantdeveloper.com/user_avatar/community.instantdeveloper.com/paolo.giannelli/32/12_2.png) [@paolo.giannelli](https://community.instantdeveloper.com/u/paolo.giannelli)\ **Post date:** [8 Settembre 2026, 3:20pm UTC](https://community.instantdeveloper.com/t/instant-developer-studio-e-lavoro-in-gruppo/938/5 "2026-09-08T15:20:35Z")
### 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). ---
**Author:** ![d.termini](https://community.instantdeveloper.com/user_avatar/community.instantdeveloper.com/d.termini/32/199_2.png) [@d.termini](https://community.instantdeveloper.com/u/d.termini)\ **Post date:** [9 Settembre 2026, 6:54am UTC](https://community.instantdeveloper.com/t/instant-developer-studio-e-lavoro-in-gruppo/938/6 "2026-09-09T06:54:20Z")
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? ---
**Author:** ![r.bianco](https://community.instantdeveloper.com/user_avatar/community.instantdeveloper.com/r.bianco/32/41_2.png) [@r.bianco](https://community.instantdeveloper.com/u/r.bianco)\ **Post date:** [9 Settembre 2026, 7:30am UTC](https://community.instantdeveloper.com/t/instant-developer-studio-e-lavoro-in-gruppo/938/7 "2026-09-09T07:30:33Z")
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. ---
**Author:** ![d.termini](https://community.instantdeveloper.com/user_avatar/community.instantdeveloper.com/d.termini/32/199_2.png) [@d.termini](https://community.instantdeveloper.com/u/d.termini)\ **Post date:** [9 Settembre 2026, 10:20am UTC](https://community.instantdeveloper.com/t/instant-developer-studio-e-lavoro-in-gruppo/938/8 "2026-09-09T10:20:22Z")
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.