Automatizzare le distribuzioni con l'integrazione e le pipeline Git di Dataverse in Power Platform

Man mano che l'adozione di Power Platform aumenta, le organizzazioni spesso faticano a mantenere un modello di sviluppo coerente e governato in più produttori, sviluppatori e ambienti. Le sfide comuni includono ambienti di sviluppo condivisi, tracciabilità limitata delle modifiche, documentazione di rilascio incoerente e difficoltà nell'applicazione dei controlli del ciclo di vita dello sviluppo software standard nei team di distribuzione a basso codice. Queste sfide aumentano il rischio di distribuzione, la collaborazione lenta e rendono più difficile il supporto delle attività di controllo e conformità.

Questa architettura di riferimento risolve questi problemi combinando l'integrazione nativa di Dataverse Git con le pipeline in Power Platform, la governance Azure DevOps e la generazione di note sulla versione assistita dall'intelligenza artificiale per creare un modello alm (Enterprise Application Lifecycle Management) ripetibile.

Tip

Questo articolo fornisce uno scenario di esempio e un'architettura di esempio generalizzata per illustrare come usare l'integrazione git di Dataverse, le pipeline in Power Platform e Copilot Studio per automatizzare le distribuzioni e generare note correlate. L'esempio di architettura può essere modificato per molti scenari e settori diversi.

Diagramma dell'architettura

Diagramma della strategia ALM di Dataverse con l'integrazione git tra ambienti di sviluppo, test e produzione usando pipeline in Power Platform.

Flusso di lavoro

I passaggi seguenti descrivono i flussi di lavoro di sviluppo, test, produzione e hotfix illustrati nel diagramma dell'architettura.

Flusso di lavoro di sviluppo e controllo del codice sorgente

I creatori e gli sviluppatori usano uno dei diversi ambienti di sviluppo dataverse per apportare modifiche. Oltre a un ambiente di sviluppo primario, i team possono usare altri ambienti, ad esempio per gli sviluppatori junior, le risorse esterne, il lavoro in corso per le iniziative a esecuzione prolungata o per altri lavori che i team non devono promuovere automaticamente al percorso di produzione principale.

  1. Associa ogni flusso di sviluppo a un ambiente Git o a un branch di funzionalità.

  2. Sincronizzare le modifiche in Git tramite l'integrazione di Dataverse Git.

  3. Esaminare i rami di funzionalità e unirli al ramo principale di Git usando le pull request e i criteri di protezione dei rami quando sono pronti per essere inviati al percorso ALM di test per la produzione.

  4. Per evitare il disallineamento delle funzionalità, integrare nei rami corrispondenti a tutti gli ambienti di sviluppo le modifiche accettate nel ramo principale.

  5. Assicurati che il ramo principale diventi l'origine autorevole per l'integrazione e la promozione del rilascio.

Flusso di lavoro di test e convalida

  1. Dal ramo principale usa un host di pipeline personalizzato per alzare di livello la soluzione pronta all'uso nell'ambiente di test direttamente dal codice sorgente nel ramo principale usando il tipo di distribuzione Controllo del codice sorgente.

  2. Usare l'ambiente di test per la convalida tecnica, i controlli di integrazione e i test di fumo.

  3. Dopo la convalida, alzare di livello la soluzione all'ambiente UAT (User Acceptance Test) usando le pipeline in Power Platform. Creare o aggiornare il ramo di versione corrispondente in Git dal ramo principale.

  4. Genera note di rilascio dagli elementi di lavoro in DevOps con stato UAT e distribuiscile ai tester responsabili dell'UAT. Usa un agente di Copilot Studio per generare e formattare queste note sulla versione utilizzando l'azione del connettore Ottieni risultati delle query Azure DevOps.

  5. Assicurarsi che l'UAT supporti la validazione aziendale e le verifiche di prontezza al rilascio prima dell'approvazione per la messa in produzione.

