Nota
O acceso a esta páxina require autorización. Pode tentar iniciar sesión ou modificar os directorios.
O acceso a esta páxina require autorización. Pode tentar modificar os directorios.
A ferramenta Solution Packager pódese usar con calquera sistema de control de código fonte. Despois de extraer un ficheiro .zip da solución a un cartafol, engada e envíe os ficheiros ao seu sistema de control de código fonte. Estes ficheiros pódense sincronizar noutro computador onde se poden empaquetar nun novo ficheiro .zip de solución idéntica.
Un aspecto importante ao usar ficheiros de compoñentes extraídos no control de código fonte é que engadir todos os ficheiros ao control de código fonte pode causar duplicación innecesaria. Vaia á Referencia de ficheiros de compoñentes da solución para descubrir que ficheiros se xeran para cada tipo de compoñente e que ficheiros se recomendan para o seu uso no control de código fonte.
Canto máis necesarias son as personalizacións e modificacións para a solución, os programadores deben editar ou personalizar os compoñentes a través dos medios existentes, exportar de novo para crear un ficheiro .zip e extraer o ficheiro de solucións comprimidas no mesmo cartafol.
Importante
Agás as seccións descritas en Cando editar o ficheiro de personalizacións, non se admite a edición manual dos ficheiros de compoñentes extraídos nin dos ficheiros .zip.
Cando a ferramenta Solution Packager extrae os ficheiros de compoñentes, non sobrescribe os ficheiros de compoñentes existentes co mesmo nome se o contido do ficheiro é idéntico. Ademais, a ferramenta respecta o atributo de só lectura nos ficheiros de compoñentes, o que produce un aviso na xanela da consola de que non se escribiron ficheiros específicos. Esta protección permite ao usuario extraer, desde o control de código fonte, o conxunto mínimo de ficheiros que están a cambiar. O parámetro /clobber pódese usar para anular e facer que os ficheiros só de lectura sexan escritos ou eliminados. O parámetro /allowWrite pódese usar para avaliar o impacto que ten unha operación de extracción sen facer que se escriban ou eliminen ficheiros. O uso do parámetro /allowWrite con rexistro detallado é efectivo.
Despois de que a operación de extracción se complete co conxunto mínimo de ficheiros extraídos do control de código fonte, un programador pode enviar os ficheiros modificados de volta ao control de código fonte, como se fai con calquera outro tipo de ficheiro de código fonte.
Desenvolvemento de equipo
Cando hai varios desenvolvedores traballando no mesmo compoñente da solución, pode xurdir un conflito cando os cambios realizados por dous desenvolvedores provoquen cambios nun único ficheiro. Esta ocorrencia minimízase descompoñendo cada compoñente ou subcompoñente editable individualmente nun ficheiro distinto. Teña en conta o seguinte exemplo.
Os programadores A e B están a traballar na mesma solución.
En computadores independentes, ambos reciben as últimas orixes da solución desde o control de orixe, empaquetan e importan un ficheiro .zip de solución non xestionada en organizacións independentes de Microsoft Dataverse.
O programador A personaliza a visualización do sistema "Contactos activos" e o formulario principal da entidade Contacto.
O programador B personaliza o formulario principal para a entidade Conta e modifica a "Vista de busca de contactos".
Ambos programadores exportan un ficheiro .zip de solución non xestionada e extráeno.
O programador A terá que consultar un ficheiro para o formulario principal Contacto e un ficheiro para a visualización "Contactos activos".
O programador B terá que retirar un ficheiro para o formulario principal da conta e un ficheiro para a "Vista de busca de contactos".
Ambos os desenvolvedores poderían enviar, en calquera orde, xa que as súas respectivas modificacións tocaron ficheiros separados.
Despois de que os dous envíos estean completados, poden repetir o paso 2 e logo continuar facendo máis cambios nas súas organizacións independentes. Cada un deles ten ambos conxuntos de cambios, sen sobrescribir o seu propio traballo.
O exemplo anterior funciona só cando hai cambios para ficheiros independentes. É inevitable que as personalizacións independentes requiran cambios dentro dun único ficheiro. Baseándonos no exemplo mostrado anteriormente, consideremos que o programador B personalizou a vista "Contactos activos" mentres que o programador A tamén a estaba personalizando. Neste novo exemplo, a orde de eventos cobra importancia. O proceso correcto para reconciliar esta situación, descrito integramente, descríbese aquí.
Os programadores A e B están a traballar na mesma solución.
En computadores independentes, ambos reciben as últimas orixes da solución desde o control de orixe, empaquetan e importan un ficheiro .zip de solución non xestionada en organizacións independentes.
O programador A personaliza a vista do sistema "Contactos activos" e o formulario principal da táboa Contacto.
O programador B personaliza o formulario principal da táboa Conta e cambia os "Contactos activos".
Ambos programadores exportan un ficheiro .zip de solución non xestionada e extráeno.
O programador A terá que consultar un ficheiro para o formulario principal Contacto e un ficheiro para a visualización "Contactos activos".
O programador B terá que consultar un ficheiro para o formulario principal Conta e un ficheiro para a visualización "Contactos activos".
O programador A está listo primeiro.
Antes de que o programador A envíe os cambios ao control de código fonte, debe obter os códigos fonte máis recentes para garantir que non haxa rexistros anteriores que entren en conflito cos seus cambios.
Non hai conflitos, polo que o programador A pode enviar.
O programador B está preparado despois do programador A.
Antes de que o programador B envíe o traballo, debe obter as fontes máis recentes para garantir que non haxa rexistros previos que entren en conflito cos seus cambios.
Hai un conflito porque o ficheiro de "Contactos activos" foi modificado desde a última vez que o programador B recuperou as fontes máis recentes.
O programador B debe conciliar o conflito. É posible que as capacidades do sistema de control de código fonte en uso poidan axudar neste proceso; se non, as seguintes opcións son todas viables.
O programador B, a través do historial de control de código fonte, se está dispoñible, pode observar que o programador A realizou o cambio anterior. Mediante comunicación directa poden discutir cada cambio. Entón, o desenvolvedor B só ten que actualizar a organización coa resolución acordada. O programador B exporta, extrae e sobrescribe o ficheiro en conflito e envíao.
Permitir que o control de código fonte sobrescriba o ficheiro local. O programador B empaqueta a solución e impórtaa na súa organización, despois avalía o estado da vista e a volve personalizar segundo sexa necesario. A continuación, o programador B podería exportar, extraer e sobrescribir o ficheiro en conflito.
Se a modificación anterior se considera innecesaria, o programador B permite que a súa copia do ficheiro sobrescriba a versión no control de código fonte e envíaa.
Tanto se se traballa nun ambiente compartido como nun ambiente independente, o desenvolvemento de solucións en equipo require que aqueles que traballan activamente nunha solución común sexan conscientes do traballo dos demais. Dataverse A ferramenta Empaquetador de solucións non elimina totalmente esta necesidade, pero permite a fusión sinxela de cambios non conflitivos no nivel de control de código fonte e destaca de forma proactiva os compoñentes concisos onde xorden conflitos.
As seguintes seccións son os procesos xenéricos para usar eficazmente a ferramenta Solution Packager no control de código fonte ao desenvolver con equipos. Funcionan igualmente con entornos independentes ou con entornos de desenvolvemento compartidos, aínda que cos entornos compartidos a exportación e a extracción inclúen naturalmente todos os cambios presentes na solución, non só os realizados polo desenvolvedor que realiza a exportación. Do mesmo xeito, ao importar un ficheiro .zip dunha solución prodúcese o comportamento natural de sobrescribir todos os compoñentes.
Crear unha solución
Este procedemento identifica os pasos típicos que se empregan ao crear unha solución por primeira vez.
Nun ambiente limpo con Dataverse, crea unha solución e, a seguir, engade ou crea compoñentes segundo sexa necesario.
Cando esteas listo para rexistrarte, segue estes pasos.
Exportar a solución non xestionada.
Usando a ferramenta Empaquetador de solucións, extraia a solución nos ficheiros de compoñentes.
A partir destes ficheiros de compoñentes extraídos, engada os ficheiros necesarios ao control de orixe.
Envíe estes cambios ao control de orixe.
Modificar unha solución
O seguinte procedemento identifica os pasos típicos empregados ao modificar unha solución existente.
Sincronice ou obteña as orixes de ficheiros de compoñentes da solución máis recentes.
Usando a ferramenta Solution Packager, empaqueta os ficheiros dos compoñentes nun ficheiro .zip de solución non xestionado.
Importar o ficheiro da solución non xestionada nun ambiente.
Personalice e edite a solución segundo sexa necesario.
Cando estea listo para comprobar os cambios no control de código fonte, siga estes pasos.
Exportar a solución non xestionada.
Usando a ferramenta Empaquetador de solucións, extraia a solución exportada en ficheiros de compoñentes.
Sincronice ou obteña as orixes máis recentes do control de orixe.
Reconcilie se existen conflitos.
Envíe os cambios ao control de orixe.
Os pasos 2 e 3 deben facerse antes de que se produzan máis personalizacións na organización de desenvolvemento. Dentro do paso 5, o paso b debe completarse antes do paso c.
Consulte tamén
Referencia do ficheiro de compoñentes da solución (SolutionPackager)
Ferramenta SolutionPackager