Invio e promozione del package
Quando il package CCD è pronto, utilizzare la distribuzione automatizzata della build per procedere. Il processo di distribuzione automatizzata della build prevede l'orchestrazione della promozione della configurazione e della personalizzazione in base ai diritti di accesso e alla struttura generale dell'ambiente.
È possibile inviare una build caricando un package CCD e un file manifest nelle rispettive posizioni nell'account di archiviazione. È innanzitutto necessario caricare il package CCD in /data/builds. È quindi necessario caricare il file manifest in /data/builds/deploy.
Questa azione attiva il workflow di distribuzione automatizzata della build. Il processo è guidato tramite task di notifica ricevuti via e-mail. Le informazioni contenute nell'e-mail guidano l'utente all'interno della procedura. Gli approvatori dei task vengono dichiarati nel file manifest. Un esempio di file manifest è disponibile nell'argomento Attivare la distribuzione automatizzata.
 |
Considerare i seguenti aspetti come prerequisiti:
• È necessario impostare una posizione per Archiviazione BLOB di Azure. I dettagli dell'autorizzazione devono essere ottenuti da PTC Cloud.
◦ PTC fornisce un URL SAS per questa attività.
◦ È necessario inviare una richiesta al portale di supporto PTC per includere l'indirizzo IP nell'elenco degli IP consentiti. Nei dettagli per la richiesta di supporto fornire un indirizzo IP stabile.
• È necessario inviare una richiesta per configurare la pipeline in modo che corrisponda al valore menzionato nel file manifest. Esempi sono int1 o pipeline1. Per ulteriori informazioni sull'attributo deploy_pipe, vedere la sezione relativa alla creazione di un file manifest nell'argomento Attivare la distribuzione automatizzata.
|
Il primo passo del workflow di distribuzione automatizzata della build è l'ispezione del package CCD. Il sistema ispeziona il package CCD per determinarne la conformità alle linee guida Windchill+. Dopo l'ispezione, il sistema genera i report e li rende disponibili sull'account di archiviazione.
I report e i log son disponibili nella cartella seguente: /data/builds/logs/<RITM Number>/. La sintassi dei report e dei file di log generati è la seguente:
• Sintassi dei report - cwave_<CustomerShortName>_<Date-Time>_<Control Label>.html. In questo caso, <Control Label> può essere IntakeProcessor, SpotBugs, Logs e così via.
• Sintassi dei log - ccd_<environment>_<Date-Time>_<ant target>_Logs.zip. In questo caso, <ant target> può essere deploy, load e così via. Per ulteriori informazioni, vedere Targets.
|
Nome report
|
Verifiche implementate
|
|---|---|
|
cwave_<CustomerShortName>_<Date-Time>_IntakeProcessor.html
|
Verifiche Windchill+ (personalizzazione consentita da Windchill+, deprecazione, API non supportate, protezione)
|
|
cwave_<CustomerShortName>_<Date-Time>_SpotBugs.html
|
Verifica del codice statico (best practice Java)
|
Considerare i seguenti punti:
• Se una delle verifiche del package CCD ha esito negativo, all'utente viene inviata una notifica e il processo di invio viene interrotto.
• Se il package CCD è conforme, il processo continua e la creazione viene promossa alla destinazione definita nel file manifest.
• Una volta completata correttamente una distribuzione della build, i test devono essere completati entro sette giorni.
|
|
Il cliente è responsabile del contenuto del package CCD. L'invio di una build certifica che lo sviluppo è stato eseguito conformemente alle linee guida di protezione PTC. Per informazioni sulle linee guida di protezione PTC, vedere Security Customization Guidelines.
|
Misure di protezione di Windchill+ per la composizione di un package CCD
Il package CCD e la relativa composizione devono essere conformi a una struttura di directory specifica. Seguire le misure di protezione fornite per la struttura di directory e il contenuto dei file di un package CCD.
• La dimensione di un package CCD non deve superare i 100 MB.
• Il package CCD può contenere le cartelle riportate di seguito.
|
Cartella
|
Descrizione
|
|---|---|
|
Configurations
|
Nessuna o una cartella Configurations
|
|
Generated
|
Nessuna o una cartella Generated
|
|
customlib
|
Nessuna o una cartella customlib
|
|
<custom module(s)>
|
Una o più cartelle di moduli personalizzati
|
|
|
Delle quattro cartelle, almeno una cartella deve essere presente nel package CCD.
|
• Il file descriptor.xml deve essere presente in tutte le cartelle di moduli personalizzati del package CCD.
• La cartella Generated può essere vuota oppure contenere una o entrambe le seguenti cartelle:
◦ Cartella db - La cartella db può essere vuota. In caso contrario, deve contenere il file db/conf/SchemaConfig.xml.
◦ Cartella BAC - È consentito un solo file .zip BAC nella cartella BAC. Le mappature BAC possono essere fornite nel file Mapping.xsl che si trova nella cartella BAC.
◦ customlib deve contenere i file jar IP del partner, se presenti.
• I valori di offerta consentiti sono plusselect e meddev.
• Un package CCD non deve contenere file bloccati o imprevisti in base alle regole di seguito indicate.
◦ Elenco di file non consentiti nel package - .jar, .class, .exe, .ser, .sql, .ddl, .pks, .pkb, .ora, .jasper, .cs, .cpp, .so, .dll, .jnilib, .dylib, .h, .cgf, .out, .ldif, .sh, .pl, .groovy, .gwt.xml, .gwt.modules.xml
◦ File validi nella cartella xconf - .xconf
◦ File validi nella cartella conf - .xml, .ini
◦ File validi nella cartella resources - .tpl, .bas, .ddx, .html, .yml, .xjb, .ftl, .xml, .dtd, .xsl, .properties, .txt, .ini, .json, .js
◦ File validi nella cartella src - .java, .rbInfo
◦ File validi nella cartella jsp - .jsp, .jspf
◦ File validi nella cartella tags - .tag, .tagf
◦ File validi nella cartella tlds - .tld
◦ File non consentiti nella cartella src_web - .java
◦ Percorso valido per la cartella JasperReports - module/main/resources e module/main/src_web (non valido a livello di configurazioni)
◦ File validi nella cartella JasperReports nel percorso delle risorse - .jrxml, .jasperProperties e .properties
◦ Tipo di file valido nella cartella JasperReports nel percorso src_web - .gif
◦ File validi nella cartella customlib - .jar
◦ Le cartelle con il nome apps non sono consentite nelle cartelle di seguito indicate.
▪ configurations/resources
▪ main/resources
▪ main/src_web
Queste misure di protezione vengono controllate quando il package viene inviato per la distribuzione. Qualsiasi non conformità viene segnalata. I log di distribuzione contengono un report di riepilogo RITM, ad esempio RITM0910921.txt. Questo report riassume se il package è conforme alle misure di protezione di Windchill+. Di seguito è riportato un esempio di report di riepilogo RITM.
È possibile trovare i log dettagliati RITM in un file ZIP di report dettagliati contenente i dettagli dei controlli delle misure di protezione. Questo file ZIP contiene un file di log che fornisce i dettagli dei controlli delle misure di protezione.
Un esempio di file ZIP è RITM0910921_Reports.zip.
Un esempio di file di log è preValidate_20240402-142645.log.
| | Sebbene queste regole non vengano applicate, è necessario prendere nota di eventuali deviazioni e correggerle attivamente. PTC applicherà alcune di queste regole in futuro e qualsiasi non conformità renderebbe il package non valido in seguito. Per ulteriori informazioni su avvertenze e personalizzazione non consentita, vedere Disallowed Customization. |
Prima del Go Live
È possibile utilizzare Windchill+ senza l'ambiente di controllo qualità. È inoltre possibile utilizzare Windchill+ Advanced con l'ambiente di controllo qualità. A seconda dello scenario, è possibile attenersi alle procedure descritte negli approcci riportati di seguito.
Windchill+ Advanced con ambiente di controllo qualità
In caso di utilizzo di Windchill+ Advanced con l'ambiente di controllo qualità, attenersi alla procedura descritta di seguito.
1. Inviare il package all'ambiente di integrazione per il ciclo di test di integrazione e accettazione funzionale. È possibile attivare spesso questo ciclo di test. Ad esempio, più volte alla settimana.
◦ Inviare una build e un file manifest con deploy_pipe : int.
Per ulteriori informazioni, vedere Deploying Code and Configuration Package.
◦ Completare il ciclo di test. Al termine del ciclo di test, il task viene considerato completato e viene ripristinato lo stato del ciclo di vita precedente dell'ambiente.
| | Se questo passo non viene completato entro sette giorni, viene automaticamente ripristinato lo stato del ciclo di vita precedente dell'ambiente. |
2. Inviare il package all'ambiente di controllo qualità per i test di accettazione degli utenti, quindi promuovere il package all'ambiente di produzione. Si consiglia di attivare il ciclo di test di accettazione degli utenti una o due volte al mese, poiché questo processo promuove la build all'ambiente di produzione.
◦ Inviare una build e un file manifest con deploy_pipe : pipeline. Per ulteriori informazioni, vedere Deploying Code and Configuration Package.
◦ Completare il ciclo di test. Considerare i seguenti punti:
▪ Se il ciclo di test ha esito positivo, il task viene approvato e la build viene promossa all'ambiente di produzione.
▪ Se il ciclo di test non ha esito positivo, il task viene rifiutato e viene ripristinato lo stato del ciclo di vita precedente dell'ambiente.
▪ Se il ciclo di test non viene completato entro sette giorni, viene ripristinato lo stato del ciclo di vita precedente dell'ambiente.
Windchill+ Basic senza un ambiente di controllo qualità
In caso di utilizzo di Windchill+ Select Basic senza un ambiente di controllo qualità, attenersi alla procedura descritta di seguito.
1. Inviare una build e un file manifest con deploy_pipe : int. Per ulteriori informazioni, vedere Deploying Code and Configuration Package.
2. Completare il ciclo di test di integrazione e accettazione funzionale. Al termine del ciclo di test, il task viene completato e viene ripristinato lo stato del ciclo di vita precedente dell'ambiente.
| | Se questo passo non viene completato entro sette giorni, viene ripristinato lo stato del ciclo di vita precedente dell'ambiente. |
3. Inviare nuovamente la stessa build e un file manifest aggiornato con deploy_pipe : pipeline. Per ulteriori informazioni, vedere Deploying Code and Configuration Package.
4. Completare il ciclo di test di accettazione degli utenti nell'ambiente di integrazione. Considerare i seguenti punti:
◦ Se il ciclo di test ha esito positivo, il task viene approvato e la build viene promossa all'ambiente di produzione.
◦ Se il ciclo di test non ha esito positivo, il task viene rifiutato e viene ripristinato lo stato del ciclo di vita precedente dell'ambiente.
◦ Se il ciclo di test non viene completato entro sette giorni, viene automaticamente ripristinato lo stato del ciclo di vita precedente dell'ambiente.
| | Tutte le attività di test utilizzano un solo ambiente. Il sistema può eseguire una sola attività di test alla volta. Se una build viene inviata utilizzando deploy_pipe : int durante questa finestra, viene automaticamente rifiutata. |
Fase di Go Live
Una volta confermata la fase di Go Live, è obbligatorio riconfigurare l'ambiente di produzione in ambienti di controllo qualità e integrazione.
Per questa attività è necessario aprire una richiesta di assistenza nel portale del supporto PTC. Per ulteriori informazioni, vedere Apertura di una richiesta di assistenza.
Stato del ciclo di vita di esecuzione
• Al termine della fase di Go Live, tutti gli ambienti vengono riconfigurati dall'ambiente di produzione. Pertanto, PTC consiglia vivamente di propagare le modifiche agli ambienti di sviluppo. L'approccio consigliato consiste nell'utilizzare BAC ed esportare un package BAC completo dall'ambiente di integrazione. Per ulteriori informazioni, vedere Importing a BAC Package Using CCD Utility.
Considerare i seguenti punti:
◦ Il modello di dati è la configurazione minima da esportare per ricreare il sistema (Gestione tipi e attributi).
◦ Per gli oggetti non supportati da BAC, è possibile eseguire l'esportazione dall'interfaccia utente dell'ambiente di integrazione (quando possibile) o ricreare il file di caricamento nell'ambiente di sviluppo.
• Successivamente, il ciclo di invio è simile a quello menzionato nella sezione Prima della fase di Go Live dell'argomento Invio e promozione del package.
• Dopo il Go Live principale è necessario riconfigurare l'ambiente di produzione in ambienti di controllo qualità e integrazione. È necessario aprire una richiesta di assistenza per le attività di riconfigurazione. Per ulteriori informazioni, vedere Apertura di una richiesta di assistenza.
| | • Dopo il Go Live iniziale, tutti gli ambienti (eccetto quello di sviluppo) devono essere riconfigurati dalla produzione. La riconfigurazione non è automatica e richiede una richiesta di servizio. • Per Go Live iniziale si intende la prima distribuzione dell'applicazione nell'ambiente di produzione. In questa fase, tutti gli ambienti inferiori vengono sincronizzati con la produzione per garantire omogeneità e stabilità in tutto l'ambiente di distribuzione. • Per Go Live principale si intende qualsiasi release successiva nell'ambiente di produzione dopo il Go Live iniziale. Queste release includono in genere nuove funzionalità, miglioramenti o correzioni e fanno parte del ciclo di sviluppo e distribuzione in corso. |