Nozioni di base su ALM con Microsoft Power Platform

  • Articolo

Questo articolo descrive i componenti, gli strumenti e i processi necessari per implementare la gestione del ciclo di vita delle applicazioni (ALM).

Ambienti

Gli ambienti sono uno spazio in cui archiviare, gestire e condividere dati aziendali, app e processi aziendali dell'organizzazione. Fungono inoltre da contenitori per separare le app in base ai diversi ruoli, requisiti di sicurezza o destinatari. Ogni ambiente può disporre di un solo database Microsoft Dataverse. Ulteriori informazioni: Panoramica degli ambienti

Importante

Quando si crea un ambiente, è possibile scegliere di installare le app Dynamics 365, come Dynamics 365 Sales e Dynamics 365 Marketing. È importante determinare in quel momento se queste app sono necessarie o meno perché non possono essere disinstallate o installate in un secondo momento. Se non utilizzi queste app e non le richiederai in futuro, ti consigliamo di non installarle nei tuoi ambienti. Ciò contribuirà ad evitare complicazioni di dipendenza quando distribuisci soluzioni tra ambienti.

Tipi di ambienti utilizzati in ALM

Con l'interfaccia di amministrazione di Power Platform, puoi creare questi tipi di ambienti Power Platform:

  • Sandbox Una sandbox ambiente è qualsiasi ambiente non di produzione di Dataverse. Poiché è isolato dalla produzione, un ambiente sandbox è ideale per sviluppare in modo sicuro e testare le modifiche dell'applicazione con basso rischio. Gli ambienti sandbox includono funzionalità che potrebbero essere dannose in un ambiente di produzione, come operazioni di reimpostazione, eliminazione e copia. Ulteriori informazioni: Gestire gli ambienti sandbox

  • Produzione ambiente in cui le app e gli altri software vengono messi in funzione per l'uso previsto.

  • Sviluppatore (formalmente chiamato Community). Il Piano per sviluppatori Power Apps ti dà accesso a funzionalità premium Power Apps, Dataverse, e Power Automate per uso individuale. Questo piano è principalmente pensato per costruire e testare Power Apps, Power Automate, e Microsoft Dataverse o per scopi di apprendimento. Un ambiente di sviluppo è un ambiente per singolo utente e non può essere utilizzato per eseguire o condividere app di produzione.

  • Default Per ogni tenant viene creato automaticamente un singolo ambiente predefinito, che viene condiviso da tutti gli utenti di quel tenant. Il tenant identifica il cliente, al quale può essere associato uno o più abbonamenti e servizi. Microsoft Ogni volta che un nuovo utente si registra per Power Apps, tale utente viene automaticamente aggiunto al ruolo di creatore dell'ambiente predefinito. L'ambiente predefinito viene creato nella regione più vicina alla regione predefinita del tenant Microsoft Entra ed è denominato "{nome del tenant Microsoft Entra} (predefinito)"

Creare e utilizzare l'ambiente corretto per uno scopo specifico, ad esempio sviluppo, test o produzione.

Per altre informazioni sull'utilizzo degli ambienti, vedi Panoramica degli ambienti.

Chi deve avere accesso?

Definisci e gestisci la sicurezza di risorse e dati in Microsoft Dataverse. Microsoft Power Platform fornisce ruoli di amministratore a livello di ambiente per eseguire attività. Dataverse include ruoli di sicurezza che definiscono il livello di accesso ad app, componenti delle app e risorse che i creatori e gli utenti di app dispongono in Dataverse.

ambiente scopo Ruoli che hanno accesso Commenti
Sviluppo Creatori e sviluppatori di app. Gli utenti dell'app non devono avere accesso. Gli sviluppatori richiedono almeno il ruolo di sicurezza Creatore ambiente per creare risorse.
Test Amministratori e persone che eseguono i test. Creatori di app, sviluppatori e utenti di app di produzione non devono avere accesso. Gli utenti dei test devono avere soltanto privilegi sufficienti per eseguire i test.
Produzione Amministratori e utenti delle app. Gli utenti devono avere soltanto l'accesso per eseguire le attività per le app che usano. Creatori e sviluppatori di app non devono avere accesso o devono avere solo privilegi a livello di utente.
Predefinita Per impostazione predefinita, tutti gli utenti del tenant possono creare e modificare app in un ambiente predefinito di Dataverse che ha un database. Raccomandiamo vivamente di creare ambienti per uno scopo specifico e di concedere ruoli e privilegi appropriati solo a coloro che ne hanno bisogno.

Ulteriori informazioni:

Soluzioni

Le soluzioni sono utilizzate per trasferire app e componenti da un ambiente a un altro o per applicare un set di personalizzazioni ad app esistenti.

Le soluzioni hanno queste caratteristiche:

  • Includono metadati e determinate entità con dati di configurazione. Le soluzioni non contengono dati aziendali.

  • Possono contenere molti componenti differenti di Microsoft Power Platform, come app basate su modello, app canvas, mappe del sito, flussi, entità, moduli, connettori personalizzati, risorse Web, set di opzioni, grafici e campi. Nota che non tutte le entità possono essere incluse in una soluzione. Ad esempio, le tabelle di sistema Utente applicazione, API personalizzata e Impostazioni organizzazione non possono essere aggiunte a una soluzione.

  • Sono inserite in un pacchetto come unità da esportare e importare in altri ambienti, oppure decostruiti e controllati nel controllo del codice sorgente come codice sorgente per gli asset. Le soluzioni sono anche utilizzate per applicare le modifiche alle soluzioni esistenti.

  • Soluzioni gestite vengono utilizzate per distribuire in qualsiasi ambiente che non sia un ambiente di sviluppo per quella soluzione. Ciò include test, test di accettazione utente (UAT), test di integrazione del sistema (SIT) e ambienti di produzione. Le soluzioni gestite possono essere gestite (aggiornamento, patch ed eliminazione) indipendentemente dalle altre soluzioni gestite in un ambiente. Come procedura consigliata per ALM, le soluzioni gestite devono essere generate da un server di compilazione e considerate un artefatto di compilazione.

  • Gli aggiornamenti a una soluzione gestita sono distribuiti alla versione precedente della soluzione gestita. Ciò non crea un ulteriore livello di soluzione. Non è possibile eliminare componenti utilizzando un aggiornamento.

  • Una patch contiene solo le modifiche per una soluzione gestita padre. Devi utilizzare le patch solo quando esegui piccoli aggiornamenti (simili a un hotfix) e hai bisogno di poterle eventualmente disinstallare. Quando le patch vengono importate, vengono sovrapposte alla soluzione padre. Non è possibile eliminare componenti utilizzando una patch.

  • L'aggiornamento di una soluzione installa un nuovo livello di soluzione immediatamente sopra il livello di base e tutte le patch esistenti.

    • L'applicazione degli aggiornamenti della soluzione comporta l'eliminazione di tutte le patch esistenti e del livello di base.

    • Gli upgrade delle soluzioni elimineranno i componenti esistenti ma che non sono più inclusi nella versione aggiornata.

Maggiori informazioni: Concetti sulle soluzioni

Controllo del codice sorgente

Il controllo del codice sorgente, noto anche come controllo della versione, è un sistema che gestisce e archivia in modo sicuro gli asset di sviluppo software e tiene traccia delle modifiche a tali asset. Il rilevamento modifiche è particolarmente importante quando più creatori e sviluppatori di app lavorano sullo stesso set di file. Un sistema di controllo del codice sorgente offre anche la possibilità di eseguire il rollback delle modifiche o di ripristinare i file eliminati.

Un sistema di controllo del codice sorgente aiuta le organizzazioni a ottenere una ALM integra poiché gli asset gestiti in tale sistema sono l'"unica fonte attendibile", o, in altre parole, l'unico punto di accesso e modifica per le tue soluzioni.

Strategia di diramazione e unione

Quasi ogni sistema di controllo del codice sorgente ha una qualche forma di supporto per la diramazione e l'unione. Con diramazione si intende divergere dalla linea principale di sviluppo e continuare a svolgere il lavoro senza cambiare la linea principale. Il processo di unione consiste nel combinare un ramo in un altro, ad esempio da un ramo di sviluppo a un ramo di linea principale. Alcune strategie di diramazione comuni sono le diramazioni basate su trunk, le diramazioni di rilascio e le diramazioni di funzionalità. Maggiori informazioni: Adottare una strategia di diramazione Git