Flusso di lavoro della versione di produzione

  1. Promuovi le modifiche UAT approvate all'ambiente di produzione usando le pipeline in Power Platform.

  2. Genera nuovamente le note di rilascio dagli elementi di lavoro di DevOps in base allo stato per una comunicazione di rilascio standardizzata.

  3. Distribuire le note sulla versione agli stakeholder tecnici e aziendali tramite canali approvati, ad esempio Teams, Outlook o SharePoint.

Flusso di lavoro hotfix

  1. Risolvere i problemi di produzione urgenti in un ambiente hotfix dedicato.

  2. Connetti gli ambienti di hotfix al ramo Git di rilascio della produzione corrente tramite l'integrazione Git di Dataverse.

  3. Promuovi gli hotfix convalidati in produzione attraverso lo stesso meccanismo di pipeline controllata.

  4. Unisci le modifiche dell'hotfix dal ramo di rilascio al ramo principale per assicurarti che siano mantenute intatte nelle versioni future.

Components

I componenti seguenti supportano il controllo del codice sorgente, la promozione dell'ambiente, la governance e la comunicazione di rilascio in questa architettura.

Integrazione di Git in Power Platform

Ruolo nell'architettura:Integrazione Git di Microsoft Dataverse sincronizza le modifiche alle soluzioni da e verso gli ambienti di sviluppo in un sistema di controllo del codice sorgente basato su Git.

Perché è stato scelto:

  • Abilita ALM basato sul codice sorgente per i componenti della soluzione Dataverse
  • Supporta la collaborazione team basata su rami
  • Riduce l'esportazione manuale e la gestione delle importazioni

Azure Repos, rami ed elementi di lavoro

Role nell'architettura:Azure DevOps ospita rami principali, funzionalità e rilascio e applica la governance delle richieste pull. Archivia anche gli elementi di lavoro e funge da origine strutturata per l'ambito di rilascio e i riepiloghi delle modifiche.

Perché è stato scelto:

  • Include controlli avanzati dei criteri aziendali, ad esempio approvazioni pull, protezione dei rami e audit trail
  • Abilita l'allineamento nativo con gli elementi di lavoro e le procedure di governance delle versioni
  • Fornisce una definizione coerente dell'ambito di rilascio
  • Supporta il filtro automatizzato degli elementi pronti per il rilascio
  • Migliora la tracciabilità tra le modifiche al codice e il contenuto di rilascio comunicato

Alternative considerate: GitHub per i repository di codice e gli elementi di lavoro del progetto

Quando questa architettura favorisce Azure DevOps:
Anche se i progetti GitHub possono fornire un monitoraggio flessibile del lavoro, ad esempio campi personalizzati, visualizzazioni della roadmap e automazione, questa architettura include Azure Boards come origine autorevole degli elementi di lavoro della versione. Azure Boards attualmente offre funzionalità di modellazione avanzata dei processi di lavoro aziendali, query condivise e definizione dell'ambito della versione basata su WIQL (Work Item Query Language) e tracciabilità avanzata di sviluppo e distribuzione predefinita per le operazioni di rilascio regolamentate.

Pipeline in Power Platform

Ruolo nell'architettura:Pipeline in Power Platform promuove le soluzioni in tutti gli ambienti, inclusi i percorsi di innalzamento di livello degli hotfix.

Perché è stato scelto:

  • Esperienza di distribuzione nativa di Power Platform
  • Orchestrazione della distribuzione compatibile con l'ambiente
  • Accessibile sia agli amministratori della piattaforma che ai team della soluzione

Alternative considerate:

Perché questa architettura favorisce le pipeline in Power Platform:
Questa architettura usa le pipeline in Power Platform come meccanismo principale di promozione dell'ambiente. Riducono la complessità della configurazione e i requisiti di conoscenza specializzati per l'integrazione continua/distribuzione continua (CI/CD), offrendo al tempo stesso un'esperienza di distribuzione nativa e regolamentata per creatori, amministratori e sviluppatori professionisti.

Microsoft Copilot Studio

Ruolo nell'architettura: Un agente di Copilot Studio per le note di rilascio genera note di rilascio standardizzate a partire dagli elementi di lavoro approvati e dal contesto di rilascio.

