coreBOS Updater: niente più versioni

Siamo arrivati al terzo capitolo della storia di coreBOS (qui la prima e la seconda parte), in cui Joe Bordes spiega perché grazie coreBOS Updater, non ci sia più bisogno di rilasciare nuove versioni.

L’articolo originale è stato pubblicato sul blog ufficiale di coreBOS.

corebos updater 2.jpeg

Non rilasciamo molte versioni.

Potrebbe sembrare una cosa preoccupante, ma non lo è per un semplice motivo: siamo stati stregati dalla Scarlet Witch, che ci ha intimato: “Niente più versioni!” (questa è per gli appassionati di fumetti Marvel).

Alcuni anni fa coreBOS ha lanciato un nuovo concept: coreBOS Updater. Sapevamo cosa volevamo raggiungere, ma non avevamo idea dell’impatto che avrebbe avuto.

È venuto fuori che spostandoci su Git e sul reale open source, le modifiche sul codice tra le diverse installazioni di progetti basati su coreBOS sono diventate un gioco da ragazzi.

Git è uno strumento incredibile che ci ha permesso di eliminare quasi completamente le migrazioni: il complesso spostamento delle modifiche del codice da un’installazione all’altra è gestito da Git, tutto ciò che dobbiamo fare è sistemare alcuni piccoli conflitti, ma riusciamo a farlo così velocemente che spesso gli utenti non si accorgono neanche che è in corso una migrazione. È incredibile. È stata sia una rivelazione che una liberazione, perché finalmente siamo stati in grado di effettuare modifiche liberamente, facendo evolvere l’applicazione ad un ritmo molto più sostenuto e offrendo di conseguenza benefici a tutte le parti.

Mentre scoprivamo il fantastico senso di libertà e potere che ci dava questo nuovo approccio, coreBOS Updater è arrivato a legare le modifiche sul database di ogni versione del codice aveva bisogno, con il sistema di controllo Git. Improvvisamente eravamo in grado di distribuire ogni nuova funzionalità, di correggere errori e di effettuare modifiche sul database che chiunque poteva applicare facilmente, ma non solo, coreBOS Updater “conosce” lo stato di ogni codice e fa in modo che ogni database sia completamente sincronizzato con lo stato del codice:

Incredibile, potente e semplice!

Eravamo in grado di effettuare ogni tipo di modifica sull’applicazione in ogni momento. Ogni volta che volevamo, e alla velocità di cui avevamo bisogno. coreBOS Updater potrebbe persino gestire personalizzazioni private nello stesso modo, rendendo facile l’applicazione di cambiamenti per clienti con necessità particolari e documentandoli.

Da allora abbiamo imparato come funziona questo nuovo sistema, provandolo su installazioni differenti, valutandone l’impatto sul nostro lavoro quotidiano, comprendendo poco a poco come tutto fosse cambiato. Proprio come l’evento Marvel del 2004 ha avuto un impatto irreversibile sull’universo Marvel,

la vita dopo coreBOS Updater è cambiata completamente.

La potenza di coreBOS Updater e di Git che ora so e posso affermare con sicurezza che potremmo non rilasciare mai più un’altra versione ufficiale (!) e che se dovessimo farlo, sarebbe una mossa di puro marketing.

L’idea semplicissima è che grazie a Git e a coreBOS Updater tutto ciò che serve per avere la più recente versione del codice è scaricare da Git e applicare le modifiche di coreBOS Updater. Lo si può fare ogni volta che si vuole, fondamentalmente ogni volta che carichiamo una modifica, cosa che avviene quasi quotidianamente. Ecco perché sarebbe assurdo rilasciare nuove versioni: dovrei rilasciarne una ogni due giorni, e in questo momento saremmo approssimativamente alla versione 4000. Sarebbe un enorme spreco di tempo.

Non c’è quindi da preoccuparsi se non rilasciamo nuove versioni, di fatto lo stiamo facendo quasi ogni giorno e tutto ciò che bisogna fare per fruirne è tenere il codice sincronizzato con Git e coreBOS Updater!

Si può fare una comparazione con le applicazioni mobili o con quelle sul computer: ogni giorno ci sono aggiornamenti che vengono approvati e installati dall’utente senza che questi sappia, o che gli interessi, quale versione sta usando. coreBOS richiede che l’utente utilizzi git per aggiornare i suoi file, perché il codice può essere modificato secondo le sue specifiche esigenze: in questo si differenzia dalle App per smartphone, ma il concetto è lo stesso.

Se si vuole sapere quale versione si sta usando, lo si può chiedere a git. Questo comando darà l’informazione richiesta:

git log -1

Ho appena eseguito questo comando sulla mia installazione e ho ottenuto questa risposta:

commit 63329a1c6d34d55669d97e259c0b1ec70db4fc49

Author: Joe Bordes <joe@tsolucio.com>

Date:   Sat Apr 1 01:40:29 2017 +0200

style(Reports) eliminate warnings and format code

Git, come si può vedere, ha indicato la versione (63329a1c6d34d55669d97e259c0b1ec70db4fc49) e la data in cui è stata rilasciata.

Git è in grado di scaricare e applicare le specifiche modifiche necessarie a tenere il codice aggiornato.

Scaricando l’installazione direttamente da GitHub senza utilizzare il comando git clone, è possibile aprire il file vtigerversion.php e ottenere la stessa informazione.

Si può notare che i numeri identificativi di queste versioni non sono friendly per gli utenti, né lo sono in un’ottica di bisogni commerciali o di marketing, di conseguenza tendiamo a identificare determinati eventi importanti con numeri commerciali come, ad esempio, coreBOS7 che ha, tra le altre cose, anche il completo supporto di PHP7.

Grazie per aver letto questo articolo!

P.S. Ho notato trend simili in molti altri progetti su github. Non sarei affatto sorpreso se in un futuro vicino le versioni numeriche perdessero ogni significato e diventassero semplici strategie di marketing. Ad esempio, sto seguendo BackupPC. Hanno rilasciato la versione 4.0.0, annunciandola al mondo. Automaticamente, sono arrivate diverse segnalazioni di problemi e, di conseguenza, aggiornamenti del codice che sono stati accettati e installati (è come il vero open source funziona), quindi 20 giorni più tardi è arrivata la versione 4.1.0, poi la 4.1.1… appena sei giorni dopo! La questione è che potrebbero semplicemente evitare di perdere tempo a organizzare i nuovi rilasci e dire agli utenti di scaricare direttamente dal progetto github.

Advertisements

Posted on April 14, 2017, in Uncategorized. Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: