Considerazioni chiave per ALM

Completato

Gli architetti di soluzioni devono definire la strategia per la gestione del ciclo di vita dell'applicazione (ALM) nel progetto. Questa attività fa parte del processo grazie al quale l'organizzazione stabilisce una governance adeguata per la soluzione.

Strategia ambientale

Un ambiente è un contenitore che archivia, gestisce e condivide i dati aziendali, le app, i flussi, le connessioni e altri asset, nonché le autorizzazioni per consentire ai membri dell'organizzazione di usare le risorse.

Svolge anche la funzione di contenitore per separare le app che possono avere ruoli, requisiti di sicurezza o destinatari diversi. La scelta di come usare gli ambienti dipende dall'organizzazione e dalle app da creare, ad esempio:

  • Le app possono essere create solo in un unico ambiente.
  • Si possono creare ambienti distinti per raggruppare le versioni di test e produzione delle app.
  • È possibile creare ambienti separati che corrispondono a team o reparti specifici dell'azienda, ciascuno con i dati e le app associati a uno specifico gruppo di destinatari.
  • È possibile creare ambienti distinti per le diverse filiali estere dell'azienda.

Sviluppare una strategia ambientale significa configurare gli ambienti e altri livelli di sicurezza dei dati in modo da supportare lo sviluppo produttivo nell'organizzazione, proteggendo e organizzando contemporaneamente le risorse. Una strategia per gestire il provisioning e l'accesso all'ambiente e per controllare le risorse al suo interno è importante per:

  • Proteggere i dati e l'accesso.
  • Comprendere come usare correttamente l'ambiente predefinito.
  • Gestire il numero corretto di ambienti per evitare la proliferazione incontrollata e risparmiare capacità.
  • Semplificare la gestione del ciclo di vita dell'applicazione (ALM).
  • Organizzare le risorse in partizioni logiche.
  • Supportare le operazioni (e l'helpdesk) nell'identificazione delle app in produzione assegnandole ad ambienti dedicati.
  • Verificare che i dati vengano archiviati e trasmessi in aree geografiche accettabili (in termini di prestazioni e conformità).
  • Garantire l'isolamento delle applicazioni in fase di sviluppo.

Diagramma che mostra un esempio di strategia ambientale.

I seguenti tipi di ambienti sono disponibili in Microsoft Power Platform:

  • Sandbox: un ambiente non di produzione di Dataverse. Isolato dalla produzione, un ambiente sandbox consente di sviluppare e testare in modo sicuro e con rischi limitati le modifiche alle applicazioni.
  • Produzione: l'ambiente in cui app e altri software vengono resi operativi per l'uso previsto.
  • Community (sviluppatore): il piano Community di Power Apps consente a un utente di accedere alla funzionalità Power Apps Premium, a Dataverse e a Microsoft Power Automate solo per uso individuale. Questo ambiente è pensato principalmente per scopi di apprendimento. Un ambiente per sviluppatori è destinato a un singolo utente e non può essere usato per eseguire o condividere app. Un ambiente del piano Community può far parte della pipeline di Azure DevOps.
  • Predefinito: un unico ambiente predefinito viene creato automaticamente per ogni tenant e condiviso da tutti gli utenti in quel tenant. L'ambiente predefinito viene usato dai servizi di Microsoft 365.
  • Valutazione: gli ambienti di valutazione servono per provare nuove funzionalità o per eseguire modelli di verifica. Gli ambienti di valutazione vengono eliminati automaticamente dopo 30 giorni.

Importante

L'Architetto di soluzioni deve definire il numero di ambienti richiesto, lo scopo e le dipendenze tra gli ambienti. Una procedura ALM efficace dovrebbe includere almeno il passaggio in un ambiente di test prima di distribuire un elemento nell'ambiente di produzione. questo ambiente offre da un lato un luogo in cui testare l'app e, dall'altro, la garanzia che la distribuzione venga testata.

Per altre informazioni, consultare ambienti e strategia ambientale.

Gestione delle soluzioni e di altro codice e componenti senza riconoscimento della soluzione

I progetti Microsoft Power Platform sono costituiti da componenti che possono essere raggruppati in soluzioni nei vari ambienti e da componenti che non possono essere aggiunti alle soluzioni, ad esempio come componenti distribuiti in Azure, dati di configurazione e report Power BI. Il piano ALM deve considerare come gestire questi componenti senza riconoscimento della soluzione.

L'Architetto di soluzioni deve scegliere se eseguire la gestione del ciclo di vita dell'applicazione con le soluzioni o con il controllo del codice sorgente. I progetti Microsoft Power Platform sono sempre stati più incentrati sull'ambiente, ma ora molti stanno tendendo verso il controllo del codice sorgente.

Se si usa un approccio incentrato sull'ambiente:

  • L'ambiente di sviluppo è la copia master di tutte le modifiche.
  • Le modifiche vengono promosse direttamente da dev > test > produzione.

Se si usa un approccio incentrato sul controllo del codice sorgente:

  • Il controllo del codice sorgente è il master.
  • L'ambiente di sviluppo viene ricreato dal controllo del codice sorgente (questo processo può essere automatizzato e reso ripetibile).
  • Le modifiche apportate dall'ambiente di sviluppo vengono archiviate nel controllo del codice sorgente.

Diagramma che mostra un approccio incentrato sul codice sorgente.

Un approccio incentrato sul controllo del codice sorgente incoraggia l'utente ad avere un master definitivo e la capacità di ricreare ambienti di sviluppo per qualsiasi versione registrata. Attualmente, Microsoft sta promuovendo e creando strumenti per supportare ALM incentrato sul controllo del codice sorgente.

Nota

In teoria, tutti gli ambienti diversi da quello di produzione dovrebbero essere buttati via. In altre parole, gli ambienti di sviluppo e test possono essere eliminati e ricreati senza alcuna perdita.

L'uso di un approccio incentrato sul controllo del codice sorgente consente un approccio Azure DevOps con le pipeline di compilazione e rilascio. L'uso di un approccio incentrato sull'ambiente implica la definizione del flusso di lavoro per i creatori di app e gli sviluppatori. L'Architetto di soluzioni dovrà definire come e chi alzerà di livello l'app nei vari ambienti, dallo sviluppo alla produzione.

L'Architetto di soluzioni dovrà anche definire come configurare ogni ambiente e cercare modi per renderlo più semplice.

Lavoro in team

Rispetto allo sviluppo di app tradizionali, i progetti Microsoft Power Apps differiscono in due aree chiave:

  • Il modo in cui i vari membri del team di progetto lavorano insieme per creare la soluzione
  • La metodologia di sviluppo

Power Apps è una piattaforma pensata per gli sviluppatori professionisti e i citizen developer. In un ambiente di sviluppo tradizionale, solo gli sviluppatori professionisti potrebbero essere coinvolti nella realizzazione effettiva di un'app. Con Power Apps, chiunque può creare le app di cui ha bisogno usando funzionalità avanzate che in precedenza erano disponibili solo per gli sviluppatori professionisti. Power Apps semplifica l'esperienza di creazione di app aziendali personalizzate, consentendo agli utenti di creare app aziendali personalizzate e ricche di funzionalità senza scrivere codice.

Diagramma che mostra l'ecosistema di sviluppo.

Con Power Apps, è possibile creare rapidamente una versione utilizzabile dell'app perché Power Apps fornisce un'esperienza di sviluppo WYSIWYG. Già nelle prime fasi del processo di sviluppo è possibile lavorare sull'app funzionante e, in caso di nuovi requisiti, è possibile aggiungere nuove funzionalità alla versione successiva.

Diagramma dell'approccio allo sviluppo di Power Apps.

Alcuni problemi con la personalizzazione e lo sviluppo di componenti all'interno di Microsoft Power Platform:

  • Microsoft Power Platform non supporta il controllo delle versioni dei componenti (ad eccezione delle app canvas).
  • Gli utenti non possono lavorare sullo stesso componente di Microsoft Power Platform contemporaneamente.
  • Le app basate su modello includono più componenti, ciascuno con i propri editor, che consentono di dividere il lavoro tra i creatori. Le app canvas, invece, hanno un solo editor e solo una persona alla volta può lavorare su un'app. Usando i componenti canvas, più creatori possono lavorare contemporaneamente sulla stessa app.

Gli architetti di soluzioni devono stabilire il flusso di lavoro per definire il modo in cui i creatori di app possono apportare e promuovere le modifiche. È necessario gestire la comunicazione proattiva e le assegnazioni del lavoro per ridurre al minimo i conflitti tra i creatori.

Per ridurre al minimo i conflitti tra i creatori, è possibile impostare un ambiente individuale per ognuno di loro. Questi ambienti individuali offrono l'isolamento e il monitoraggio, ma richiedono uno sforzo aggiuntivo per unire il lavoro e risolvere i conflitti. Un ambiente condiviso da più creatori può essere meno complesso, ma non offre l'isolamento ed è privo di dettagli per il monitoraggio delle modifiche.

Controllo del codice sorgente

Anche se si usa un approccio incentrato sull'ambiente, è comunque necessario decidere dove risiederà la copia master delle soluzioni e del codice.

Gli asset del codice di sviluppo con riconoscimento della soluzione (come plug-in, componenti di codice PCF e script del modulo estratti da TypeScript) dovrebbero essere "costruiti" in un ambiente di compilazione e non sul desktop dello sviluppatore. Dopo la creazione, gli asset dovrebbero essere distribuiti in un ambiente da cui la soluzione master verrà esportata o trasformata nella soluzione da installare.

Strumenti

Microsoft fornisce diversi strumenti e app da usare con ALM in Microsoft Power Platform:

  • Interfaccia di amministrazione di Microsoft Power Platform: fornisce un portale unificato per gli amministratori per creare e gestire gli ambienti.
  • Power Apps build tools: automatizza le attività comuni di compilazione e distribuzione correlate a Power Apps usando Azure DevOps.
  • GitHub: esempio molto usato di un sistema di controllo delle versioni.
  • Strumento Migrazione della configurazione: consente di spostare la configurazione e/o i dati di riferimento tra i vari ambienti.
  • Package Deployer: consente di distribuire i pacchetti di asset alle istanze Dataverse. I pacchetti possono essere costituiti da file della soluzione e file flat, codice personalizzato, file HTML e dati.
  • Strumento per la creazione di pacchetti di soluzioni: strumento per decomprimere un file della soluzione compresso in più file XML e di altro tipo, in modo che possano essere facilmente gestiti da un sistema di controllo del codice sorgente.
  • Microsoft Power Apps CLI: una semplice interfaccia della riga di comando che consente agli sviluppatori di creare i componenti di codice.
  • Modulo PowerShell per la distribuzione dei pacchetti: usato per distribuire i pacchetti nell'ambiente Dataverse.
  • Modulo PowerShell per Verifica di Power Apps: interagisce con il servizio di verifica di Power Apps per eseguire processi di analisi statica e scaricare i risultati.

Nota

Le azioni GitHub per Microsoft Power Platform sono attualmente in anteprima.