Control de código fuente con archivos de solución

La herramienta Solution Packager puede usarse con cualquier sistema de control de código fuente. Una vez extraído el archivo .zip de la solución a una carpeta, añada y envíe los archivos a su sistema de control de código fuente. Estos archivos se pueden sincronizar a continuación en otro equipo donde se pueden comprimir en un nuevo archivo .zip de solución idéntico.

Un aspecto importante al usar los archivos componentes extraídos en el control de código fuente es que agregar todos los archivos al control de código fuente puede causar duplicación innecesaria. Consulte Referencia de archivo de componente de la solución para ver qué archivos se generan para cada tipo de componente y qué archivos se recomiendan para su uso en el control de código fuente.

Cuando sean necesarias más personalizaciones y cambios para la solución, los desarrolladores deberán modificar o personalizar los componentes con los medios existentes, exportar de nuevo para crear un archivo .zip y extraer el archivo comprimido de solución en la misma carpeta.

Cuando la herramienta Solution Packager extrae los archivos componentes no sobrescribe los archivos componentes existentes del mismo nombre si el contenido del archivo es idéntico. Además, la herramienta respeta el atributo de solo lectura en los archivos de componentes, generando una advertencia en la ventana de la consola que indica que determinados archivos no se escribieron. Esta protección permite al usuario extraer, desde el control de código fuente, el conjunto mínimo de archivos que están cambiando. El parámetro /clobber se puede utilizar para anular y permitir que los archivos de solo lectura se escriban o eliminen. El parámetro de /allowWrite se puede usar para evaluar el impacto que tiene una operación de extracción sin hacer realmente que ningún archivo se escriba o elimine. El uso del parámetro /allowWrite con registro detallado es efectivo.

Después de que la operación de extracción se complete con el conjunto mínimo de archivos extraídos del control de código fuente, un desarrollador puede enviar los archivos modificados de nuevo al control de código fuente, como con cualquier otro tipo de archivo.

Formatos de archivo de control de código fuente

La herramienta Solution Packager admite dos formatos de archivo para archivos de componente extraídos. La elección del formato correcto por adelantado evita tener que migrar la estructura del repositorio más adelante.

Cuándo usar el formato YAML: Para todos los proyectos nuevos y siempre que use la integración nativa de Git de Dataverse. El formato YAML es compatible con versiones futuras y genera un historial de cambios más limpio.

Cuándo usar el formato XML: Solo cuando se trabaja con repositorios existentes que ya usan el formato XML o cuando se usan herramientas heredadas que no admiten YAML.

Desarrollo de equipo

Cuando hay varios desarrolladores que trabajan en el mismo componente de la solución puede surgir un conflicto donde los cambios entre dos desarrolladores provoquen cambios a un archivo único. Esta instancia se minimiza descomponiendo cada componente o subcomponente individualmente editable en un archivo distinto. Tenga en cuenta el siguiente ejemplo.

1. El desarrollador A y B trabajan en la misma solución.

2. En equipos independientes, ambos obtienen la última versión de la solución del control de código fuente, empaquetan y luego importan un archivo .zip de solución no administrada en organizaciones independientes de Microsoft Dataverse.

3. El desarrollador A personaliza la vista del sistema "Contactos activos" y el formulario principal de la entidad Contact.

4. El desarrollador B personaliza el formulario principal para la entidad la Cuenta y cambia la «Vista de búsqueda de contacto».

5. Ambos desarrolladores exportan un archivo .zip de solución no administrada y lo extraen.

   1. El desarrollador A deberá consultar un archivo para el formulario principal de contacto y un archivo para la vista "Contactos activos".

   2. El Desarrollador B necesitará extraer un archivo para el formulario principal de la Cuenta y otro archivo para la «Vista de consulta de Contacto».

6. Ambos desarrolladores podrían enviar, en cualquier orden, ya que sus respectivos cambios afectan a archivos independientes.

7. Después de completarse ambos envíos, pueden repetir el paso #2 y después seguir realizando otros cambios en las organizaciones independientes. Cada uno tiene ambos conjuntos de cambios, sin sobrescritura de su propio trabajo.

El ejemplo anterior funciona únicamente cuando hay cambios en archivos separados. Es inevitable que las personalizaciones independientes requieran cambios en un archivo único. En función del ejemplo mostrado anteriormente, considere que el desarrollador B personalizó la vista "Contactos activos" mientras el desarrollador A también lo personalizaba. En este nuevo ejemplo, el orden de los eventos pasa a ser importante. Aquí se ofrece la descripción del proceso correcto para solucionar este problema, con todos los detalles.

1. El desarrollador A y B trabajan en la misma solución.

2. En equipos independientes, ambos obtienen las fuentes más recientes de la solución desde el control de código fuente, empaquetan el archivo .zip de solución no administrada e importan en organizaciones independientes.

3. El desarrollador A personaliza la vista del sistema "Contactos activos" y el formulario principal de la tabla Contacto.

4. El desarrollador B personaliza el formulario principal para la tabla Cuenta y cambia los «Contactos activos».

5. Ambos desarrolladores exportan un archivo .zip de solución no administrada y lo extraen.

   1. El desarrollador A deberá consultar un archivo para el formulario principal de contacto y un archivo para la vista "Contactos activos".

   2. El desarrollador B deberá consultar un archivo para el formulario principal de la cuenta y un archivo para la vista "Contactos activos".

6. El desarrollador A está listo primero.

   1. Antes de que el desarrollador A envíe al control de código fuente, debe obtener las versiones más recientes del código para garantizar que ninguna confirmación anterior entre en conflicto con sus cambios.

   2. No hay conflictos así que el desarrollador A puede enviar.

7. El desarrollador B está listo a continuación del desarrollador A.

   1. Antes de que el desarrollador B envíe, debe obtener las últimas fuentes para garantizar que ningún registro previo entre en conflicto con sus cambios.

   2. Hay un conflicto porque el archivo de "Active Contacts" se ha modificado desde que el desarrollador B recuperó por última vez las fuentes más recientes.

   3. El desarrollador B debe solucionar el conflicto. Es posible que las capacidades del sistema de control de código fuente en uso puedan ayudar en este proceso; si no las siguientes opciones son viables.

      1. El desarrollador B, mediante el historial de control de código fuente, si procede, puede consultar si el desarrollador A realizó el cambio anterior. A través de la comunicación directa pueden discutir cada cambio. A continuación, el desarrollador B tiene que actualizar la organización con la resolución acordada. A continuación, el desarrollador B exporta, extrae y sobrescribe el archivo en conflicto y lo envía.

      2. Permitir que el control de código fuente sobrescriba el archivo local. El desarrollador B empaqueta la solución y la importa a su organización, a continuación evalúa el estado de la vista y vuelve a personalizarla según sea necesario. A continuación, el desarrollador B puede exportar, extraer y sobrescribir el archivo en conflicto.

      3. Si el cambio anterior se considera no necesario, el desarrollador B permite que su copia del archivo sobrescriba la versión en el control de código fuente y la envíe.

Si trabaja en un entorno compartido o en entornos independientes, el desarrollo del equipo de soluciones de Dataverse requiere que los que trabajan activamente con una solución común conozcan el trabajo de otros usuarios. La herramienta Solution Packager no elimina completamente esta necesidad pero habilita la combinación fácil de cambios que no están en conflicto en el nivel de control de código fuente y resalta de forma proactiva los componentes concisos donde han surgido los conflictos.

Las secciones siguientes son procesos genéricos para usar eficazmente la herramienta Solution Packager en el control de código fuente al desarrollar con equipos. Estos funcionan por igual con los entornos independientes o con los entornos compartidos de desarrollo, aunque con los entornos compartidos la exportación y el extracto incluirán naturalmente todos los cambios presentes en la solución, no solo los creados por el desarrollador que realiza la exportación. De forma similar, cuando se importa un archivo .zip de solución se producirá el comportamiento natural de sobrescribir todos los componentes.

Crear una solución

El siguiente procedimiento identifica los pasos típicos usados al crear una solución por primera vez.

1. En un entorno limpio con Dataverse cree una solución y, a continuación, agregue o cree componentes como sea necesario.

2. Cuando esté listo para registrarse, siga estos pasos.

   1. Exporte la solución no administrada.

   2. Con la herramienta Solution Packager, extraiga la solución en archivos componentes.

   3. De los archivos de componentes extraídos, agregue los archivos necesarios al control de código fuente.

   4. Envíe estos cambios al control de origen.

Modificar una solución

El siguiente procedimiento identifica los pasos típicos usados al modificar una solución existente.

1. Sincronice o obtenga los últimos archivos de los componentes de la solución.

2. Con la herramienta Solution Packager, empaquete los archivos componentes en un archivo .zip de solución no administrada.

3. Importe el archivo de la solución no administrada en un entorno.

4. Personalice y modifique la solución como sea necesario.

5. Cuando esté listo para comprobar los cambios en el control de origen, haga lo siguiente.

   1. Exporte la solución no administrada.

   2. Con la herramienta Solution Packager, extraiga la solución exportada en los archivos componentes.

   3. Sincronice o obtenga las últimas fuentes del control de código.

   4. Solucione los conflictos si los hay.

   5. Envíe los cambios al control de código fuente.

   Los pasos 2 y 3 deben realizarse antes de que se produzcan más personalizaciones en la organización del desarrollo. En el paso 5, el paso b se debe completar antes que el paso c.

Vea también

Referencia de archivo de componente de la solución (SolutionPackager)
Herramienta de empaquetado de soluciones
Formatos de archivo de control de código fuente