Perché è stato scelto:

  • Riduce l'impegno necessario per la documentazione manuale delle release
  • Migliora la coerenza e la leggibilità delle comunicazioni di rilascio
  • Supporta gruppi di destinatari doppi (stakeholder aziendali e tecnici)

Alternative considerate:

  • Creazione manuale nelle pagine di posta elettronica o wiki
  • Solo automazione basata su modelli, non AI

Perché questa architettura include l'intelligenza artificiale:
Dimostra un potenziamento pratico e a basso rischio dell'IA generativa all'interno di un processo operativo ad alto valore, con una chiara supervisione umana e una chiara attribuzione di responsabilità. È più flessibile modificare gruppi di destinatari, progetti e percorsi di distribuzione rispetto all'automazione rigida.

Dettagli dello scenario

L'architettura è particolarmente utile per le organizzazioni che devono supportare più ambienti di sviluppo che lavorano in parallelo (DEV1, DEV2, DEVn) mantenendo al tempo stesso un'origine di verità condivisa e regolamentata in Git. Ogni sviluppatore o piccolo team può lavorare in un ambiente isolato e sincronizzare le modifiche tramite flussi di lavoro basati su rami, consentendo ai team di collaborare senza basarsi su un singolo ambiente di sviluppo condiviso.

Valore aziendale

Il valore chiave fornito da questa architettura include:

  • Controllo del codice sorgente come origine della verità per le personalizzazioni della soluzione, invece di considerare un ambiente maker come origine di distribuzione autorevole. Questo approccio migliora la coerenza e supporta l'innalzamento di livello controllato in ambienti downstream.

  • Sicurezza, controllo e conformità tramite procedure consigliate sdlC (Software Development Lifecycle), tra cui il controllo della versione, le revisioni del codice, la tracciabilità delle modifiche e l'integrazione con i processi di governance aziendale.

  • Sviluppo parallelo su larga scala utilizzando branch e ambienti di sviluppo isolati, consentendo a più collaboratori di sviluppare e iterare simultaneamente con un rischio ridotto di conflitti.

  • Supporto per ambienti di sviluppo di breve durata, che consente ai team di ricreare gli ambienti dal sistema di controllo del codice sorgente per scenari di test, sperimentazione e sviluppo temporaneo, riducendo al contempo la proliferazione degli ambienti a lungo termine.

  • Produttività del team Fusion, che consente a produttori, sviluppatori e amministratori di collaborare tramite esperienze native di controllo del codice sorgente nel prodotto, ancora allineate alle procedure DevOps aziendali.

  • Protezione operativa e recuperabilità tramite il controllo del codice sorgente, che mantiene la cronologia delle versioni e supporta il ripristino agli stati precedenti quando si verificano modifiche impreviste.

In questa architettura, l'agente AI per le note di rilascio estende ulteriormente questo valore migliorando la comunicazione operativa e la trasparenza del rilascio. Trasforma gli elementi di lavoro di DevOps approvati in note di rilascio standardizzate e facili da consultare per gli stakeholder, riducendo il lavoro manuale e preservando al contempo la revisione e la responsabilità umane.

Considerazioni

Queste considerazioni implementano i pilastri di Power Platform Well-Architected, un insieme di principi guida che migliorano la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Power Platform Well-Architected.

Reliability

Questa architettura migliora l'affidabilità implementando percorsi di promozione controllati e gestione del rilascio compatibile con i rami. Questo approccio riduce il rischio di errore di distribuzione e supporta la recuperabilità durante scenari di supporto di produzione urgenti.

  • Avanzamento della distribuzione standardizzato dallo sviluppo al test all'ambiente di produzione
  • Percorso hotfix dedicato con tracciabilità del ramo di rilascio
  • Meccanismi di pipeline riutilizzabili anziché distribuzioni manuali
  • Controlli di validazione prima della promozione in produzione

Security

