Pianificazione di processi di compilazione, test e controllo di qualità
Questa unità prende in esame i processi di sviluppo che è possibile usare per gestire i processi di compilazione, test e controllo di qualità. Fornisce inoltre informazioni sulla pianificazione della gestione di questi processi.
Creazione di un piano di progetto per compilazioni
A seconda della metodologia scelta, è necessario selezionare tempi e luoghi per le compilazioni. È inoltre necessario stabilire l'ordine delle compilazioni. Ad esempio, non si compila il codice dall'ambiente di sviluppo all'ambiente di produzione senza prima passare per l'ambiente di test.
È inoltre necessario considerare come gestire lo sviluppo che non supera i test per poter eseguirne il rollback. Questo approccio impedisce la predisposizione agli errori. È possibile usare Microsoft Dynamics 365 Lifecycle Services per gestire la compilazione da un ambiente a un altro.
Ad esempio, una compilazione può eseguire il rollback di qualsiasi codice con errori dall'ambiente di test all'ambiente di sviluppo, promuovere il codice corretto dall'ambiente di test all'ambiente di produzione e infine promuovere il codice finito dall'ambiente di sviluppo a quello di test.
Scelta degli ambienti necessari
Pianificare la scelta degli ambienti all'inizio dell'implementazione. Quando si pianificano gli ambienti è necessario:
- Decidere lo scopo dell'ambiente. Decidere se destinare gli ambienti allo sviluppo, ai test di sistema, ai test di accettazione utente o alle operazioni.
- Considerare la topologia dell'ambiente, come ad esempio Sviluppare o Compilazione e test.
- Considerare il livello dell'ambiente (Livello 1 o Livello 2).
Un ambiente di livello 1 è un ambiente single-box con tutti i componenti installati sullo stesso server. Un ambiente di livello 1 usa Microsoft SQL Server ed è strutturato per massimizzare l'efficienza di sviluppo. Questo livello non è adatto per i test di accettazione utente o i test delle prestazioni.
Un ambiente di livello 2 o superiore è un ambiente multi-box con componenti installati su più server. Anziché Microsoft SQL Server, gli ambienti di livello 2 usano i database SQL di Microsoft Azure. L'architettura in questo ambiente è la stessa dell'ambiente di produzione, ma non usa il ripristino di emergenza. Usare questo ambiente per i test di accettazione utente e i test delle prestazioni.
L'offerta cloud standard per gli ambienti include un ambiente di livello 1 per lo sviluppo e il test, un ambiente di livello 2 per i test di accettazione utente e un ambiente di produzione. Il sistema fornisce questi ambienti in momenti diversi:
- Ambiente di livello 2: durante il processo di installazione.
- Ambiente di sviluppo e test di livello 1: all'inizio della fase di progettazione e al termine della configurazione di Microsoft Azure DevOps.
- Ambiente di produzione: durante la preparazione del sistema di produzione con Microsoft. È necessario richiedere questo ambiente tramite Lifecycle Services.
Se necessario, è anche possibile aggiungere un altro ambiente per gli ambienti di livello 1 e 2. Inoltre, è possibile distribuire gli ambienti di livello 1 come ambienti ospitati nel cloud o come immagini di ambiente. I clienti o i partner gestiscono gli ambienti ospitati nel cloud. L'immagine di ambiente è un ambiente locale che usa un disco rigido virtuale.
È possibile selezionare quali ambienti sono necessari e quando sono necessari. È necessario riepilogare gli elenchi degli ambienti richiesti in una matrice per Microsoft.
È possibile usare il piano ambientale per scegliere il flusso per la compilazione del codice in tutti gli ambienti e per strutturare il processo ALM.
Pianificazione dei test necessari
Durante l'implementazione delle app per la finanza e le operazioni è necessario decidere come testare lo sviluppo per l'approvazione, chi effettuerà il test, quali criteri usare per l'approvazione e come tenere traccia dei test. Per testare il sistema è possibile usare unit test, test di regressione e test delle prestazioni.
Gli unit test sono utili per verificare se una specifica funzionalità è operativa. Non controllano se il nuovo codice influisce sulle funzionalità esistenti nel sistema.
I test di regressione eseguono il controllo di un intero processo per garantire che le funzionalità esistenti siano operative anche nel nuovo sviluppo. Ad esempio, se si apporta una modifica per aggiungere funzionalità correlate ai clienti, è possibile eseguire i test di regressione per assicurarsi che la nuova funzionalità non interferisca con le funzionalità esistenti, ad esempio gli ordini cliente.
Valutare anche la possibilità di eseguire i test delle prestazioni del sistema per accertarne la stabilità. A tale scopo, più utenti devono accedere al sistema ed eseguire volumi elevati di processi fiscali. Questo approccio è utile per identificare opportunità per migliorare le prestazioni.
Le app per la finanza e le operazioni includono lo strumento Registrazione attività per documentare i passaggi di un processo eseguito da un utente. Con Microsoft Azure DevOps è possibile collegare attività a una soluzione del progetto di sviluppo. È quindi possibile usare l'attività per tenere traccia di aggiornamenti, documenti di test e altre note.
Controllo del codice sorgente e controllo di qualità per gli sviluppatori
A volte accade che più sviluppatori lavorino contemporaneamente nelle app per la finanza e le operazioni. Per evitare che gli sviluppatori interferiscano gli uni con gli altri, è possibile impostare il controllo del codice sorgente con un progetto Azure DevOps.
Il progetto Azure DevOps ospita il codice sorgente del modello che consente agli utenti di eseguire l'estrazione e l'archiviazione degli oggetti. Quando si estrae un oggetto, si comunica al sistema che si stanno apportando modifiche. Quando si esegue l'archiviazione dell'oggetto, il sistema crea una nuova versione di quell'oggetto.
Il controllo della versione consente di visualizzare le modifiche precedenti apportate da altri. È possibile annullare le modifiche in sospeso e impostare le modifiche archiviate più recenti. È inoltre possibile selezionare Più recente per gli oggetti per estrarre la versione archiviata più recente dell'oggetto. Gli sviluppatori dovrebbero usare regolarmente questa funzione per assicurarsi di lavorare con il codice più aggiornato.
Per garantire la qualità dello sviluppo, seguire le procedure consigliate di Microsoft Dynamics 365 X++. È anche possibile sviluppare proprie procedure consigliate, ad esempio le convenzioni di denominazione, per mantenere tutto lo sviluppo standardizzato all'interno dell'organizzazione.
Selezione di un sistema di controllo della versione
Nelle app per la finanza e le operazioni è obbligatorio un sistema di controllo della versione. Azure DevOps supporta sia il controllo della versione di Team Foundation sia Git.
Controllo della versione di Team Foundation di Azure DevOps
Il sistema di controllo della versione di Team Foundation di Azure DevOps è destinato alle app per la finanza e le operazioni. È un sistema di controllo della versione centralizzato, ovvero gli sviluppatori lavorano in un unico ramo e hanno una sola versione di ogni file sui loro computer di sviluppo. Ogni ramo appartiene a un'area di lavoro del server e ogni sviluppatore lavora in un'area di lavoro locale. Quando uno sviluppatore archivia il codice sorgente, deve assicurarsi di archiviare la versione più recente e risolvere i conflitti esistenti.
Per impostazione predefinita, i repository del controllo della versione di Team Foundation sono disattivati nell'area Impostazioni organizzazione di Azure DevOps. È necessario attivare i repository prima di poter creare un nuovo progetto di Azure DevOps come sistema di controllo della versione.
Per attivare il controllo della versione di Team Foundation nell'organizzazione, effettuare i passaggi seguenti:
- Aprire Azure DevOps andando a dev.azure.com/<propria organizzazione>.
- Selezionare Impostazioni organizzazione nell'angolo inferiore sinistro del dashboard.
- Aprire Repos > Repository.
- Disattivare l'interruttore Disabilita creazione repository controllo della versione di Team Foundation nella sezione Tutte le impostazioni repository.
È possibile creare nuovi progetti Azure DevOps usando il controllo della versione di Team Foundation come sistema di controllo della versione.
Git
Git è il sistema di controllo della versione predefinito di Microsoft consigliato per lo sviluppo.
Mentre il controllo della versione di Team Foundation è un sistema di controllo della versione centralizzato, Git è un sistema distribuito. Ogni sviluppatore ha la propria copia di un repository di origine (o ramo leggero) in cui può eseguire il commit di modifiche. Gli sviluppatori possono creare nuovi rami privati e passare da un ramo all'altro. Nel controllo della versione di Team Foundation è più difficile passare da un ramo all'altro e spesso richiede più ambienti di sviluppo.
È importante notare che è possibile eseguire la migrazione dal controllo della versione di Team Foundation a Git e viceversa.