Il processo di rilascio di NSP si basa sulle esigenze del cliente e sulle best practice seguite dagli altri team. L'obiettivo principale di questo processo è creare e mantenere cicli di rilascio ben definiti e prevedibili. Questo processo ci permette di affrontare le diverse esigenze dei clienti. Alcuni clienti devono rimanere in un'unica release per un periodo di tempo prolungato, piuttosto che adottare le funzionalità di sicurezza più recenti.

NSP supporta i seguenti tipi di Release:

• Rilascio principale:
  Un rilascio principale, noto anche come release Baseline, è adatto per i clienti che sono sottoposti a un controllo rigoroso delle modifiche. Una release principale fornisce nuove funzionalità e miglioramenti ed è certificata. I clienti possono rimanere in questa versione per un periodo di tempo prolungato.
  
• Rilascio delle funzionalità:
  Una release di funzionalità fornisce nuove funzionalità e miglioramenti. È adatto per i clienti che sono disposti a partecipare all'adozione precoce di nuove funzionalità.
  
• Versione di manutenzione:
  Una release di manutenzione, nota anche come release di aggiornamento, fornisce correzioni software. Viene fornito ogni due mesi sia per le release principali che per le release delle funzionalità.
  
• Rilascio hotfix:
  Una release di hotfix fornisce correzioni software sia per le release principali che per le release delle funzionalità. Viene fornito solo su una base di necessità per selezionare i clienti che richiedono correzioni immediate e non possono attendere il rilascio della manutenzione. Una release di hotfix può includere anche più di una correzione.

Nota: NSP Engineering determina al momento del commit del piano di rilascio se una release è una funzionalità o una release principale. Il numero di versione del rilascio viene selezionato di conseguenza.

Di seguito è riportato un esempio di cadenza di rilascio del software NSP releases:


Tenere presente i seguenti termini utilizzati nel presente documento che spiegano l'policy dell'assistenza software per NSP:

• Periodo di fine vita (EoLP):
  EoLP è il lasso di tempo del giorno in cui annunciamo la versione del prodotto discontinuazione fino all'ultimo giorno in cui sosteniamo formalmente la versione del prodotto. EoLP è il periodo compreso tra end of Life Start (EoLS) e End of Life end (EoLE).
• EoLS: sono applicabili i due scenari seguenti:
  • Dopo la dichiarazione di EoLS, non sono disponibili ulteriori rilasci di manutenzione durante il EoLP. Il supporto completo dei set di firme e gli hotfix vengono forniti per i prossimi 12 mesi.
  • Per le release principali, c'è un supporto esteso di altri 12 mesi (per un totale di 24 mesi dopo EoLS).
    Durante questo periodo, non ci sono ulteriori rilasci di manutenzione. Vengono forniti il supporto completo degli insiemi di firme e gli hotfix critici limitati.
• EoLE: non viene fornito alcun set di firme o hotfix. Il software è EoL.
  Di seguito è riportato un esempio di ciclo di vita del rilascio principale e delle funzionalità:

Di seguito sono elencate le caratteristiche di una release principale rispetto a una release delle funzionalità:

	Rilascio principale	Rilascio delle funzionalità
Versione	La seconda cifra della versione del prodotto è numerata come ". 1". Ad esempio 9.110.1 ,, 11.1.	La seconda cifra della versione del prodotto è numerata come. 2,. 3, ecc. Ad esempio 9.29.310.2 ,,,, 10.3.
Ambito di rilascio	Una release principale può includere miglioramenti software per quanto segue: Nuove funzionalità Aggiornamento dell'infrastruttura Supportabilità Introduzione al nuovo hardware Certificazione	Una versione della funzionalità può includere i miglioramenti software per i seguenti elementi: Nuove funzionalità Aggiornamento dell'infrastruttura Supportabilità Introduzione al nuovo hardware
Timeline	Il rilascio principale è di circa ogni 18 mesi.	La release delle funzionalità è di circa ogni 6 mesi fino alla successiva release principale.
Periodo di assistenza	Il periodo di supporto principale del rilascio è di 48 mesi: 24 mesi di engineering e Assistenza tecnica-MRs, hotfix e supporto completo delle Signature set 24 mesi di Assistenza tecnica 24 – 36 mesi-nessun supporto MRs, Full Signature set e hotfix 37 – 48 mesi-nessun supporto MRs, Full Signature set e hotfix critici limitati	Il periodo di supporto del rilascio delle funzionalità è di 20 mesi: 8 mesi di engineering e Assistenza tecnica-MRs, hotfix e supporto completo delle Signature set 12 mesi di Assistenza tecnica-no MRs, Full Signature set support e hotfix
EoLS	EoLS è di 24 mesi dalla data di GA. Viene inviato un annuncio EoL per indicare questa fase.	EoLS è di 8 mesi dalla data di GA. Viene inviato un annuncio EoL per indicare questa fase.
EoLP	EoLP è di 24 mesi.	EoLP è di 12 mesi.
EoLE	EoLE è di 24 mesi dalla data di EoLS.	EoLE è 12 mesi dopo EoLS.
Versione di manutenzione	La versione di manutenzione deve essere fornita una volta ogni due mesi su una base di necessità, fino a EoLS.	La versione di manutenzione deve essere fornita una volta ogni due mesi su una base di necessità, fino a EoLS.
Hotfix	Gli hotfix vengono forniti in base alle esigenze utilizzando i due scenari seguenti: Dopo la dichiarazione di EoLS, vengono forniti hotfix per i prossimi 12 mesi. Per il periodo rimanente fino a EoLE, vengono forniti aggiornamenti critici limitati.	Gli hotfix vengono forniti su base necessaria, fino a EoLE.
Set di firme	Gli aggiornamenti dei set di firme vengono forniti fino a EoLE.	Gli aggiornamenti dei set di firme vengono forniti fino a EoLE.
Correzioni delle vulnerabilità	Le correzioni delle vulnerabilità sono fornite su base necessaria, fino a EoLE.	Le correzioni delle vulnerabilità sono fornite su base necessaria, fino a EoLE. Importante: NSP Engineering potrebbe consentire un'eccezione in alcuni casi in cui è necessario un impegno significativo per supportare la correzione. L'approvazione del Business Head è necessaria per le eccezioni.
Supporto per nuovi componenti hardware/piattaforma	Qualsiasi nuovo hardware o piattaforma NSP è supportato nella release principale o nelle release delle funzionalità, a seconda dell'ambito delle modifiche coinvolte.
Certificazione	Ogni release principale è certificata per CC/FIPS/UC APL, ecc. I rilasci di certificazione sono numerati come 9.1.15.x , 9.1.17.x9.1.19.x.
Localizzazione	La localizzazione dell'interfaccia utente del modulo rapporti Manager e della documentazione del prodotto viene eseguita per il rilascio principale ed è disponibile da MR1 del rilascio principale. L'interfaccia utente e la documentazione di ogni release di funzionalità Manager sono localizzate. L'interfaccia utente di Manager rapporto e la documentazione complessiva del prodotto sono localizzate nelle seguenti lingue: giapponese, coreano, cinese semplificato e tradizionale.