Processo di controllo del codice sorgente utilizzando una soluzione

Esistono due percorsi principali che puoi utilizzare quando utilizzi soluzioni in un sistema di controllo del codice sorgente:

  • Esportare la soluzione non gestita e inserirla come decompressa nel sistema di controllo del codice sorgente. Il processo di compilazione importa la soluzione compressa come non gestita in un ambiente di compilazione temporaneo (ambiente sandbox). Quindi, esporta la soluzione come gestita e l'archivia come artefatto di compilazione nel sistema di controllo del codice sorgente.
  • Esporta la soluzione come non gestita e anche come gestita e posiziona entrambe nel sistema di controllo del codice sorgente. Sebbene questo metodo non richieda un ambiente di compilazione, richiede la gestione di due copie di tutti i componenti (una copia di tutti i componenti non gestiti della soluzione non gestita e una copia di tutti i componenti gestiti della soluzione gestita).

Processo di controllo del codice sorgente utilizzando una soluzione.

Ulteriori informazioni: Attività con strumenti di compilazione

Automazione

L'automazione è una parte fondamentale del ciclo di vita dell'applicazione che migliora la produttività, l'affidabilità, la qualità e l'efficienza di ALM. Gli strumenti e le attività di automazione sono utilizzati per convalidare, esportare, comprimere, decomprimere ed esportare soluzioni oltre a creare e ripristinare ambienti sandbox.

Ulteriori informazioni: Cosa sono gli strumenti Microsoft Power Platform Build Tools?

Sviluppo in team utilizzando un controllo del codice sorgente condiviso

È importante considerare come tu e il tuo team di sviluppo lavorerete insieme per creare il progetto. Abbattere le barriere e favorire lo scambio di idee e opinioni può consentire al team di fornire un software migliore. Alcuni strumenti e flussi di lavoro, come quelli forniti in Git, GitHub e Azure DevOps, sono stati progettati con lo scopo esplicito di migliorare la comunicazione e la qualità del software. Nota che lavorare con le configurazioni in un sistema di soluzione può creare sfide per lo sviluppo in team. Le organizzazioni devono orchestrare le modifiche di più sviluppatori per evitare al massimo conflitti di unione, poiché i sistemi di controllo del codice sorgente hanno limitazioni su come avvengono le unioni. Ti consigliamo di evitare situazioni in cui più persone apportano contemporaneamente modifiche a componenti complessi, come moduli, flussi e app canvas.

Maggiori informazioni: Scenario 5: supportare lo sviluppo in team

Integrazione e distribuzione continue

Puoi utilizzare qualsiasi sistema di controllo del codice sorgente e creare una pipeline per un'integrazione continua e una distribuzione continua (CI/CD). Tuttavia, questa guida è incentrata su GitHub e Azure DevOps. GitHub è una piattaforma di sviluppo utilizzata da milioni di sviluppatori. Azure DevOps fornisce servizi di sviluppo a team di supporto per pianificare il lavoro, collaborare allo sviluppo di codice e creare e distribuire applicazioni.

Per iniziare, hai bisogno di quanto segue:

Maggiori informazioni: Creare la prima pipeline

Licenze

Per creare o modificare app e flussi utilizzando rispettivamente Power Apps e Power Automate, gli utenti dovranno disporre di una licenza per utente per Power Apps o Power Automate o di una licenza per applicazione Dynamics 365 appropriata. Per ulteriori informazioni, vedi Panoramica sulle licenze per Microsoft Power Platform. Ti consigliamo inoltre di contattare il tuo rappresentante di account per discutere delle tue esigenze di licenza. Microsoft

Considerazioni su ALM

Se utilizzi ALM come parte integrante della creazione di app in Microsoft Power Platform, puoi migliorare drasticamente velocità, affidabilità e esperienza utente dell'app. Questa soluzione assicura inoltre la possibilità di un contributo congiunto alla creazione dell'applicazione da parte di più sviluppatori, ovvero sviluppatori tradizionali, che scrivono codice, e sviluppatori non professionisti.

Vedi i seguenti articoli che trattano diversi aspetti da considerare all'inizio di qualsiasi sviluppo di applicazioni: