Condividi tramite

Distribuire un modello di verifica per la distribuzione aziendale di Azure DevTest Labs

  • Articolo

Le aziende stanno adottando rapidamente il cloud a causa di vantaggi che includono agilità, flessibilità ed economia. I primi passaggi sono spesso carichi di lavoro di sviluppo e test. Azure DevTest Labs offre funzionalità che traggono vantaggio dall'azienda e supportano gli scenari di sviluppo/test principali.

Questo articolo descrive come un'azienda può fornire un modello di verifica o un progetto pilota efficace per una distribuzione di Azure DevTest Labs. Il modello di verifica usa uno sforzo concentrato da un singolo team per stabilire valore organizzativo.

Ogni azienda ha requisiti diversi per l'incorporazione di Azure DevTest Labs nell'organizzazione. Il modello di verifica è un primo passo verso una distribuzione end-to-end riuscita.

Per un modello di verifica riuscito:

  1. Scegli una o due squadre.
  2. Identificare gli scenari dei team, ad esempio macchine virtuali (VM) per sviluppatori o ambienti di test.
  3. Documentare i casi d'uso correnti.
  4. Distribuire DevTest Labs per soddisfare gli scenari e i casi d'uso dei team.
  5. Valutare il successo e le lezioni apprese.

Gli scenari principali di DevTest Labs includono ambienti di sviluppo, test e training cloud. I casi d'uso includono:

  • Creazione di desktop per sviluppatori.
  • Configurazione degli ambienti di test.
  • Abilitazione dell'accesso alle macchine virtuali e alle risorse di Azure.
  • Configurazione di sandbox per l'apprendimento e la sperimentazione.
  • Configurazione dei criteri del lab e dei controlli dei costi conformi alle normative aziendali.

Prerequisiti

Per completare correttamente un modello di verifica di DevTest Labs, soddisfare i prerequisiti seguenti:

Informazioni di base

Informazioni su Azure e DevTest Labs usando le risorse seguenti:

Comprendere le aree di interesse aziendali

I problemi comuni per le aziende che esegrano i carichi di lavoro nel cloud includono:

Ottenere una sottoscrizione di Azure

  • Le aziende con un Contratto Enterprise esistente che consente l'accesso ad Azure possono usare una sottoscrizione esistente o nuova per DevTest Labs. Se è presente un Contratto Enterprise, una sottoscrizione di sviluppo/test enterprise consente di accedere ai sistemi operativi client Windows 10/Windows 8.1 e tariffe scontate per i carichi di lavoro di sviluppo e test.

  • In alternativa, è possibile usare una sottoscrizione di Visual Studio per la distribuzione pilota e sfruttare i crediti Azure gratuiti.

  • È anche possibile creare e usare un account Azure gratuito per il progetto pilota.

  • Per usare immagini del sistema operativo client Windows (Windows 7 o versioni successive) per attività di sviluppo o test in Azure, eseguire una delle operazioni seguenti:

    Per altre informazioni sui crediti Azure per ogni offerta MSDN, vedere Credito Azure mensile per sottoscrittori di Visual Studio.

Registrare tutti gli utenti in Microsoft Entra ID

Per la gestione, ad esempio l'aggiunta di utenti o l'aggiunta di proprietari di lab, tutti gli utenti del lab devono appartenere al tenant di Microsoft Entra ID per la sottoscrizione di Azure usata dal progetto pilota. Molte aziende configurano l'identità ibrida per consentire agli utenti di usare le identità locali nel cloud. Non è necessaria un'identità ibrida per un modello di verifica di DevTest Labs.

Definire l'ambito del modello di verifica

L'obiettivo del progetto pilota è usare i carichi di lavoro e le dipendenze minimi necessari per decidere se Azure DevTest Labs è adatto all'azienda. Scegliere il carico di lavoro più semplice con le dipendenze più semplici per garantire un esito positivo e rapido. In alternativa, scegliere il carico di lavoro più rappresentativo che espone potenziali complessità, in modo da poter replicare il successo pilota nella fase di scalabilità orizzontale.

Pianificare attentamente il modello di verifica prima di iniziare l'implementazione. Assicurarsi di impostare le aspettative appropriate con gli utenti che le risorse pilota non rimarranno per un periodo illimitato.

Eseguire queste attività per definire l'ambito del progetto pilota:

  • Definire obiettivi e criteri di successo.
  • Elencare un piccolo set di carichi di lavoro o scenari da coprire per il progetto pilota.
  • Determinare le risorse che il lab deve rendere disponibile, ad esempio immagini personalizzate o immagini del Marketplace.
  • Decidere la topologia di rete e i criteri lab.
  • Scegliere gli utenti e i team da coinvolgere nel progetto pilota e verificare i risultati.
  • Decidere la durata del progetto pilota, ad esempio due settimane o un mese.
  • Decidere come eliminare le risorse pilota al termine del progetto pilota.

C'è una tendenza a cercare di rendere perfetto il progetto pilota, quindi rispecchia lo stato finale dopo l'implementazione di DevTest Labs. Tuttavia, cercando di fare il modello di verifica perfetto significa troppo sforzo prima di poter avviare il progetto pilota. Lo scopo del progetto pilota è determinare le decisioni appropriate per aumentare e implementare il servizio finale.

Prendere altre decisioni di pianificazione e progettazione

Una soluzione Completa di DevTest Labs include alcune importanti decisioni di pianificazione e progettazione. Il modello di verifica può essere utile per prendere queste decisioni. Altre considerazioni includono:

Topologia della sottoscrizione

I requisiti a livello aziendale per le risorse in Azure possono estendersi oltre le quote disponibili all'interno di una singola sottoscrizione. Potrebbero essere necessarie diverse sottoscrizioni di Azure oppure potrebbe essere necessario effettuare richieste di servizio per aumentare i limiti iniziali delle sottoscrizioni. Per altre informazioni, vedere Considerazioni sulla scalabilità.

È importante decidere come distribuire le risorse tra le sottoscrizioni prima dell'implementazione finale con scalabilità completa, perché è difficile spostare le risorse in un'altra sottoscrizione in un secondo momento. Ad esempio, non è possibile spostare un lab in un'altra sottoscrizione dopo la creazione. La guida decisionale per la sottoscrizione è una risorsa di pianificazione preziosa.

Topologia di rete

L'infrastruttura di rete predefinita creata automaticamente da DevTest Labs potrebbe non soddisfare requisiti e vincoli per gli utenti aziendali. Ad esempio, le aziende spesso usano:

  • Reti virtuali connesse ad Azure ExpressRoute per la connessione di reti locali ad Azure.
  • Reti virtuali con peering in una configurazione hub-spoke per la connessione di reti virtuali tra sottoscrizioni.
  • Tunneling forzato per limitare il traffico alle reti locali.

Per altre informazioni, vedere Componenti di rete.

DevTest Labs supporta anche l'aggiunta di reti virtuali esistenti al lab da usare per la creazione di nuove macchine virtuali. Per altre informazioni, vedere Aggiungere una rete virtuale in Azure DevTest Labs.

Accesso remoto alle macchine virtuali

Sono disponibili diverse opzioni per gli utenti aziendali per accedere in remoto alle macchine virtuali di DevTest Labs:

  • Il metodo più semplice e sicuro consiste nell'usare la connettività del browser tramite Azure Bastion. Le macchine virtuali non devono usare indirizzi IP pubblici. Per altre informazioni, vedere Abilitare la connessione del browser alle macchine virtuali di DevTest Labs con Azure Bastion.

  • Un'altra opzione consiste nell'usare indirizzi IP pubblici o indirizzi IP pubblici condivisi e connettersi tramite RDP (Remote Desktop Protocol) o secure shell (SSH).

  • Se le opzioni precedenti non sono sufficienti, è possibile connettersi tramite un gateway di accesso remoto, come illustrato nell'architettura di riferimento aziendale di DevTest Labs. Per altre informazioni, vedere Configurare un lab per l'uso di Gateway Desktop remoto.

  • Le aziende possono anche connettere i lab alle reti locali tramite ExpressRoute o una VPN da sito a sito. Questa opzione abilita connessioni RDP o SSH dirette alle macchine virtuali in base ai relativi indirizzi IP privati, senza esposizione a Internet.

Accesso al lab e autorizzazioni

Prima dell'implementazione finale di DevTest Labs, è importante decidere su vasta scala chi concedere a ogni livello di accesso al lab. I due livelli di autorizzazione principali di DevTest Labs sono Proprietario e Utente devTest Labs. Un modello comune è destinato al proprietario del budget, ad esempio il responsabile del team, a essere il proprietario del lab, con i membri del team come utenti del lab. La persona responsabile del budget può quindi modificare le impostazioni dei criteri del lab e mantenere il team entro il budget.

Completare il modello di verifica

Dopo aver esaminato gli scenari definiti, completare il progetto pilota. Raccogliere commenti e suggerimenti dagli utenti, determinare se il progetto pilota è riuscito e decidere se l'organizzazione procederà a un'implementazione di DevTest Labs su scala aziendale. Iniziare a prendere in considerazione l'automazione della distribuzione di DevTest Labs e delle risorse associate per garantire la coerenza nell'implementazione con scalabilità orizzontale.

Modello di verifica di esempio

Questo esempio seguente illustra un piano per la definizione dell'ambito di una distribuzione di prova di DevTest Labs.

Panoramica

Un'azienda prevede di sviluppare un nuovo ambiente Azure DevTest Labs da usare per i fornitori, isolato dalla rete aziendale. Per determinare se la soluzione soddisfa i requisiti, l'organizzazione sviluppa un modello di verifica per convalidare lo scenario end-to-end.

Obiettivi

Il modello di verifica ha gli obiettivi seguenti:

  • Soluzione end-to-end funzionante per i fornitori che usano account guest Microsoft Entra per accedere a un ambiente Azure isolato.
  • Un ambiente DevTest Labs con tutte le risorse necessarie per la produttività dei fornitori.
  • Identificazione e comprensione di eventuali potenziali problemi di blocco che influiscono sull'uso e l'adozione più ampi.
  • Buona comprensione di tutto il codice e il materiale collaterale da parte degli utenti che sviluppano la soluzione.
  • Fiducia nell'adozione più ampia da parte di tutti i partecipanti.

Requisiti

La soluzione presenta i requisiti seguenti:

  • I team fornitori possono usare un set di lab in Azure DevTest Labs.
  • I fornitori hanno accesso ai lab tramite Microsoft Entra ID e assegnazioni di ruolo.
  • I fornitori hanno un modo per connettersi correttamente alle proprie risorse, ad esempio una VPN da sito a sito che consente di accedere alle macchine virtuali senza usare indirizzi IP pubblici.
  • I lab si connettono a un'infrastruttura di rete che supporta i requisiti.
  • DevTest Labs installa il set di artefatti software necessari ai fornitori nelle macchine virtuali.

Prerequisiti

  • Sottoscrizione da usare per il progetto
  • Un tenant di Microsoft Entra e un microsoft Entra Global Amministrazione istrator che può fornire guida e indicazioni per Microsoft Entra ID
  • Modalità di collaborazione dei membri del progetto, ad esempio:
    • Azure Repos per codice sorgente e script
    • Microsoft Teams o SharePoint per i documenti
    • Microsoft Teams per conversazioni
    • Azure Boards per gli elementi di lavoro

Attività di installazione

  • Decidere quale area di Azure usare per il modello di verifica.
  • Decidere se aggiungere macchine virtuali lab al dominio Microsoft Entra e se usare Microsoft Entra Domain Services o un altro metodo.
  • Identificare i fornitori che useranno l'ambiente di verifica.
  • Determinare le risorse necessarie per i fornitori, ad esempio il software disponibile nelle macchine virtuali.
  • Decidere i servizi di Azure, diversi dalle macchine virtuali, che i fornitori possono usare in DevTest Labs.
  • Pianificare il training dei fornitori per l'uso del lab.

Passaggi successivi