Domande frequenti:

sono un cliente NSP esistente. Quando è possibile prevedere l'implementazione della versione corrente del processo di rilascio di NSP?
Il processo di rilascio di NSP descritto nel presente documento è valido per il quarto trimestre, 2017 in avanti.

Sono un nuovo cliente e desidero installare NSP. Quale ramo di rilascio è necessario utilizzare?
Si consiglia di installare una release di funzionalità per sfruttare le funzionalità e i miglioramenti più recenti. Tuttavia, la vostra decisione deve tenere conto del processo di controllo delle modifiche della vostra organizzazione. Se l'organizzazione applica un aggiornamento rigoroso policy o desidera rimanere su un'unica versione di rilascio per un lungo periodo, si consiglia di utilizzare il rilascio principale.

Sto utilizzando il rilascio 9.1. principale posso trasferirmi al rilascio 9.2 delle funzionalità?
Sì. Tuttavia, una volta adottata una release di funzionalità, è necessario rimanere nel percorso di rilascio della funzionalità fino a rendere disponibile la prossima release principale.
Se è necessario tornare alla versione principale precedente, è necessario riconfigurarlo e riavviarlo di nuovo.

Quali sono le opzioni di upgrade supportate tra le release delle funzionalità e le release principali?
Gli scenari di upgrade supportati per il software Sensor e Manager sono i seguenti:

• Sono supportati gli upgrade dal rilascio principale precedente alla release principale successiva. Ad esempio, da 8.1 a 9.1 e 9.1 a 10.1.
• Sono supportati gli upgrade dalla versione precedente della funzionalità al rilascio della funzionalità successiva. Ad esempio, se sono presenti rilasci 9.2 di funzionalità e 9.3 l'utente è attualmente 9.2 attivo, è possibile effettuare l'upgrade a 9.3.
• Sono supportati gli upgrade dalle due versioni precedenti alla release principale successiva. Ad esempio, se sono presenti Release 8.2 e 8.3 , è possibile effettuare l'upgrade da 8.2 e 8.3 per 9.1.

Le release delle funzionalità del Manager supportano sensori eterogenei di funzionalità e Release principali?
Gli scenari supportati sono i seguenti:

• La versione principale di Manager supporta sensori eterogenei per la versione precedente e immediata della versione precedente. Ad esempio: il 9.1 Manager supporta i sensori in esecuzione 9.1 , 8.1 e l'ultima release 8.x delle funzionalità del software Sensor.
• La funzione Manager Release supporta sensori eterogenei per il rilascio immediato delle funzionalità precedenti e il rilascio principale immediato precedente. Ad esempio: il Manager supporta i 8.3 sensori in esecuzione 8.3 e 8.1 Sensor software.

Nota: La terza cifra varia per i diversi modelli di Sensor. Ad esempio, M-Series is 8.1.3.x e NS-Series è 8.1.5.x.

Le release delle funzionalità del Central Manager supportano gestori eterogenei di funzionalità e Release principali?
Gli scenari supportati sono i seguenti:

• La Central Manager principale supporta Manager eterogenei per la release principale immediata precedente Manager e la funzionalità precedente immediata Manager rilascio. Ad esempio: il 9.1 Central Manager supporta i Manager in esecuzione 8.19.1 e l'ultima release 8.x delle funzionalità del software Manager.
  
• La funzione Central Manager Release supporta i manager eterogenei per la versione immediata precedente della feature e la release principale immediatamente precedente. Ad esempio: il Central Manager supporta i 8.3 Manager in esecuzione 8.3 e 8.1 Manager software.

Viene fornita una notifica anticipata quando si consiglia ai clienti di effettuare l'upgrade del software Sensor a una versione consigliata minima per motivi critici?
Quando annunciamo una nuova immagine software Sensor per risolvere qualsiasi problema o vulnerabilità critica, forniamo:

• Una finestra di sei mesi per i clienti di effettuare l'upgrade all'immagine consigliata minima se c'è una release di funzionalità (ad esempio, da 8.2 a 8.3 ) o una release di manutenzione (ad esempio, da 8.3.5.15 a 8.3.5.30 ).
• Una finestra di 12 mesi per i clienti di effettuare l'upgrade all'immagine consigliata minima se è presente una release principale (ad esempio, da 9.1 a 10.1 ).