Le complessità nascoste del rilascio di nuove versioni su IBM^® i

Consegna di una nuova versione di Rocket^® DevOps è sempre una pietra miliare. Rappresenta mesi (o anni) di impegno da parte dei team di sviluppo, test, documentazione e supporto. Ma per quelli di noi in IBM^® nell'ecosistema, il processo di rilascio è raramente semplice.

Evidenziamo gli aspetti meno visibili dei rilasci di prodotto: le sfide legate alla compatibilità, agli aggiornamenti e al supporto a lungo termine. Sebbene ogni fornitore e team di prodotto affronti i propri ostacoli specifici, questi tre temi ricorrenti sono quelli che ho visto emergere spesso durante i cicli di rilascio. Ma come possono le organizzazioni gestirli?

1. Tenere il passo con gli aggiornamenti del sistema operativo IBM i

IBM^® i continua a evolversi, con frequenti aggiornamenti tecnologici (TR) e rilasci importanti periodici. Ogni modifica apporta miglioramenti, ma anche potenziali rischi per i fornitori di software.

• Rischi di compatibilità: anche piccole modifiche a IBM i possono alterare il comportamento in modi che incidono sul nostro prodotto. Le API potrebbero essere deprecate, i modelli di sicurezza migliorati o gli strumenti di sistema sostituiti.
• Esigenze di test: prima di ogni rilascio, investiamo molto nei test su più versioni di IBM i per garantirne la stabilità. Ciò richiede non solo impegno tecnico, ma anche l'accesso ad ambienti di test che eseguono ciascuna versione supportata.

Cosa puoi fare:

• Gestire un laboratorio dedicato di ambienti che comprendano le versioni IBM i supportate.
• Collaborare con IBM nelle fasi iniziali del ciclo di aggiornamento tecnologico per anticipare i cambiamenti radicali.
• Fornire ai clienti matrici di supporto chiare per le versioni IBM i.

2. Interdipendenze con strumenti di terze parti

Le moderne applicazioni IBM i raramente esistono in modo isolato. Il nostro prodotto si integra con il controllo del codice sorgente ^Git®, le piattaforme CI/CD, i sistemi di ticketing e persino le soluzioni di sicurezza. La sfida è che questi strumenti di terze parti si evolvono in modo indipendente.

• Versione Drift: Una nuova versione di uno strumento di terze parti potrebbe improvvisamente interrompere la nostra integrazione.
• Coordinamento dei fornitori: Spesso ci affidiamo alle roadmap e alle priorità di altri fornitori, che potrebbero non essere in linea con le nostre.

Cosa puoi fare

• Ove possibile, creare integrazioni solide e basate su standard.
• Gestire pipeline di test automatizzate che esercitino integrazioni con le versioni più recenti di strumenti di terze parti.
• Fornire ai clienti indicazioni sulle versioni di terze parti "certificate" da noi testate.

3. Aggiornamento dei clienti da versioni precedenti del nostro software

Non tutti i clienti effettuano aggiornamenti frequenti. Alcuni potrebbero utilizzare versioni del nostro prodotto risalenti a cinque, dieci o addirittura quindici anni fa, una strategia che comporta rischi significativi. Aggiornare i clienti all'ultima versione raramente è un processo che richiede un solo clic.

• Sono necessari più passaggi: a volte, l'architettura del prodotto è cambiata in modo così significativo che gli aggiornamenti diretti non sono possibili. I clienti potrebbero dover passare attraverso più versioni intermedie.
• Conversione dei dati: le modifiche dello schema e le trasformazioni della configurazione devono essere gestite con attenzione per evitare interruzioni.
• Avversione al rischio: è comprensibile che i clienti siano preoccupati per l'impatto sulle applicazioni mission-critical.

Cosa puoi fare

• Fornire percorsi di aggiornamento chiari e documentazione che delinei i passaggi richiesti.
• Se possibile, fornire utilità di migrazione per automatizzare le transizioni di dati e configurazioni.
• Offri servizi professionali o supporto partner per aggiornamenti complessi.

4. Supporto delle versioni precedenti quando cambiano le dipendenze

Anche dopo il rilascio di una nuova versione, le versioni precedenti rimangono in uso. Supportarle può essere difficile, soprattutto quando si utilizzano dipendenze di terze parti come Java.^® o i compilatori si evolvono.

Terreno in movimento: Ad esempio, quando Oracle^® o se IBM modifica le policy di supporto Java, le versioni precedenti del nostro prodotto potrebbero non funzionare più in modo affidabile.
Aspettative del cliente: Alcuni clienti si aspettano che le versioni precedenti continuino a essere pienamente supportate, anche quando la piattaforma sottostante non sarà più compatibile.

Cosa puoi fare

• Definire e comunicare una chiara politica del ciclo di vita del supporto (ad esempio, N-2 rilasci).
• Fornire ai clienti un preavviso quando le modifiche apportate da terze parti interessano le versioni precedenti.
• Incoraggiare gli aggiornamenti proattivi anziché la risoluzione reattiva dei problemi.

5. Altre sfide degne di nota

I problemi sopra menzionati sono comuni, ma non sono certo le uniche difficoltà nel rilascio di una nuova versione. Ad esempio:

• Localizzazione e supporto multilingue.
• Differenze hardware tra le sedi dei clienti.
• Requisiti di conformità alla sicurezza (ad esempio, standard di crittografia).
• Personalizzazioni specifiche del cliente che complicano gli aggiornamenti.
   

Considerazioni finali

Il rilascio di una nuova versione di un software per IBM i non si limita mai all'aggiunta di funzionalità. Ogni rilascio è un delicato equilibrio tra priorità, compromessi e mitigazione dei rischi. Per Rocket Software, si tratta di compatibilità, continuità e della fiducia dei clienti che si affidano al nostro prodotto per carichi di lavoro critici.

Raramente esiste un approccio unico e impeccabile al rilascio del software, soprattutto in ambienti complessi come IBM i. Il successo deriva da una combinazione mirata di test e validazioni rigorosi, comunicazione chiara e coerente e policy ben definite che guidano il supporto e la pianificazione del ciclo di vita. Quando questi elementi sono presenti, le organizzazioni riducono i rischi, migliorano l'affidabilità e rafforzano la credibilità. Essendo trasparenti su ciò che è coinvolto, su ciò che è in evoluzione e su ciò che è previsto, promuoviamo la fiducia e creiamo una base più solida per partnership e prestazioni a lungo termine.

IBM è un marchio registrato di International Machines Corporation

Oracle, Java, MySQL e NetSuite sono marchi registrati di Oracle e/o delle sue affiliate. Altri nomi potrebbero essere marchi dei rispettivi proprietari.

Git e il logo Git sono marchi registrati o marchi di Software Freedom Conservancy, Inc., negli Stati Uniti e/o in altri paesi