PP

Guia de trabajo colaborativo

Power Platform, Git y GitHub

Litoclean Peru ยท Gerencia de Gestion de Proyectos e Innovacion

Todo lo que necesitas saber para conectar Power Platform con Git y GitHub y trabajar en equipo de forma profesional

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.

Ver plan recomendado
  • Power Apps
  • Power Automate
  • Dataverse
  • Git
  • GitHub
  • Azure DevOps
  • ALM

Resumen ejecutivo

Que debes entender antes de empezar

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.

2. Desarrollo y produccion no se mezclan

Git se usa para desarrollo. Pruebas, UAT y produccion deben recibir soluciones administradas o despliegues controlados por pipelines.

3. No se trabaja en la Default Solution

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.

Mensaje clave para Litoclean Peru y la GGPI

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

Como se conecta Power Platform con Git y GitHub

Azure DevOps con integracion nativa desde Solutions

Es la ruta mas directa cuando en Power Apps aparece el panel Conectarse a Git para seleccionar organizacion, proyecto y repositorio.

  • Se conecta desde Solutions en Power Apps, Power Automate, Copilot Studio o Power Pages.
  • Requiere Managed Environments y permisos de System Administrator para la vinculacion inicial.
  • Permite trabajar con environment binding o solution binding.
  • Los cambios se ven desde la pantalla Source control, donde puedes revisar, resolver conflictos, hacer pull y commit.

Ventajas

Menor friccion para makers, mejor adopcion, operacion guiada desde la interfaz de Power Platform.

Cuando elegirlo

Cuando tu organizacion ya usa Azure DevOps o cuando quieres poner orden rapido sin exigir CLI a todo el equipo.

GitHub con repositorios, PRs y GitHub Actions

GitHub es ideal para revisiones, trazabilidad y automatizacion, incluso cuando la integracion nativa desde la interfaz todavia no este habilitada en tu tenant.

  • Se usa GitHub para ramas, revisiones, issues y acciones automatizadas.
  • Se usa PAC CLI o Power Platform Actions para exportar, empaquetar, desempaquetar y desplegar soluciones.
  • Se recomienda autenticacion con Service Principal y, cuando sea posible, Workload Identity Federation.
  • Es excelente para equipos que ya tienen gobierno, seguridad y aprobaciones en GitHub Enterprise.

Ventajas

Flujos DevSecOps mas flexibles, integracion con acciones, revisiones y politicas corporativas.

Cuando elegirlo

Cuando GitHub es el estandar del area TI o cuando se requiere integracion con flujos existentes de CI/CD.

Modelo mixto recomendado para adopcion gradual

Combina facilidad operativa para makers y disciplina de despliegue para TI.

  1. Conectar desarrollo a Git nativo si el tenant lo permite.
  2. Usar PRs, politicas de ramas y revisiones obligatorias.
  3. Automatizar build y despliegues con GitHub Actions o Azure Pipelines.
  4. Promover a TEST, UAT y PROD solo desde artefactos aprobados.

Concluson

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

Arquitectura objetivo para trabajo eficiente y eficaz

01

Ambientes

Define por lo menos DEV, TEST, UAT y PROD. Todos deben tener gobierno claro; los de desarrollo deben ser administrados.

02

Soluciones

Crea soluciones personalizadas por dominio funcional: por ejemplo GGPI_Proyectos, GGPI_Aprobaciones o Litoclean_Operaciones.

03

Repositorio y ramas

Usa main para estable, develop para integracion y ramas feature/, release/ y hotfix/.

04

Revision

Ningun cambio pasa a la rama principal sin pull request, evidencia funcional, comentario tecnico y aprobacion de responsable.

05

Despliegue

Empaqueta y despliega a TEST, UAT y PROD solo desde el repositorio o desde artefactos de build, nunca desde cambios manuales directos.

Preparacion local

Que necesitas en tu PC para conectarte y trabajar bien

