Controllo del codice sorgente con i file della soluzione

Lo Strumento per la creazione di pacchetti di soluzioni può essere utilizzato in qualsiasi sistema di controllo del codice sorgente. Dopo che un file .zip della soluzione è stato estratto in una cartella, aggiungi e invia i file al sistema di controllo del codice sorgente. Questi file possono poi essere sincronizzati in un altro computer dove è possibile comprimerli in un nuovo file .zip della soluzione identico.

Un aspetto importante quando si utilizzano i file di componente estratti in controllo del codice sorgente è che l'aggiunta di tutti i file in controllo del codice sorgente potrebbe causare duplicati non necessari. Vai a Informazioni di riferimento sul file componente della soluzione per sapere quali file vengono generati per ciascun tipo di componente e quali file si consiglia di utilizzare nel controllo del codice sorgente.

Se ulteriori personalizzazioni e modifiche sono necessarie per la soluzione, gli sviluppatori devono modificare o personalizzare i componenti con mezzi esistenti, esportare di nuovo per creare un file .zip e estrarre il file di soluzione compresso nella stessa cartella.

Quando lo Strumento per la creazione di pacchetti di soluzioni estrae i file di componente, non sovrascrive i file di componente esistenti con lo stesso nome, se il contenuto dei file è identico. Inoltre, lo strumento rispetta l'attributo di sola lettura dei file di componente generando un avviso nella finestra della console indicante i file specifici che non sono stati scritti. Questa protezione consente all'utente di estrarre dal controllo del codice sorgente il set minimo di file che si stanno modificando. Il parametro /clobber può essere utilizzato per sovrascrivere e rendere di sola lettura i file da scrivere o eliminare. Il parametro /allowWrite può essere utilizzato per per valutare l'impatto di un'operazione di estrazione senza causare effettivamente la scrittura o l'eliminazione di alcun file. L'utilizzo del parametro /allowWrite con registrazione dettagliata è valida.

Dopo che l'operazione estratto è completata con il set minimo di file estratti dal controllo del codice sorgente, uno sviluppatore potrà inviare i file modificati nuovamente al controllo del codice sorgente, come si farebbe con qualsiasi altro tipo di file di origine.

Quando esistono più sviluppatori che utilizzano lo stesso componente di soluzione è possibile che si crei un conflitto quando le modifiche di due sviluppatori comportano modifiche in un solo file. L'eventualità è minima tramite la decomposizione di ogni singolo componente o sottocomponente modificabile in un file distinto. Di seguito è illustrato un esempio.

1. Gli sviluppatori A e B stanno entrambi utilizzando la stessa soluzione.

2. Dai singoli computer, entrambi ottengono le origini più recenti della soluzione dal controllo del codice sorgente, comprimono e importano un file .zip di una soluzione non gestita nelle organizzazioni Microsoft Dataverse indipendenti.

3. Lo sviluppatore A personalizza la visualizzazione di sistema dei contatti attivi e il modulo principale per l'entità contatto.

4. Lo sviluppatore B personalizza il modulo principale per l'entità Account e modifica "Visualizzazione Ricerca contatto".

5. Entrambi gli sviluppatori esportano un file .zip della soluzione non gestita ed eseguono l'estrazione.

   1. Lo sviluppatore A dovrà estrarre un file per il modulo principale contatto e un file per la visualizzazione dei contatti attivi.

   2. Lo sviluppatore B dovrà estrarre un file per il modulo principale account e un file per "Visualizzazione Ricerca contatto".

6. Entrambi gli sviluppatori possono inviare, in qualsiasi ordine, in quanto le rispettive modifiche hanno toccato file distinti.

7. Una volta completati gli invii, possono ripetere il passaggio 2 e continuare ad apportare modifiche nelle organizzazioni indipendenti. Entrambi hanno i set di modifiche, senza sovrascritture del proprio lavoro.

L'esempio precedente funziona solo in caso di modifiche a file distinti. È inevitabile che le personalizzazioni indipendenti richiedano modifiche in un unico file. Basandosi sull'esempio precedente, si consideri che lo sviluppatore B abbia personalizzato la visualizzazione dei contatti attivi mentre anche lo sviluppatore A la stava personalizzando. In questo nuovo esempio, l'ordine degli eventi diventa importante. Il processo corretto per riconciliare questo frangente, scritto per intero, è indicato di seguito.

1. Gli sviluppatori A e B stanno entrambi utilizzando la stessa soluzione.

2. Dai singoli computer, entrambi ottengono le origini più recenti della soluzione dal controllo del codice sorgente, comprimono e importano un file .zip di una soluzione non gestita nelle organizzazioni indipendenti.

3. Lo sviluppatore A personalizza la visualizzazione di sistema dei contatti attivi e il modulo principale per la tabella Contatto.

4. Lo sviluppatore B personalizza il modulo principale per la tabella Account e modifica "Contatti attivi".

5. Entrambi gli sviluppatori esportano un file .zip della soluzione non gestita ed eseguono l'estrazione.

   1. Lo sviluppatore A dovrà estrarre un file per il modulo principale contatto e un file per la visualizzazione dei contatti attivi.

   2. Lo sviluppatore B dovrà estrarre un file per il modulo principale account e un file per la visualizzazione dei contatti attivi.

6. Lo sviluppatore A finisce per primo.

   1. Prima di inviare al controllo del codice sorgente, lo sviluppatore A deve ottenere le origini più recenti per assicurarsi che nessuna archiviazione precedente sia in conflitto con le modifiche che ha apportato.

   2. Non sono presenti conflitti quindi lo sviluppatore A può inviare.

7. Lo sviluppatore B finisce subito dopo lo sviluppatore A.

   1. Prima di inviare, lo sviluppatore B deve ottenere le origini più recenti per assicurarsi che nessuna archiviazione precedente sia in conflitto con le modifiche che ha apportato.

   2. Esiste un conflitto perché il file per "Contatti attivi" è stato modificato dopo l'ultimo recupero delle origini più recenti da parte dello sviluppatore B.

   3. Lo sviluppatore B deve risolvere il conflitto. È possibile che le funzionalità del sistema di controllo del codice sorgente in uso siano utili per il processo; in caso contrario, sono disponibili le seguenti opzioni.

      1. Lo sviluppatore B, tramite la cronologia del controllo del codice sorgente, se disponibile, può verificare che lo sviluppatore A ha effettuato la modifica per primo. Tramite la comunicazione diretta possono discutere ogni modifica. Quindi lo sviluppatore B deve soltanto aggiornare l'organizzazione con la risoluzione concordata. Lo sviluppatore B quindi esporta, estrae e sovrascrive il file in conflitto e invia.

      2. Consente al controllo del codice sorgente di sovrascrivere il file locale. Lo sviluppatore B comprime la soluzione e la importa nell'organizzazione, quindi valuta lo stato della visualizzazione e di nuovo la personalizza secondo le esigenze. Quindi, lo sviluppatore B potrebbe esportare, estrarre e sovrascrivere il file in conflitto.

      3. Se la prima modifica può essere ritenuta inutile, lo sviluppatore B consente la sovrascrittura della versione con la copia del file nel controllo del codice sorgente e invia.

Se si lavora a un ambiente condivisa o in un ambiente indipendente, lo sviluppo in team di soluzioni Dataverse richiede che quelli che lavorano attivamente su una soluzione comune siano a conoscenza del lavoro degli altri. Lo Strumento per la creazione di pacchetti di soluzioni non elimina totalmente questa necessità, ma consente l'unione delle modifiche non in conflitto a livello di controllo del codice sorgente e evidenzia proattivamente i componenti concisi in cui si sono verificati i conflitti.

Le prossime sezioni indicano i processi generici per utilizzare efficacemente lo Strumento per la creazione di pacchetti di soluzioni nel controllo del codice sorgente quando si sviluppa in team. Le sezioni valgono ugualmente per gli ambienti indipendenti o per gli ambienti di sviluppo condivisi, ma per gli ambienti condivisi l'esportazione e l'estrazione includono naturalmente tutte le modifiche presenti nella soluzione, non solo quelle applicate dallo sviluppatore che esegue l'esportazione. Analogamente durante l'importazione di un file .zip della soluzione, si applica il comportamento naturale che sovrascrive tutti i componenti.

Questa procedura illustra i passaggi tipici da utilizzare quando si crea per la prima volta una soluzione.

1. In un ambiente pulito con Dataverse, crea una soluzione e quindi aggiungi o crea componenti a seconda delle esigenze.

2. Quando sei pronto per l'archiviazione, esegui la procedura seguente.

   1. Esportare la soluzione non gestita.

   2. Tramite lo Strumento per la creazione di pacchetti di soluzioni, estrai la soluzione nei file del componente.

   3. Dai file del componente estratti, aggiungere i file necessari al controllo del codice sorgente.

   4. Inviare le modifiche al controllo del codice sorgente.

Nella procedura seguente vengono illustrati i passaggi tipici da utilizzare quando si modifica una soluzione esistente.

1. Sincronizzare oppure ottenere le origini più recenti dei file dei componenti della soluzione.

2. Tramite lo Strumento per la creazione di pacchetti di soluzioni, comprimi i file di componente in un file .zip della soluzione non gestita.

3. Importare il file della soluzione non gestita in un ambiente.

4. Personalizzare e modificare la soluzione secondo le esigenze.

5. Quando sei pronto al controllo delle modifiche nel controllo del codice sorgente, effettua quanto segue.

   1. Esportare la soluzione non gestita.

   2. Tramite lo Strumento per la creazione di pacchetti di soluzioni, estrai la soluzione esportata nei file del componente.

   3. Sincronizzare oppure ottenere le origini più recenti dal controllo del codice sorgente.

   4. Riconciliare in caso di conflitti.

   5. Inviare le modifiche al controllo del codice sorgente.

   I passaggi 2 e 3 devono essere eseguiti prima di apportare ulteriori personalizzazioni nell'organizzazione di sviluppo. Nel passaggio 5, il passaggio b deve essere completato prima del passaggio c.

Informazioni di riferimento sul file componente della soluzione (SolutionPackager)
Strumento SolutionPackager