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 consentire che i file di sola lettura vengano scritti o eliminati. 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 verbosa è valido.

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.

Formati di file di controllo del codice sorgente

Lo strumento Solution Packager supporta due formati di file per i file di componenti estratti. La scelta del formato corretto in primo piano evita di dover eseguire la migrazione della struttura del repository in un secondo momento.

Quando usare il formato YAML: Per tutti i nuovi progetti e ogni volta che si usa l'integrazione nativa di Dataverse Git. Il formato YAML è compatibile con versioni future e produce una cronologia delle modifiche più pulita.

Quando usare il formato XML: Solo quando si usano repository esistenti che usano già il formato XML o quando si usano strumenti legacy che non supportaNO YAML.

Sviluppo in team

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. Su computer separati, entrambi ottengono le ultime versioni della soluzione dal controllo del codice sorgente, impacchettano e importano un file di soluzione non gestito .zip in organizzazioni distinte Microsoft Dataverse.

3. Developer A personalizza la visualizzazione del sistema "Contatti attivi" e il modulo principale dell'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à controllare un file per il modulo principale Contatto e un file per la visualizzazione "Contatti attivi".

   2. Lo sviluppatore B dovrà controllare un file per il modulo principale dell'account e un file per la "Visualizzazione di 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 entrambi i set di modifiche, senza sovrascritture del loro 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. In base all'esempio illustrato in precedenza, si consideri che lo sviluppatore B ha personalizzato la visualizzazione "Contatti attivi" mentre lo sviluppatore A lo 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. Su computer indipendenti, entrambi ottengono le ultime versioni della soluzione dal controllo del codice sorgente, comprimono e importano un file .zip di una soluzione non gestita nelle organizzazioni indipendenti.

3. Developer A personalizza la visualizzazione di sistema "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à controllare un file per il modulo principale Contatto e un file per la visualizzazione "Contatti attivi".

   2. Lo sviluppatore B dovrà controllare un file per il modulo principale account e un file per la visualizzazione "Contatti attivi".

6. Lo sviluppatore A è pronto 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 è pronto 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. Si è verificato un conflitto perché il file dei "Contatti attivi" è stato modificato dopo che lo sviluppatore B ha recuperato per l'ultima volta le versioni più recenti delle origini.

   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 modifica precedente è ritenuta inutile, lo sviluppatore B consente che la propria copia del file sovrascriva la versione nel controllo del codice sorgente e la sottomette.

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.

Creare una soluzione

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 effettuare il check-in, segui i seguenti passaggi.

   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 componenti estratti, aggiungere i file necessari al controllo del codice sorgente.

   4. Inviare le modifiche al controllo del codice sorgente.

Modificare una soluzione

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 a registrare le modifiche nel sistema di controllo del codice sorgente, segui questi passaggi.

   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. Sincronizza o ottieni le versioni più recenti dal controllo versioni.

   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.

Vedi anche

Informazioni di riferimento sul file componente della soluzione (SolutionPackager)
Strumento SolutionPackager
Formati di file di controllo del codice sorgente