1. El repositorio debe ser la fuente de verdad
La practica correcta es que los cambios nazcan en desarrollo, se registren en Git, se revisen por pull request y luego se desplieguen a ambientes aguas abajo.
Guia de trabajo colaborativo
Litoclean Peru ยท Gerencia de Gestion de Proyectos e Innovacion
Esta web resume la estrategia recomendada para versionar soluciones de Power Platform, colaborar entre makers y desarrolladores, preparar tu PC, evitar errores frecuentes y desplegar con control entre desarrollo, pruebas y produccion.
Resumen ejecutivo
La practica correcta es que los cambios nazcan en desarrollo, se registren en Git, se revisen por pull request y luego se desplieguen a ambientes aguas abajo.
Git se usa para desarrollo. Pruebas, UAT y produccion deben recibir soluciones administradas o despliegues controlados por pipelines.
Se deben crear soluciones personalizadas no administradas. La solucion por defecto no se conecta a Git y no debe ser la base del trabajo colaborativo.
Si hoy necesitan una implementacion estable, auditable y facil de gobernar, la ruta mas segura es: ambiente DEV administrado + soluciones personalizadas + Git + pull requests + pipeline de despliegue. Si el equipo ya usa GitHub a nivel corporativo, se puede mantener GitHub para colaboracion y automatizacion, aun cuando la conexion nativa visible en Power Platform siga mostrando Azure DevOps.
Estrategias posibles
Es la ruta mas directa cuando en Power Apps aparece el panel Conectarse a Git para seleccionar organizacion, proyecto y repositorio.
Menor friccion para makers, mejor adopcion, operacion guiada desde la interfaz de Power Platform.
Cuando tu organizacion ya usa Azure DevOps o cuando quieres poner orden rapido sin exigir CLI a todo el equipo.
GitHub es ideal para revisiones, trazabilidad y automatizacion, incluso cuando la integracion nativa desde la interfaz todavia no este habilitada en tu tenant.
Flujos DevSecOps mas flexibles, integracion con acciones, revisiones y politicas corporativas.
Cuando GitHub es el estandar del area TI o cuando se requiere integracion con flujos existentes de CI/CD.
Combina facilidad operativa para makers y disciplina de despliegue para TI.
Para GGPI, este modelo permite que el equipo de negocio evolucione sin perder trazabilidad, mientras TI conserva control sobre calidad, aprobaciones y despliegues.
Plan recomendado
Define por lo menos DEV, TEST, UAT y PROD. Todos deben tener gobierno claro; los de desarrollo deben ser administrados.
Crea soluciones personalizadas por dominio funcional: por ejemplo GGPI_Proyectos, GGPI_Aprobaciones o Litoclean_Operaciones.
Usa main para estable, develop para integracion y ramas feature/, release/ y hotfix/.
Ningun cambio pasa a la rama principal sin pull request, evidencia funcional, comentario tecnico y aprobacion de responsable.
Empaqueta y despliega a TEST, UAT y PROD solo desde el repositorio o desde artefactos de build, nunca desde cambios manuales directos.
Preparacion local
Get-Command pac | Format-List
pac
pac auth create --environment "Nombre-o-URL-del-ambiente"
pac auth list
git --version
git config --global user.name "Tu Nombre"
git config --global user.email "tu.correo@empresa.com"
Ejemplos utiles
git clone https://github.com/tu-organizacion/ggpi-powerplatform.git
cd ggpi-powerplatform
git checkout develop
git pull
git checkout -b feature/formulario-solicitud-proyecto
# Realizar cambios en la solucion y validar
git add .
git commit -m "feat: agrega formulario de solicitud de proyecto GGPI"
git push -u origin feature/formulario-solicitud-proyecto
| Tipo | Ejemplo | Uso |
|---|---|---|
| Estable | main |
Version aprobada |
| Integracion | develop |
Trabajo integrado del equipo |
| Nueva funcionalidad | feature/flujo-aprobacion-ordenes |
Trabajo acotado |
| Liberacion | release/2026.06 |
Preparar salida |
| Correccion urgente | hotfix/error-autorizacion |
Atencion a produccion |
Ejemplo referencial para automatizar build y despliegue. Ajusta autenticacion, nombres de ambientes, versionado y permisos segun tu tenant.
name: Power Platform ALM
on:
workflow_dispatch:
pull_request:
branches: [ develop, main ]
jobs:
validate-solution:
runs-on: windows-latest
steps:
- uses: actions/checkout@v5
- name: Install PAC CLI
shell: pwsh
run: |
dotnet tool update --global Microsoft.PowerApps.CLI.Tool
$env:PATH += ";$HOME\.dotnet\tools"
pac
- name: Authenticate
shell: pwsh
run: |
pac auth create --environment "${{ vars.POWERPLATFORM_ENVIRONMENT_URL }}"
- name: Pack solution
shell: pwsh
run: |
pac solution pack --folder src/GGPI_Proyectos --zipfile out/GGPI_Proyectos.zip
- name: Import to test
if: github.ref == 'refs/heads/main'
shell: pwsh
run: |
pac solution import --path out/GGPI_Proyectos.zip --environment "${{ vars.POWERPLATFORM_TEST_URL }}"
Trabajo colaborativo
Propone y valida requerimientos, ajusta componentes low-code en soluciones controladas y documenta evidencia de negocio.
Gestiona repositorio, pipelines, ramas, code review, componentes PCF, plug-ins, scripts y controles de calidad.
Aprueba criterios de paso, prioriza backlog, decide salidas a UAT y produccion, y vela por trazabilidad y gobierno.
Casos de uso
Objetivo: controlar formularios, aprobaciones y trazabilidad de iniciativas internas.
Objetivo: digitalizar inspecciones, incidencias y seguimiento de tareas para operaciones o soporte.
| Elemento | Recomendacion | Justificacion |
|---|---|---|
| Ambiente de desarrollo | Uno principal y otros aislados para iniciativas grandes | Reduce choques y mejora paralelismo |
| Repositorio | Uno por dominio o programa | Ordena ownership y revisiones |
| Metodo de despliegue | Pipeline con aprobaciones | Evita cambios manuales no auditados |
| Gobierno | PR obligatorio + checklist funcional | Mejora calidad y control |
| Hotfix | Rama y ambiente dedicados | Permite corregir sin romper la siguiente version |
Errores frecuentes
Rompe trazabilidad, complica rollback y hace imposible una disciplina ALM madura.
Genera desorden, dificulta el versionado y no es el enfoque recomendado para equipos.
En componentes code-first, el codigo fuente debe ser la verdad; no dependas de DLL o bundles compilados como unica referencia.
Checklist
Recursos oficiales
Conceptos, beneficios y enfoque ALM con Dataverse.
Prerequisitos, conexion, binding y varios ambientes de desarrollo.
Como revisar cambios, conflictos, pull y commit.
Instalacion, autenticacion y operaciones desde tu PC.
Acciones disponibles para exportar, empaquetar y desplegar.
Roadmap y disponibilidad planificada de soporte nativo para GitHub.