Processo di distribuzione per una build di Windchill Navigate
Il processo di distribuzione prevede l'invio e la promozione del package in diversi ambienti. L'obiettivo è garantire che il package venga accuratamente testato e convalidato in ogni fase prima di raggiungere l'ambiente di distribuzione finale.
Il processo di distribuzione di Navigate include i seguenti passi:
1. Distribuzione iniziale in un ambiente inferiore
2. Fase della curva di maturità
3. Distribuzione finale nell'ambiente di produzione
Si consideri lo scenario seguente: il team seleziona un caso di utilizzo in base ai requisiti correnti e quindi integra il caso di utilizzo nel ciclo di sprint. Il processo prevede l'invio e la promozione del package attraverso varie fasi. Inizialmente, è possibile distribuire il package in un ambiente inferiore inviandolo. Il package viene promosso alla fase della curva di maturità. La promozione finale avviene nella fase di distribuzione finale.
Descrizione dettagliata del processo
1. Prima/iniziale distribuzione della build - La distribuzione iniziale della build che PTC riceve dal cliente viene sottoposta a un esame completo da parte del team PTC. Gli elementi necessari per questo esame includono:
◦ Questionario compilato: un questionario dettagliato compilato dal cliente.
◦ Package della build: un package compresso inviato da clienti/integratori di sistemi.
 | La build iniziale avanza al passo successivo solo se il team PTC la approva, verificando che soddisfi le linee guida richieste. |
2. Fase della curva di maturità - Questa fase non richiede l'approvazione del team PTC. Durante questa fase, la build passa attraverso una curva di maturità, che include i task seguenti:
◦ Correzioni di bug: identificazione e risoluzione dei problemi.
◦ Modifiche della logica: perfezionamento della funzionalità della build.
◦ Test di accettazione degli utenti (UAT): garantiscono che la build soddisfi i requisiti dell'utente.
◦ Modifiche estetiche: aggiustamento dell'interfaccia e dell'esperienza dell'utente.
La distribuzione iniziale avviene in un ambiente non di produzione. Un cliente o un integratore di sistema è tenuto a tenere una documentazione completa di tutte le modifiche apportate alla build.
| | È fondamentale che i requisiti definiti dal package della build e le dipendenze della build (da librerie di terze parti) rimangano invariati durante questo processo. In caso di modifiche, è necessario riavviare il processo di distribuzione. |
3. Distribuzione finale della build nell'ambiente di produzione - La distribuzione finale nel server del prodotto viene sottoposta a un esame approfondito e completo da parte del team PTC. Questo esame garantisce che tutti gli aspetti della build soddisfino gli standard più elevati di qualità, funzionalità e conformità prima del rilascio nell'ambiente di produzione. Di seguito sono indicati gli elementi necessari per questo esame:
◦ Questionario compilato: un questionario dettagliato compilato dal cliente.
◦ Package della build: un package compresso inviato da clienti/integratori di sistemi.
◦ Documentazione dettagliata: documentazione completa di tutte le modifiche apportate alla build durante la fase di maturità. Per ulteriori informazioni, vedere la sezione Creazione della documentazione completa: linee guida chiave.
| | Questa fase richiede l'approvazione del team PTC. |
Linee guida per i clienti
• Coerenza dei requisiti - La build iniziale caricata deve includere tutto il contenuto significativo. Per l'integratore di sistema è essenziale evitare di introdurre modifiche significative nei requisiti o nelle dipendenze (soprattutto da librerie di terze parti) durante le due fasi di distribuzione: la prima e la terza fase.
• Documentazione completa - È necessario tenere una documentazione completa di tutte le modifiche apportate alla build.
• Esame del team PTC - Il team PTC esamina tutte le modifiche prima che la build venga promossa per la distribuzione finale nell'ambiente di produzione.
Attenendosi a queste linee guida, è possibile garantire un processo di distribuzione sicuro e stabile per la build di Windchill Navigate.
Con quale frequenza è necessario ripetere il processo di distribuzione?
Quando si prende in considerazione una personalizzazione, si pensa a un caso di utilizzo specifico e un team di sviluppo che lavora in cicli di sprint. Il team sceglie un caso di utilizzo, che può essere un requisito o un gruppo di requisiti, e inizia a svilupparlo in cicli di sprint. A volte possono essere necessari più cicli di sprint per preparare la build.
Ad esempio, in un ciclo di rilascio di sei mesi con cinque sprint, i requisiti vengono selezionati e sviluppati all'interno di questi sprint. Le sequenze temporali potrebbero essere diverse, ad esempio sprint di 20 giorni con fasi di sviluppo, controllo qualità e distribuzione. Se i requisiti cambiano in modo significativo durante il ciclo, il processo deve essere riavviato e sono necessarie le approvazioni.
La frequenza del processo di distribuzione dipende dal numero di casi di utilizzo e dai cicli di sprint. Ad esempio, se si sviluppano 10 casi di utilizzo in 10 cicli di sprint, il processo viene seguito 10 volte. Se si sviluppano 5 casi di utilizzo in un solo ciclo di sprint, il processo viene seguito due volte.
Esempi aggiuntivi:
1. Esempio 1: cicli di sprint più brevi
◦ Il ciclo di sprint previsto è di 2 settimane. Si seleziona un requisito, lo si sviluppa per 10 giorni, si dedicano 2 giorni al controllo qualità e quindi lo si distribuisce. Se i requisiti sono 6, il processo viene eseguito 6 volte in 12 settimane.
2. Esempio 2: requisiti sovrapposti
◦ Sono presenti requisiti sovrapposti che si estendono su più sprint. Ad esempio, un requisito che richiede 3 sprint per essere completato seguirà il processo una volta per ogni sprint, garantendo test e integrazione continua.
3. Esempio 3: modifiche sostanziali a metà ciclo
◦ Se si apporta una modifica significativa a un requisito a metà ciclo, ad esempio se si modifica il modello di dati, è necessario riavviare il processo. In tal modo si garantisce che tutte le dipendenze vengano rivalutate e che vengano ottenute le approvazioni.
4. Esempio 4: distribuzioni frequenti
◦ Si preferiscono distribuzioni frequenti e un ciclo di sprint di 1 settimana. Si esegue lo sviluppo per 4 giorni, il controllo qualità per 1 giorno e la distribuzione l'ultimo giorno. Con 8 requisiti, il processo viene eseguito 8 volte in 8 settimane.
5. Esempio 5: sequenze temporali personalizzate
◦ È possibile impostare sequenze temporali personalizzate in base alle esigenze del progetto. Ad esempio, un ciclo di sprint di 30 giorni potrebbe prevedere 20 giorni di sviluppo, 5 giorni di controllo qualità e 5 giorni di distribuzione. È possibile regolare la frequenza del processo in base al numero di requisiti e alla loro complessità.
Quali informazioni sono incluse nel questionario?
Durante il processo di distribuzione è necessario compilare due questionari:
1. Questionario sulla distribuzione iniziale - Questo questionario è obbligatorio per la prima distribuzione in un ambiente inferiore. Garantisce che tutti i controlli e le configurazioni preliminari siano stati completati prima di procedere.
2. Questionario sulla distribuzione finale - Questo questionario è obbligatorio per la distribuzione finale nell'ambiente di produzione. Consente di verificare che tutti gli aspetti critici siano stati esaminati e approvati, garantendo una distribuzione fluida e corretta.
Di seguito è riportato un esempio di questionario:
Domanda | Risposta | |
|---|---|---|
Dettagli generali | Nome dell'account cliente | |
Versione di Windchill in uso | ||
Versione di Windchill Navigate in uso | ||
Data di distribuzione pianificata | ||
Ambiente di distribuzione pianificato | ||
Dettagli del package | Il package è stato testato in ambienti inferiori? In caso affermativo, indicare l'ambiente. | |
Che tipo di personalizzazioni sono state implementate? | ||
Nel package vengono utilizzate librerie di terze parti? | ||
Si utilizza il metodo di autenticazione predefinito o il package si basa sulle chiavi di accesso? | ||
Qual è il business case o l'obiettivo della personalizzazione? | ||
È stato accertato che nessuna parte della personalizzazione violi le misure di protezione? | ||
Quali sono le differenze tra il vecchio package e quello nuovo (se presenti)? |
| | In questo questionario, è necessario descrivere eventuali differenze tra il vecchio e il nuovo package. Ad esempio, è possibile spiegare se sono state aggiunte nuove funzionalità, se sono stati risolti bug o se sono state apportate modifiche al numero di versione. Queste differenze sono importanti perché aiutano a garantire che tutti coloro che sono coinvolti nel processo di distribuzione comprendano cosa è cambiato. In questo modo è possibile evitare problemi, garantire la compatibilità e assicurarsi che il nuovo package soddisfi tutti i requisiti. |
Creazione della documentazione completa: linee guida chiave
Quando si invia la build finale per la distribuzione nell'ambiente di produzione, è fondamentale includere la documentazione completa di tutte le modifiche apportate durante la fase di maturità. Questa documentazione deve descrivere in dettaglio tutti gli aggiornamenti, le aggiunte di funzionalità, le correzioni di bug e le revisioni che si sono verificate durante il processo di sviluppo.
Fornendo una documentazione completa, si garantisce che tutte le parti interessate siano a conoscenza delle modifiche facilitando la risoluzione dei problemi, il mantenimento della coerenza e la verifica che la build soddisfi tutti i requisiti. Questo passo è essenziale per una distribuzione corretta e senza problemi, riducendo al minimo il rischio di errori e assicurando che l'ambiente di produzione sia completamente preparato per la nuova build.
Si consideri lo scenario riportato di seguito.
In genere, si avvia un ciclo di build con la versione 1.0. Man mano che si crea una nuova revisione della build nelle fasi successive, è possibile aggiornarla a versioni come 1.1, 1.2 e così via. Quando la build è pronta per la distribuzione nel server di produzione, potrebbe essere stata rivista più volte, raggiungendo una versione finale, ad esempio la 1.7.
È necessario tenere traccia delle modifiche apportate durante ogni revisione. Ad esempio, se si modificano 5 elementi, documentare chiaramente queste modifiche. Questa documentazione può essere sotto forma di note di rilascio, le cui dimensioni variano a seconda del prodotto.
Ad esempio, la documentazione può includere quanto segue:
• Versione 1.4.6: aggiunta una correzione per gestire un problema specifico.
• Versione 1.4.5: implementazione di una nuova funzionalità.
• Versione 1.4.4: miglioramento delle prestazioni per una particolare funzione.
Questo tipo di documentazione consente di tenere traccia del percorso della build dalla versione 1.0 alla versione 1.7. È possibile utilizzare schermate o qualsiasi formato che trasmetta al meglio le informazioni pertinenti. La chiave è garantire la tracciabilità completa delle modifiche. Utilizzare il formato più adatto alle proprie esigenze, che si tratti di un documento Word, di un foglio Excel o di qualsiasi altro metodo.
Di seguito sono riportati alcuni esempi di log delle modifiche:
Esempio 1 - Log modifiche conciso: riepilogo di una riga per riferimento rapido
Esempio 2 - Log modifiche dettagliato: elenco completo degli aggiornamenti
Esempio 3 - Log modifiche completo: una raccolta completa di aggiornamenti, correzioni e miglioramenti
