Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo della gestione del ciclo di vita come utente del blueprint

La gestione del ciclo di vita è la capacità di rigenerare una base di codice da opzioni o versioni aggiornate di un blueprint. Ciò consente all'autore di un blueprint di gestire centralmente il ciclo di vita di sviluppo del software di ogni progetto che contiene un particolare blueprint. Ad esempio, l'aggiunta di una correzione di sicurezza al blueprint di un'applicazione Web consentirà a ogni progetto che contiene o creato dal blueprint dell'applicazione Web di rilevare automaticamente tale correzione. Questo stesso framework di gestione consente inoltre all'utente del blueprint di modificare le opzioni del blueprint dopo averle selezionate.

Utilizzo della gestione del ciclo di vita su progetti esistenti

È possibile utilizzare la gestione del ciclo di vita per progetti creati a partire da blueprint o su progetti esistenti non associati a nessun blueprint. Ad esempio, è possibile aggiungere un blueprint di pratiche di sicurezza standard in un'applicazione five-year-old Java che non è mai stata creata a partire da un blueprint. Il blueprint genera un flusso di lavoro di scansione di sicurezza e altro codice correlato. Quella parte della base di codice nell'applicazione Java verrà ora aggiornata automaticamente con le migliori pratiche del team ogni volta che vengono apportate modifiche al blueprint.

Utilizzo della gestione del ciclo di vita su più blueprint in un progetto

Poiché i blueprint rappresentano componenti architettonici, è spesso possibile utilizzare più blueprint insieme nello stesso progetto. Ad esempio, un progetto potrebbe essere costituito da un API blueprint web centrale creato da un ingegnere della piattaforma aziendale, insieme a un blueprint di controllo del rilascio creato dal team addetto alla sicurezza delle app. Ciascuno di questi progetti può essere aggiornato in modo indipendente e memorizzerà le risoluzioni di fusione applicate in passato.

Gestione dei conflitti nelle richieste pull del ciclo di vita

Occasionalmente, le richieste pull del ciclo di vita potrebbero generare conflitti di fusione. Questi problemi possono essere risolti manualmente. Le risoluzioni vengono memorizzate nei successivi aggiornamenti del blueprint.

Disattivazione delle modifiche alla gestione del ciclo di vita

Gli utenti possono rimuovere un blueprint da un progetto per dissociare tutti i riferimenti al blueprint e disattivare gli aggiornamenti del ciclo di vita. Per motivi di sicurezza, ciò non rimuove né influisce sul codice o sulle risorse del progetto, incluso ciò che è stato aggiunto dal blueprint. Per ulteriori informazioni, consulta Dissociazione di un blueprint da un progetto per interrompere gli aggiornamenti.

Sovrascrivere la gestione del ciclo di vita di un blueprint in un progetto

Se desideri sovrascrivere gli aggiornamenti di un blueprint a file specifici del progetto, puoi includere un file di proprietà nel tuo repository. GitLabLa specifica Code Owners è la linea guida consigliata. Il blueprint rispetta sempre il file dei proprietari del codice più di ogni altra cosa e può generarne uno di esempio come il seguente:

new BlueprintOwnershipFile(sourceRepo, {
      resynthesis: {
        strategies: [
          {
            identifier: 'dont-override-sample-code',
            description: 'This strategy is applied accross all sample code. The blueprint will create sample code, but skip attempting to update it.',
            strategy: MergeStrategies.neverUpdate,
            globs: [
              '**/src/**',
              '**/css/**',
            ],
          },
        ],
      },
    });

Questo genera un file .ownership-file con i seguenti contenuti:

[dont-override-sample-code] @amazon-codecatalyst/blueprints.import-from-git
# This strategy is applied accross all sample code. The blueprint will create sample code, but skip attempting to update it.
# Internal merge strategy: neverUpdate
**/src/**
**/css/**