Introduzione
Il caso d'uso per il proprio connettore personalizzato determinerà in che modo si desidera gestire il ciclo di vita nel corso della sua evoluzione. Di seguito sono riportati gli scenari principali e una panoramica generale:
Utilizzo di un unico ambiente: questo scenario viene comunemente usato per le app di produttività create e usate nello stesso ambiente. In questo scenario non è importante poter spostare l'app tra ambienti diversi o condividerla con altre persone esterne all'azienda. Occorre invece gestire le modifiche che causano un'interruzione e seguire alcune linee guida per l'aggiornamento del controllo delle versioni. L'adozione di alcune soluzioni consentirà un eventuale trasferimento futuro dell'app in altri ambienti. In genere, per questo scenario non viene implementato un processo di gestione ALM (Application Lifecycle Management) formale.
Utilizzo di più ambienti: questo scenario riguarda i casi in cui si vuole installare il connettore privatamente in più ambienti e non si intende creare una versione open source o certificare il connettore. Il connettore deve essere creato e gestito nel contesto di una soluzione, che rappresenta il meccanismo principale per la copia dei connettori personalizzati tra gli ambienti. Il connettore potrà sfruttare tutti gli aspetti della gestione del ciclo di vita del framework della soluzione. Per tenere traccia delle modifiche nel connettore, è possibile usare il controllo delle versioni dei componenti della soluzione.
Open source/certificazione: questo scenario riguarda la creazione di un connettore open source o la certificazione del connettore per renderlo disponibile pubblicamente affinché altri possano installarlo o usarlo. In questo scenario si gestiscono i singoli file che compongono la definizione del connettore e si usa lo strumento da riga di comando di Microsoft Power Platform per l'importazione e l'esportazione. Poiché la pubblicazione di questi connettori richiede l'acquisizione dei singoli file di definizione e di altri metadati, di solito non si usa una soluzione, ma il controllo del codice sorgente per i file esportati.
Questo modulo spiega nel dettaglio come gestire questi diversi scenari usando gli strumenti e le funzionalità della piattaforma.
Application Lifecycle Management
La ALM (Application Lifecycle Management) riguarda i componenti che costituiscono un'applicazione completa, inclusi governance, sviluppo e manutenzione, nonché gli aspetti seguenti:
- Gestione dei requisiti
- Architettura
- Sviluppo
- Test
- Manutenzione
- Gestione delle modifiche
- Integrazione continua
- Gestione di progetto
- Distribuzione
- Gestione del rilascio
Il ciclo di vita dell'applicazione è un processo di sviluppo ciclico che coinvolge queste aree: pianificazione e tracciamento, sviluppo, creazione e test, distribuzione, operazioni, monitoraggio e apprendimento dall'individuazione.
Quando si crea un connettore open source e/o si certifica un connettore personalizzato, la fase di distribuzione non si limita allo spostamento in un altro ambiente. È necessario seguire una serie di procedure ben definita, descritta in dettaglio nelle istruzioni su come inviare il connettore a Microsoft.
ALM in Microsoft Power Platform
Microsoft Power Platform fornisce strumenti ALM per supportare un processo di gestione del ciclo di vita sano ed efficace. Questi strumenti si basano su Microsoft Dataverse e sulle soluzioni. Le soluzioni sono meccanismi per l'implementazione di ALM in Microsoft Power Apps e Microsoft Power Automate. Le soluzioni consentono di creare connettori personalizzati e di trasportarli tra i vari ambienti.
Un aspetto chiave della gestione ALM in Microsoft Power Platform è l'uso degli ambienti per scopi specifici durante le diverse fasi del ciclo di vita. Ad esempio, in un'impostazione ALM di base sono presenti ambienti di sviluppo, test e produzione. Per altre informazioni, vedere Strategia ambientale per ALM.
Un altro aspetto chiave di ALM è l'applicazione del controllo del codice sorgente per tenere traccia delle modifiche apportate a ciascuna versione del connettore personalizzato o di altri componenti. Usando gli strumenti di compilazione Microsoft Power Platform è possibile automatizzare il processo di acquisizione di uno snapshot di una soluzione che contiene il connettore e dell'uso del controllo delle versioni per tenere traccia delle modifiche a ogni revisione.
Più avanti in questo modulo si forniranno altre informazioni sull'uso delle soluzioni e degli strumenti di compilazione.
ALM per open source/certificazione
Quando si crea un connettore open source e/o si certifica un connettore personalizzato, in genere si usa un processo ALM predefinito che coinvolge il repository GitHub dei connettori di Microsoft Power Platform. Sebbene sia possibile creare una soluzione open source per qualsiasi posizione pubblica, ad esempio un proprio repository GitHub pubblico o un percorso di download, si consiglia di usare il repository GitHub dei connettori di Microsoft Power Platform per i vantaggi specifici che offre, come la visibilità e la facilità di importazione.
Sebbene sia possibile usare ALM anche con gli approcci e gli strumenti Microsoft Power Platform, oltre che con l'interfaccia della riga di comando e GitHub, questa scelta non semplifica il processo, né aggiunge un valore significativo se l'obiettivo è creare un connettore open source e/o ottenere una certificazione.