Accesso, distribuzione e configurazione di Windchill+
|
|
Il ruolo di amministratore aziendale fornisce privilegi elevati per supportare le modifiche di configurazione critiche per l'azienda, incluso l'accesso alle pagine delle utilità a livello di sito. Sebbene questa funzionalità consenta maggiore agilità, deve essere utilizzata con giudizio e non sostituisce la metodologia di distribuzione CCD consigliata.
Per iniziare a utilizzare la funzionalità di amministratore aziendale, è necessario generare una richiesta di servizio. Al momento dell'approvazione, un amministratore del sito assegna l'utente al gruppo Site Business Administrator - Contributor (Site) concedendo all'utente i privilegi necessari. Per ulteriori informazioni, vedere Apertura di una richiesta di assistenza.
|
Accesso
• È possibile accedere alla parte front-end dell'ambiente di integrazione, incluse le pagine delle utilità a livello di organizzazione e di amministratore del sito.
• L'accesso amministrativo è limitato alle pagine delle utilità a livello di sito e di organizzazione, sia per gli ambienti di controllo qualità che per quelli di produzione. Questo accesso deve essere utilizzato principalmente per scopi di sola visualizzazione, anche se con il nuovo ruolo di amministratore aziendale tale accesso non viene applicato. PTC consiglia di utilizzare questo accesso solo per scopi di monitoraggio e risoluzione dei problemi. Le utilità specifiche a livello di organizzazione disponibili variano a seconda dell'ambiente. Utilizzare questo accesso in modo responsabile e rimanere sempre all'interno dell'ambito definito del proprio ruolo.
• Non è possibile accedere alla parte back-end dei server Windchill in alcun ambiente Windchill+ ospitato da PTC. L'accesso back-end è disponibile solo negli ambienti di sviluppo locali, come macchina virtuale ospitata da sviluppatori o dal portale cloud.
Metodologie di distribuzione
• PTC supporta la distribuzione di package di build solo tramite il processo di distribuzione automatizzata della build.
• La distribuzione automatizzata della build accetta solo una singola metodologia di creazione dei package, denominata CCD (Code and Configuration Deployment).
• Il sistema utilizza il framework Business Administrative Change (BAC) per acquisire, esportare e importare le configurazioni aziendali. Un package BAC deve essere incluso nel package CCD per poter essere promosso.
• L'utilità CCD è l'unica metodologia di distribuzione supportata.
• Un package BAC deve includere tutte le configurazioni e combinare tutti i workstream (cumulativi) in un determinato intervallo di tempo in base alla programmazione e alla cadenza di rilascio. Per ulteriori informazioni, vedere
Importing a BAC Package Using CCD Utility.
• PTC sconsiglia di utilizzare BAC per gestire le liste di controllo d'accesso (ACL) dei contenitori. Utilizzare invece la struttura
LoadFromFile, supportata all'interno del package CCD. Per ulteriori informazioni, vedere
CCD Package Structure.
• Le ACL non sono consentite tramite BAC o altri oggetti simili. Questa restrizione si applica specificamente alle distribuzioni di Windchill+.
• La funzionalità LoadFromFile presenta limitazioni ben definite. Supporta solo i package CCD che non superano una determinata soglia di dimensione.
Best practice per lo sviluppo e la configurazione
• Tutti i progetti devono iniziare con le attività di modellazione dei dati tramite l'utilità Gestione tipi e attributi.
• La modellazione dei dati si riferisce alla definizione di un tipo di oggetto e di una strategia di attributo. Nell'ambiente di sviluppo, sviluppare il modello di dati e pubblicarlo nell'ambiente di integrazione utilizzando la distribuzione automatizzata.
• È necessario convalidare tutti i package CCD prima di inviarli al servizio di creazione automatizzato. È consigliabile impostare due ambienti di sviluppo:
◦ Un ambiente di sviluppo di origine in cui vengono implementate le modifiche.
◦ Un ambiente di sviluppo di destinazione per verificare se il package CCD può essere distribuito. Per ulteriori informazioni, vedere la sezione relativa al target di distribuzione in
Targets.
In questo contesto, l'argomento
Destinazioni fa riferimento in modo specifico alle destinazioni ANT CCD utilizzate per scopi di creazione e configurazione. Non fa riferimento agli ambienti di distribuzione quali INT (integrazione), QA, PROD (produzione) o eventuali destinazioni pipeline associate.
• Per la gestione della configurazione, è necessario creare un package BAC dopo ogni test di accettazione funzionale completato. I clienti e i partner devono pianificare l'archiviazione di questi package nel proprio sistema di gestione del codice sorgente. Il package BAC include il modello di dati e funge da punto di partenza per l'inserimento di nuovi sviluppatori o l'aggiornamento dell'ambiente di sviluppo locale.
• Quando un package BAC è disponibile nell'ambiente di integrazione, gli sviluppatori possono eseguire modifiche minori dall'interfaccia utente.
• Tutto lo sviluppo deve essere eseguito in un ambiente di sviluppo locale, ad esempio una macchina virtuale locale o un portale cloud.
• L'utilità CCD deve essere utilizzata nell'ambiente di sviluppo per attività di preparazione, creazione e distribuzione.
• PTC sconsiglia di gestire la configurazione di singoli contenitori nell'ambiente di sviluppo, ad esempio un prodotto o un progetto.
• È possibile creare alcuni contenitori per produrre un modello di contenitore.
• Utilizzare con cautela la configurazione a livello di contenitore negli ambienti di controllo qualità e produzione.
Riepilogo dei ruoli di amministratore aziendale
|
|
PTC consiglia che l'utente assegnato al ruolo di amministratore aziendale non sia membro di altri gruppi di utenti con permessi inferiori.
|
Il gruppo di utenti Amministratore aziendale concede privilegi elevati per apportare modifiche direttamente nell'ambiente di produzione. Queste funzionalità consentono di visualizzare e aggiornare direttamente la configurazione aziendale, incluse le definizioni dei tipi, le strutture di attributi e le classificazioni, ma comportano anche una notevole responsabilità operativa. Modifiche non appropriate o non coordinate possono interrompere i workflow attivi, influire sull'integrità dei dati o compromettere la continuità dei processi aziendali.
I clienti sono fortemente invitati a definire pratiche di governance interne, inclusi protocolli di gestione delle modifiche, test in ambienti non di produzione e formazione degli amministratori. Questa funzionalità è progettata per ridurre la dipendenza dalle pipeline della piattaforma, laddove appropriato, ma non per eliminare le best practice relative alla convalida e alla responsabilità. L'agilità aziendale e la stabilità della piattaforma devono essere attentamente equilibrate.
Le interruzioni del sistema causate da questa funzionalità sono considerate responsabilità del cliente e non sono coperte dalle interruzioni previste dal contratto SLA o dalla garanzia di uptime del 99,5%.