Herramientas base

  • Git for Windows para clonar, crear ramas, hacer commit y revisar historial.
  • Visual Studio Code para editar archivos, revisar diffs y usar extensiones.
  • Power Platform CLI para autenticacion, exportacion, pack, unpack e importacion.
  • Node.js si el proyecto usa PCF o automatizaciones de frontend.
  • .NET segun la version requerida por PAC CLI si se instala como .NET Tool.

Comprobaciones utiles

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"

Si vas a usar la integracion nativa

  1. Confirma que el ambiente sea Managed Environment.
  2. Ingresa con un usuario con rol System Administrator.
  3. Ve a Solutions y elige Connect to Git.
  4. Selecciona tipo de conexion: Environment o Solution.
  5. Selecciona organizacion, proyecto, repositorio, rama y carpeta.
  6. Valida en Source control que ya puedas ver cambios, actualizaciones y conflictos.

Si vas a trabajar con GitHub desde tu PC

  1. Crea o clona el repositorio.
  2. Autenticate con Power Platform usando pac auth create.
  3. Exporta o sincroniza la solucion para llevarla a archivos versionables.
  4. Haz cambios locales, revisa diferencias y crea commits pequenos y claros.
  5. Sube tu rama y abre un pull request con evidencia funcional.
  6. Despliega mediante flujo automatizado o pipeline aprobado.

Ejemplos utiles

Comandos y estructuras de referencia

Flujo Git local para una mejora

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

Convencion de ramas sugerida

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 de workflow para GitHub Actions

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

Modelo de equipo recomendado

Rol maker funcional

Propone y valida requerimientos, ajusta componentes low-code en soluciones controladas y documenta evidencia de negocio.

Rol tecnico o desarrollador

Gestiona repositorio, pipelines, ramas, code review, componentes PCF, plug-ins, scripts y controles de calidad.

Rol lider GGPI

Aprueba criterios de paso, prioriza backlog, decide salidas a UAT y produccion, y vela por trazabilidad y gobierno.

Normas operativas recomendadas

  • Commits pequenos, con mensaje claro y relacion directa con un requerimiento o incidencia.
  • Pull request obligatorio para integrar a develop o main.
  • Revisar conflictos y ejecutar pull antes de commit cuando se usa integracion nativa.
  • Documentar variables de entorno, referencias de conexion y dependencias.
  • No hacer cambios manuales en TEST, UAT o PROD.
  • Todo cambio debe tener responsable, fecha, evidencia y plan de reversa.

Casos de uso

Aplicacion practica para Litoclean Peru y la GGPI

Caso 1. Gestion de solicitudes de proyecto

Objetivo: controlar formularios, aprobaciones y trazabilidad de iniciativas internas.

  • Power App para registrar solicitudes.
  • Power Automate para aprobaciones multinivel.
  • Dataverse para centralizar datos y estados.
  • Git para versionar formularios, flujos y cambios de tabla.
  • Pipeline para pasar a TEST y UAT con aprobacion de GGPI.

Caso 2. Automatizacion de mantenimiento operativo

Objetivo: digitalizar inspecciones, incidencias y seguimiento de tareas para operaciones o soporte.

  • Ramas por mejora o incidente.
  • Hotfix para correcciones urgentes.
  • Versionado de cambios en formularios, vistas y flujos.
  • Historial auditable para cumplimiento y mejora continua.

Escenario recomendado para la GGPI

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

Que no debes hacer

Trabajar directo en produccion

Rompe trazabilidad, complica rollback y hace imposible una disciplina ALM madura.

Usar la Default Solution

Genera desorden, dificulta el versionado y no es el enfoque recomendado para equipos.

Subir binarios como fuente principal

En componentes code-first, el codigo fuente debe ser la verdad; no dependas de DLL o bundles compilados como unica referencia.

Checklist

Lista minima para arrancar bien

Recursos oficiales

Documentacion que conviene revisar