Condividi tramite

Controllo del codice sorgente con i file della soluzione

  • Articolo

Lo strumento SolutionPackager 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. Vedi 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.

Importante

Ad eccezione delle sezioni descritte in Quando modificare il file delle personalizzazioni, la modifica manuale dei file dei componenti estratti e dei file .zip non è supportata.

Quando lo strumento SolutionPackager 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. Questo consente all'utente da 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.

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. 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 la visualizzazione di ricerca dei contatti.

  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 di ricerca dei contatti.

  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 l'entità contatto.

  4. Lo sviluppatore B personalizza il modulo principale per l'entità Account e modifica i contatti attivi.

  5. Entrambi gli sviluppatori esportano una soluzione non gestita. File .zip ed 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 i 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 la personalizza di nuovo 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 alla copia del file di sovrascrivere la versione nel controllo del codice sorgente e invia.

Se si lavora a un'organizzazione condivisa o in organizzazioni indipendenti, 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 SolutionPackager 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 SolutionPackager nel controllo del codice sorgente quando si sviluppa in team. Le sezioni valgono ugualmente per le organizzazioni indipendenti o le organizzazioni di sviluppo condivise, ma per le organizzazioni condivise l'esportazione e l'estrazione includeranno 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

Nella procedura seguente vengono illustrati i passaggi tipici da utilizzare quando si crea per la prima volta una soluzione.

  1. In un'organizzazione pulita, creare una soluzione nel server Dataverse e quindi aggiungere o creare componenti a seconda delle esigenze.

  2. Quando si è pronti per l'archiviazione, eseguire la procedura seguente.

    1. Esportare la soluzione non gestita.

    2. Utilizzando lo strumento SolutionPackager, 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.

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. Utilizzando lo strumento SolutionPackager, comprimi i file di componente in un file .zip della soluzione non gestita.

  3. Importare il file della soluzione non gestita in un'organizzazione.

  4. Personalizzare e modificare la soluzione secondo le esigenze.

  5. Quando si è pronti al controllo delle modifiche nel controllo del codice sorgente, effettuare quanto segue.

    1. Esportare la soluzione non gestita.

    2. Utilizzando lo strumento SolutionPackager, 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.

Vedi anche

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