Definizione della gestione del ciclo di vita dell'applicazione

Completato

La maggior parte dei progetti avrà un piano e un team di controllo qualità completi. Tuttavia, ogni membro del team di creatori deve partecipare al processo per garantire soluzioni di qualità. Dagli unit test alla configurazione delle pipeline di rilascio con Azure DevOps, vi sono molti punti in un progetto in cui è possibile dare il proprio contributo per garantirne il successo.

Application Lifecycle Management (ALM)

A livello generale, l'architetto di soluzioni, o un tecnico DevOps, sarà responsabile del processo ALM. Tuttavia, è necessario anche il coinvolgimento del consulente funzionale sotto la loro direzione, in quanto membro chiave del team di creatori. Per avere successo, è necessario comprendere e seguire i processi ALM definiti dall'architetto di soluzioni (o dal tecnico DevOps). Porre domande, offrirsi di documentare il piano e ottenere la conferma di ciò che si è compreso. Mentre si crea questa documentazione, si apprenderà di più sui piani ALM per il progetto.

Durante la creazione, si convaliderà il proprio lavoro utilizzando gli strumenti della piattaforma quali Verifica app, Verifica flusso e Verifica soluzione.

Tutto il proprio lavoro verrà svolto nel contesto di una soluzione e sarà necessario comprendere come creare, esportare e importare le soluzioni, secondo le istruzioni dell'architetto di soluzioni. Per i progetti più grandi, probabilmente saranno presenti pipeline di compilazione più formalizzate e distribuzione continua automatizzata.

Strumento per la creazione di pacchetti di soluzioni

È necessario usare lo strumento per la creazione di pacchetti di soluzioni per prendere la soluzione non gestita dalla fase di sviluppo e prepararla per l'archiviazione in un repository del controllo del codice sorgente. Lo strumento per la creazione di pacchetti di soluzioni prende il file unico della soluzione e lo suddivide in singoli file che rappresentano ciascun componente della soluzione. Questo processo dello strumento per la creazione di pacchetti di soluzioni è denominato decompressione della soluzione. L'output dello strumento per la creazione di pacchetti di soluzioni viene quindi archiviato nel repository di controllo del codice sorgente. Questa versione di output archiviata rappresenta ora la fonte attendibile per il progetto.

Lo strumento per la creazione di pacchetti di soluzioni consente anche di comprimere la cartella dal controllo del codice sorgente, ricreando il file unico della soluzione. I file archiviati nel controllo del codice sorgente vengono quindi utilizzati per creare le soluzioni che verranno importate negli altri ambienti. Sebbene lo strumento per la creazione di pacchetti di soluzioni possa essere eseguito manualmente in modo autonomo, più comunemente viene eseguito usando Microsoft Power Platform Build Tools come parte di una pipeline automatizzata.

Package Deployer

Package Deployer consente di creare un pacchetto che include più soluzioni, i dati dallo strumento di migrazione della configurazione e la logica del codice dello sviluppatore che viene eseguita prima e dopo il completamento dell'importazione del pacchetto. Per molti aspetti, Package Deployer può essere considerato come una procedura guidata di installazione di Microsoft Power Platform. Package Deployer può essere eseguito in modo interattivo per importare manualmente pacchetti e dati in un ambiente. Package Deployer supporta anche l'esecuzione tramite PowerShell, che consente l'automazione e l'integrazione in Azure Pipelines.

Verifica soluzione

Power Automate e Power Apps consentono di personalizzare la distribuzione e ciascuno offre i propri strumenti di verifica app in linea, utili per la risoluzione dei problemi in tempo reale. Tuttavia, Verifica soluzione (ulteriori dettagli sono disponibili qui) consente di esaminare l'intera soluzione, eseguire analisi statiche e produrre un elenco dettagliato dei problemi riscontrati.