Questa architettura applica la sicurezza tramite privilegi minimi, separazione dei ruoli e identità di automazione controllate. Questo approccio riduce il rischio di modifiche non autorizzate e migliora la responsabilità delle modifiche.

  • Controllo degli accessi in base al ruolo in ambienti Power Platform e Azure DevOps
  • Entità servizio o identità gestite per l'esecuzione della pipeline
  • Autorizzazioni di distribuzione di produzione con restrizioni
  • Attività di unione e rilascio di rami controllabili
  • Canali approvati per la distribuzione delle note di rilascio

Eccellenza operativa

Questa architettura assegna punteggi elevati per l'eccellenza operativa. Un modello di gestione delle versioni ripetibile e scalabile migliora l'eccellenza operativa e supporta la distribuzione regolamentata in più team e ambienti.

  • Strategia di ramo codificato (funzionalità, main, release)
  • Processo di promozione dell'ambiente ripetibile
  • Modello di gestione degli hotfix standardizzati
  • Generazione automatica delle note sulla versione integrata nel flusso di lavoro di rilascio
  • Riduzione della dipendenza dalla conoscenza tribale per la comunicazione di rilascio

Efficienza prestazionale

Questa architettura ottimizza l'efficienza del processo di distribuzione più delle prestazioni dell'applicazione in fase di esecuzione, il che è appropriato per un'architettura di riferimento ALM. Supportando flussi di sviluppo paralleli e riducendo il coordinamento manuale tra le attività di rilascio, aumenta la velocità effettiva per il recapito delle modifiche riducendo al tempo stesso lo sforzo operativo per ogni rilascio.

  • Distribuzione automatizzata e comunicazione di rilascio
  • Riduzione del sovraccarico di coordinamento manuale
  • Flusso di lavoro standardizzato per cicli di rilascio più veloci
  • Ridimensionamento a flussi paralleli DEVn senza riprogettare la governance

Ottimizzazione dell'esperienza

Questa architettura supporta un processo di rilascio prevedibile e ben definito tra ambienti di sviluppo, test e produzione, migliorando la collaborazione tra produttori, sviluppatori, responsabili del rilascio e team di supporto.

  • Flussi di lavoro allineati al ruolo
  • Modello di promozione prevedibile
  • Formato e tempistiche delle note di rilascio coerenti
  • Ambiguità ridotta al minimo nei passaggi di consegne tra team

L'esperienza è migliorata per più gruppi di utenti:

  • Sviluppatori e autori tramite flussi di lavoro chiari di ambiente e ramo
  • Responsabili del rilascio attraverso promozioni e tracciabilità standardizzate
  • Stakeholder aziendali tramite riepiloghi di rilascio basati su intelligenza artificiale leggibili
  • Team di supporto attraverso una procedura definita per gli hotfix

Intelligenza artificiale responsabile

  • Equità: la funzionalità di intelligenza artificiale riepiloga gli elementi di lavoro di versione approvati. Non prendere decisioni relative al personale, determinare l'idoneità o prendere decisioni che influiscono sui clienti.

  • Affidabilità e sicurezza: i revisori umani controllano il contenuto prima della distribuzione.

  • Privacy e sicurezza: l'agente elabora solo i metadati di rilascio aziendali che rientrano nell'ambito previsto, ad esempio elementi di lavoro approvati e contesto di rilascio. Seguite i criteri di governance dei dati e dei connettori dell'organizzazione per la gestione dei dati sensibili.

  • Inclusività: l'output generato supporta gruppi di destinatari tecnici e non tecnici con sezioni strutturate e riepiloghi in linguaggio normale.

  • Trasparenza: etichetta le note di rilascio come assistite dall'IA e collega la fonte attendibile revisionata agli effettivi elementi di lavoro di origine in DevOps.

  • Responsabilità finale: un responsabile della release designato o un responsabile dell’approvazione della distribuzione mantiene la responsabilità finale in merito al contenuto definitivo della release e alle decisioni sulla distribuzione in produzione.

Passaggi successivi

  1. Connettere gli ambienti di sviluppo dataverse a un repository Git.
  2. Pianificare la struttura e la strategia dell'organizzazione Azure DevOps.
  3. Recuperare gli elementi di lavoro da DevOps con Copilot Studio utilizzando i connettori come strumenti.

Contributori

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autori principali: