Nota
L'accés a aquesta pàgina requereix autorització. Pots provar d'iniciar sessió o canviar de directori.
L'accés a aquesta pàgina requereix autorització. Pots provar de canviar directoris.
L'eina Solution Packager es pot utilitzar amb qualsevol sistema de control de codi font. Després d'extreure una solució .zip fitxer a una carpeta, afegiu-los i envieu-los al vostre sistema de control d'origen. Aquests fitxers es poden sincronitzar en un altre ordinador on es poden empaquetar en un fitxer .zip de la solució idèntic.
Un aspecte important quan s'utilitzen fitxers de components extrets al control d'origen és que afegir tots els fitxers al control d'origen pot causar duplicacions innecessàries. Aneu a la Referència de fitxers de components de la solució per descobrir quins fitxers es generen per a cada tipus de component i quins fitxers es recomanen per utilitzar-los al control d'origen.
Com que hi ha més personalitzacions i canvis necessaris per a la solució, els desenvolupadors han d'editar o personalitzar els components mitjançant mitjans existents, tornar a exportar-los per crear un fitxer .zip i extreure el fitxer de solució comprimida a la mateixa carpeta.
Important
Excepte les seccions descrites a Quan editar el fitxer de personalitzacions, no s'admet l'edició manual dels fitxers de components extrets i dels fitxers .zip.
Quan l'eina Solution Packager extreu els fitxers de components, no sobreescriu els fitxers de components existents amb el mateix nom si el contingut del fitxer és idèntic. A més, l'eina respecta l'atribut de només lectura en fitxers de components produint un avís a la finestra de la consola que no s'han escrit fitxers concrets. Aquesta protecció permet a l'usuari desprotegir, des del control d'origen, el conjunt mínim de fitxers que estan canviant. El paràmetre /clobber es pot utilitzar per anul·lar-ho i fer que els fitxers de només de lectura es puguin escriure o suprimir. El paràmetre /allowWrite es pot utilitzar per avaluar l'impacte que té una operació d'extracció sense escriure ni suprimir fitxers. L'ús del paràmetre /allowWrite amb el registre detallat és efectiu.
Un cop finalitzada l'operació d'extracció amb el conjunt mínim de fitxers desprotegits del control d'origen, un desenvolupador pot tornar a enviar els fitxers modificats al control d'origen, com es fa amb qualsevol altre tipus de fitxer d'origen.
Desenvolupament de l'equip
Quan hi ha diversos desenvolupadors treballant en el mateix component de solució, pot sorgir un conflicte quan els canvis de dos desenvolupadors donen lloc a canvis en un sol fitxer. Aquesta situació es redueix descomponent cada component editable o subcomponent individualment en un fitxer diferent. Tingueu en compte l'exemple següent.
Els desenvolupadors A i B estan treballant a la mateixa solució.
En ordinadors independents, tots dos reben els codis font més recents de la solució del control del codi font, empaqueten i importen un fitxer .zip d'una solució no administrada en organitzacions independents del Microsoft Dataverse.
El desenvolupador A personalitza la visualització del sistema "Contactes actius" i el formulari principal per a l'entitat Contacte.
El desenvolupador B personalitza el formulari principal de l'entitat Compte i canvia la "Visualització de cerca de contactes".
Tots dos desenvolupadors exporten un fitxer .zip de solució no administrada i l'extreuen.
Cal que el desenvolupador A recuperi un fitxer per al formulari principal de contacte i un fitxer per a la visualització Contactes actius.
El desenvolupador B haurà de desprotegir un fitxer per al formulari principal del compte i un fitxer per a la "Visualització de cerca de contactes".
Tots dos desenvolupadors podrien enviar, en qualsevol ordre, ja que els seus respectius canvis tocaven fitxers separats.
Un cop complertes les dues trameses, poden repetir el pas 2 i després continuar fent nous canvis en les seves organitzacions independents. Cadascun d'ells té tots dos conjunts de canvis, sense sobreescriptures de la seva pròpia feina.
L'exemple anterior només funciona quan hi ha canvis en fitxers separats. És inevitable que les personalitzacions independents requereixin canvis dins d'un sol fitxer. Basant-nos en l'exemple mostrat anteriorment, tingueu en compte que el desenvolupador B va personalitzar la visualització "Contactes actius" mentre que el desenvolupador A també la personalitzava. En aquest nou exemple, l'ordre dels esdeveniments esdevé important. Aquí es descriu el procés correcte per reconciliar aquesta situació, escrit íntegrament.
Els desenvolupadors A i B estan treballant a la mateixa solució.
En ordinadors independents, tots dos reben els codis font més recents de la solució del control del codi font, empaqueten i importen un fitxer .zip d'una solució no administrada en organitzacions independents.
El desenvolupador A personalitza la vista del sistema "Contactes actius" i el formulari principal per a la taula Contactes.
El desenvolupador B personalitza el formulari principal de la taula Compte i canvia els "Contactes actius".
Tots dos desenvolupadors exporten un fitxer .zip de solució no administrada i l'extreuen.
Cal que el desenvolupador A recuperi un fitxer per al formulari principal de contacte i un fitxer per a la visualització Contactes actius.
Cal que el desenvolupador B recuperi un fitxer per al formulari principal del compte i un fitxer per a la visualització "Contactes actius".
El desenvolupador A està a punt primer.
Abans que el desenvolupador A s'enviï al control d'origen, ha d'obtenir les fonts més recents per assegurar-se que no hi hagi registracions anteriors en conflicte amb els seus canvis.
No hi ha conflictes, de manera que el desenvolupador A pot enviar.
El desenvolupador B està a punt després del desenvolupador A.
Abans que el desenvolupador B enviï, ha d'obtenir les fonts més recents per assegurar-se que no hi hagi registres anteriors en conflicte amb els seus canvis.
Hi ha un conflicte perquè el fitxer de "Contactes actius" s'ha modificat des de l'última vegada que el desenvolupador B va recuperar les últimes fonts.
El desenvolupador B ha de conciliar el conflicte. És possible que les capacitats del sistema de control de fonts en ús puguin ajudar a aquest procés; en cas contrari, les opcions següents són viables.
El desenvolupador B, a través de l'historial de control de codi font, si està disponible, pot observar que el desenvolupador A ha fet el canvi anterior. Mitjançant la comunicació directa poden discutir cada canvi. Aleshores, el desenvolupador B només ha d'actualitzar l'organització amb la resolució acordada. A continuació, el desenvolupador B exporta, extreu i sobreescriu el fitxer en conflicte i l'envia.
Permet que el control d'origen sobreescrigui el fitxer local. El desenvolupador B empaqueta la solució i l'importa a la seva organització, després avalua l'estat de la visualització i la torna a personalitzar segons sigui necessari. A continuació, el desenvolupador B pot exportar, extreure i sobreescriure el fitxer en conflicte.
Si el canvi anterior es considera innecessari, el desenvolupador B permet que la seva còpia del fitxer sobreescrigui la versió al control d'origen i l'envia.
Ja sigui treballant en un entorn compartit o independent, el desenvolupament de Dataverse solucions en equip requereix que aquells que treballen activament en una solució comuna siguin conscients del treball dels altres. L'eina Solution Packager no elimina completament aquesta necessitat, però permet combinar fàcilment canvis no conflictius a nivell de control d'origen i ressalta de manera proactiva els components concisos on sorgeixen conflictes.
Les següents seccions són els processos genèrics per utilitzar eficaçment l'eina Solution Packager en el control d'origen quan es desenvolupa amb equips. Aquests funcionen igualment amb entorns independents o entorns de desenvolupament compartits, tot i que amb entorns compartits l'exportació i l'extracció inclouen naturalment tots els canvis presents a la solució, no només els realitzats pel desenvolupador que realitza l'exportació. De la mateixa manera, quan s'importa una solució .zip fitxer es produeix el comportament natural per sobreescriure tots els components.
Crear una solució
Aquest procediment identifica els passos típics que s'utilitzen quan es crea una solució per primera vegada.
En un entorn Dataverse net, creeu una solució i, a continuació, afegiu o creeu components segons sigui necessari.
Quan estiguis a punt per registrar-te, segueix aquests passos.
Exporteu la solució no administrada.
Amb l'eina Solution Packager, extreu la solució en fitxers de components.
Des d'aquests fitxers de components extrets, afegiu-hi els fitxers necessaris al control del codi font.
Envieu aquests canvis al control del codi font.
Modificar una solució
El següent procediment identifica els passos típics que s'utilitzen per modificar una solució existent.
Sincronitzeu o obtingueu el codi font més recent dels fitxers de components de la solució.
Amb l'eina Solution Packager, empaqueteu fitxers de components en un fitxer .zip solució no administrat.
Importeu el fitxer de solució no administrat en un entorn.
Personalitzeu i editeu la solució segons calgui.
Quan estigueu a punt per comprovar els canvis al control d'origen, seguiu aquests passos.
Exporteu la solució no administrada.
Amb l'eina Solution Packager, extreu la solució exportada en fitxers de components.
Sincronitzeu o obtingueu el codi font més recent del control de codi font.
Concilieu si hi ha cap conflicte.
Envieu els canvis al control del codi font.
Els passos 2 i 3 s'han de dur a terme abans que es produeixin personalitzacions posteriors a l'organització de desenvolupament. Dins del pas 5, el pas b s'ha de completar abans del pas c.
Consulteu també
Referència del fitxer de components de la solució (SolutionPackager)
Eina SolutionPackager