È opportuno eseguire Verifica soluzione regolarmente su qualsiasi soluzione non gestita durante la compilazione negli ambienti di sviluppo. Verifica soluzione può analizzare i flussi di Power Apps e Power Automate, nonché asset del codice quali i plug-in creati dagli sviluppatori. Il team di progetto può eseguire manualmente la verifica della soluzione dal portale per i creatori selezionando la soluzione e quindi eseguendo la verifica. È anche possibile automatizzare l'esecuzione di Verifica soluzione come parte di un processo di compilazione tramite le attività di PowerShell o Azure Pipeline. Automatizzandone l'esecuzione, Verifica soluzione può diventare parte integrante del processo di compilazione e può anche essere impostata per interrompere la compilazione se sono presenti troppi errori. Affinché il team abbia successo non è sufficiente la semplice esecuzione di Verifica soluzione, deve anche essere presente un piano per valutare e risolvere regolarmente i problemi identificati.

Automatizzazione della distribuzione

Un'area importante nell'ambito del piano di compilazione consiste nel considerare quale automazione è possibile usare per rendere ripetibile il processo. Sono disponibili molti strumenti, sia offerti da Microsoft che dalla community, che è possibile usare per automatizzare il processo di compilazione. Microsoft sta investendo in Azure DevOps e in un set di attività di Microsoft Power Platform che è possibile usare per automatizzare la gestione della soluzione e le attività di distribuzione. Ad esempio, un team può avere una Azure Pipeline che ogni giorno alle 19.00 estrae la soluzione dall'ambiente di sviluppo e la archivia in un repository Git. La stessa pipeline può essere usata anche per eseguire Verifica soluzione di modo che, ogni mattina, quando il team inizia a lavorare sappia immediatamente se sono stati identificati problemi nella build della notte precedente. La pipeline consente anche di importare la soluzione in un ambiente di compilazione pulito per permettere di rilevare eventuali dipendenze introdotte involontariamente durante lo sviluppo di quel giorno. Questo garantisce che nel controllo del codice sorgente venga archiviata una versione pulita, pronta per la distribuzione in altri ambienti. Le pipeline possono essere usate anche per automatizzare i test in modo che rappresentino solo un altro passaggio all'interno della pipeline. Azure Pipelines consente anche di produrre l'artefatto della soluzione gestita che verrà usato nelle pipeline di rilascio per la distribuzione negli ambienti upstream, quali gli ambienti di test e produzione. Lo stesso artefatto della soluzione usato nel test viene utilizzato fino alla produzione. Ciò garantisce che non vengano introdotte modifiche impreviste con il procedere da un ambiente all'altro fino alla produzione. Azure Pipelines consente inoltre di creare asset di codice dello sviluppatore per assicurare che non vengano compilati su una workstation di sviluppo locale.

Controllo della versione

Per impostazione predefinita, le modifiche che vengono apportate dall'ambiente di sviluppo all'ambiente di test e all'ambiente di produzione rappresentano un unico flusso di lavoro di modifiche. Se viene identificato un problema nell'ambiente di produzione, lo si corregge nell'ambiente di sviluppo e tale correzione procede lungo la serie di ambienti fino alla produzione. La presenza di un unico flusso di lavoro funziona bene se non viene eseguito alcun nuovo sviluppo. Se il team di sviluppo è già passato alla versione 2 nel proprio ambiente di sviluppo e quindi corregge un bug identificato in produzione, quando la correzione viene spostata alla produzione, viene spostato alla produzione anche tutto il lavoro in corso per la versione 2, perché è tutto insieme. L'azione ideale consiste nell'apportare la modifica in un ambiente di sviluppo di un flusso di lavoro separato che rappresenti solo ciò che è già in produzione, di modo che ciò che viene promosso includa solo la correzione e nessuna parte della versione 2. Ciò richiede che il team di progetto pianifichi anticipatamente una strategia per la gestione di più versioni attive. A tale fine potrebbe semplicemente essere presente un flusso di sviluppo attivo e un flusso di manutenzione per supportare la produzione. I progetti più complessi possono anche avere più flussi di sviluppo attivi in corso contemporaneamente.

Per gestire contemporaneamente flussi di sviluppo e di manutenzione attivi, viene in genere usata una combinazione di ambienti Dataverse e di rami di controllo del codice sorgente. I rami consentono di avere una copia degli asset del progetto e un ambiente associato a ogni ramo in cui apportare modifiche in modo isolato. Le modifiche in un ramo possono essere unite con un altro ramo. La strategia di diramazione dovrebbe essere mantenuta il più semplice possibile per evitare di dover risolvere molti conflitti durante l'unione dei rami.