Rilasciare Software in Cloud, Desktop e Aziende
Ci sono diversi tipi di ambiente di produzione quando si tratta di rilasciare software:
Leggi l’articolo su Medium pubblicato in Serious Scrum
- Applicazioni cloud come Gmail, che hanno il loro ambiente di produzione nel cloud e non sono installate localmente nell’infrastruttura dei clienti
- Applicazioni desktop come Libre Office installate sul laptop del cliente finale
- I prodotti software aziendali come SAP che vengono rilasciati in moduli da SAP SE e successivamente devono essere personalizzati per adattarsi alle esigenze del cliente
Rilasciare software nel cloud
Nelle piattaforme native cloud, tutto è sotto il controllo dell’organizzazione proprietaria del prodotto. Se viene eseguito un aggiornamento al software nel cloud, può essere distribuito automaticamente a tutti gli utenti finali. La maggior parte delle volte, l’aggiornamento per l’utente finale è facile e immediato come aggiornare una pagina del browser. Questo è il caso in cui tutti i vantaggi del DevOps sono spinti all’estremo. Ogni volta che una funzionalità è pronta per essere rilasciata può passare dall’ambiente di sviluppo direttamente alla produzione con un semplice click.
Tutte le pipeline automatizzate eseguiranno i controlli per la qualità del codice, le prestazioni, le regressioni e nel caso in cui tutti i controlli di qualità passino il software può entrare direttamente in produzione e l’utente finale può beneficiare dell’aggiornamento software. Questo è anche lo scenario in cui è possibile massimizzare i vantaggi del feedback rapido da parte degli utenti finali. Basta rilasciare software con le funzionalità minime e creare funzionalità aggiuntive in base al feedback degli utenti.
In questo caso, non aspettiamo fino alla fine dello Sprint per eseguire il rilascio. Pur mantenendo gli eventi Scrum pianificati in ogni Sprint, il rilascio software può diventare un altro punto nella definition of Done. In questo modo la funzionalità implementata viene considerata Done quando viene rilasciata e non quando è pronta per il rilascio. La Sprint Review può essere fatta, come al solito, alla fine dello Sprint. Nella revisione dello Sprint verranno discussi tutti gli elementi di backlog completati durante lo sprint e il valore che aggiungono al prodotto rilasciato.
Rilasciare software per desktop
Ogni giorno usiamo applicazioni desktop per varie attività. Dalla modifica dei documenti, alla modifica di video e immagini. Che cosa si fa di solito per ottenere questo tipo di applicazioni? Si naviga in Internet, si trova un’applicazione che può soddisfare le nostre esigenze, si scarica e si installa sul nostro computer. In genere, in questo caso, gli aggiornamenti delle applicazioni sono meno frequenti degli aggiornamenti eseguiti per le applicazioni cloud per diversi motivi, dalla distribuzione dei pacchetti che può sovraccaricare i server che li ospitano, alla creazione e test del pacchetto, che possono richiedere del tempo. Naturalmente, anche in questo caso, è bene adottare DevOps e Scrum per raccogliere feedback rapidi da parte degli utenti finali sulle nuove funzionalità. La maggior parte delle volte non è possibile rilasciare software per fornire nuove funzionalità più di una volta al giorno come accade per le applicazioni cloud.
In questo caso, l’ambiente di produzione è il computer dell’utente e il software di produzione è il pacchetto distribuito agli utenti finali. Mentre su piattaforme cloud l’organizzazione proprietaria del software possiede anche gli ambienti di produzione, nel caso delle applicazioni desktop, l’ambiente di produzione è il computer portatile dell’utente finale. Non sarà possibile raccogliere metriche in tempo reale per inserirle nel ciclo di feedback dell’implementazione. Con l’autorizzazione dell’utente finale, sarà possibile raccogliere report di utilizzo e informazioni quando si verifica un arresto anomalo nell’applicazione, ma non di più.
In questo caso, i rilasci possono verificarsi dopo più Sprint. Tuttavia, è fondamentale avere un prodotto funzionante dopo ogni Sprint anche se il rilascio potrebbe non sempre avvenire alla fine dello Sprint.
Prodotti aziendali realizzati internamente
Quando un’azienda installa software sviluppato internamente su cloud privati o sull’infrastruttura del cliente, la maggior parte delle volte il software deve essere personalizzato in base alle esigenze aziendali. In questo caso, ci saranno diverse organizzazioni che lavorano sul software:
- Unità di sviluppo del prodotto
- Unità che si occupa del cliente
In questo caso, l’unità di sviluppo del prodotto rilascia il prodotto da personalizzare e l’unità dedicata al cliente ha la responsabilità di implementare e configurare il prodotto per esigenze le specifiche. Potrebbe non essere sempre possibile rimanere aggiornati all’ultima versione del prodotto.
Quando il prodotto viene sviluppato internamente, potrebbe esserci la possibilità di accedere ai server del cliente direttamente dagli ambienti dell’unità di sviluppo del prodotto. In questo caso, è possibile installare le patch per il prodotto direttamente quando vengono rilasciate. Quando viene creata una nuova patch sul prodotto, per motivi di sicurezza o per la risoluzione di bug, è possibile eseguire l’installazione automatica per tutti i clienti che utilizzano il prodotto.
Quindi, in questo caso, è possibile identificare due flussi DevOps:
- Dall’unità di sviluppo del prodotto agli ambienti di produzione del cliente
- Dall’unità che si occupa del cliente agli ambienti di produzione del cliente.
Bisogna porsi una domanda: è una buona idea avere 2 flussi paralleli che rilasciano sugli stessi ambienti di produzione?
Questi flussi paralleli se non coordinati nel modo giusto possono entrare in conflitto e tentare di eseguire installazioni simultanee nello stesso ambiente. Così, anche nel caso in cui l’Unità di Sviluppo del Prodotto e l’Unità che si occupa del Cliente, abbiano entrambi accesso agli ambienti di produzione del cliente, è comunque auspicabile che l’Unità che si occupa del Cliente abbia sempre il controllo su tutto ciò che accade negli ambienti di produzione del Cliente.
Rilasciare software aziendale
In questo caso, il rilascio può essere fatto alla fine di ogni Sprint o dopo qualche Sprint, per concordare con il cliente sulla cadenza di rilascio. Se il prodotto è business-critical, è necessario concordare la tempistica di rilascio per pianificare, se necessario, il giorno e l’ora in cui il sistema non sarà disponibile a causa dell’aggiornamento. Naturalmente, è necessario rilasciare durante lo Sprint quando un bug di produzione deve essere risolto.
Tuttavia non c’è una vera e propria regola, e dipende dal prodotto e l’area del prodotto su cui stiamo lavorando. Le aziende che utilizzano Scaled Agile preferiscono avere il rilascio di nuove funzionalità ogni due-quattro Sprint, mentre le correzioni di bug dovrebbero essere fatte il più presto possibile. E’ molto frequente ricevere e-mail con la richiesta, “da fare al più presto”, che aggiunge tanta pressione sul team. Naturalmente, è un compito del Product Owner mitigare queste situazioni e stabilire le priorità corrette per questo tipo di richieste che possono essere controproducenti per l’umore e la qualità.
Pensieri finali
In tutti i casi è bene adottare Scrum e DevOps nella misura consentita dal tipo di applicazione. È sempre una buona idea avere piccoli incrementi di prodotto rilasciabili, per raccogliere feedback veloci dal cliente finale. Scrum e DevOps sono nati per questo.
Massimizzare i benefici che derivano dalla collaborazione a tutti i livelli, dal team di sviluppo al Cliente, è un must per creare prodotti di successo.
Grazie per la lettura!!!
Se ti è piaciuto l’articolo puoi leggere di più nella sezione Agile