Development Workflow & Environments

Modifiche al solo front-end

Esempio: viene richiesto di cambiare il layout di un componente di frontend. Le informazioni visualizzate rimangono identiche.

Se occorre modificare esclusivamente il frontend, senza modifiche lato backend, è sufficiente creare una versione dell'app di frontend e farne un deploy indipendente. Ad esempio, se si usa Vercel è sufficiente creare un'altra app che avrà una URL diversa. In questo modo è possibile mostrare al committente la nuova versione. Se il sito è pubblico, si consiglia di proteggerlo con una password nota solo alle persone che dovranno dare un feedback. Come implementare questa protezione resta a carico dello sviluppatore di frontend. Per quest'attività è sufficiente utilizzare correttamente Git, ad esempio creando un feature branch per la nuova versione dell'app, mantenendo il branch attualmente in produzione per eventualità attività correttive finché la versione non è stata approvata.

Una volta che la modifica è stata approvata è possibile effettuare il deploy del nuovo branch sul server/app di produzione. Il CMS, in questa situazione, non è impattato.

Modifiche al sito in termini di contenuti e asset digitali

Esempio: il committente chiede di cambiare l'immagine di un banner o di cambiare i testi del sito.

In questo caso direttamente sulla property del sito e si utilizza la doppia modalità preview/public dell'API del CMS, che l'app di frontend dovrà onorare correttamente. L'app di frontend onora la doppia modalità preview/public in modi diversi a seconda della tecnologia utilizzata.

Ad esempio, NextJS supporta il preview mode che permette di avere un'unica istanza dell'applicazione che funziona in due modalità.

In ReactJS, VueJS e altre tecnologie client side, occorre avere una doppia istanza dell'applicazione in quanto non sarebbe possibile proteggere il token che permette di accedere alle API di preview. Si ricorda che se questo token viene esposto agli utenti finali, un utente potrebbe potenzialmente accedere ad informazioni che non sono state ancora pubblicate. In questi casi la seconda istanza dell'applicazione, che sarà configurata con il token di preview per accedere all'API dovrà essere in un ambiente protette accessibile solo ad utenti autorizzati (es. basic authentication, rete privata, etc.)

Tornando all'esempio di partenza, l'amministratore del CMS può cambiare immagine e testi nel CMS, visualizzando l'anteprima delle modifiche, senza pubblicarle in produzione. Una volta fatte le modifiche, gli approvatori possono visualizzarle direttamente nel CMS. E' anche possibile condividere l'anteprima delle modifiche ad utenti che non sono del CMS tramite la generazione di una URL di anteprima.

Modifiche al content model del CMS

Esempio: per una componente di frontend che mostra un'immagine, viene richiesto di aggiungere una seconda immagine. In questo caso, è necessario modificare il content model del CMS, in quanto la componente del CMS che corrisponde alla componente del frontend dovrà avere un nuovo attributo.

Entriamo qui in questa casistica se le modifiche al frontend richiedono modifiche al content model sul CMS, ad esempio aggiungendo/togliendo degli attributi dai content types.

Il workflow in questi casi è leggermente più complesso. E' necessario creare una property con una nuova versione del sito. Per farlo:

• clonare la property e aggiungere al nome la versione (es. "sito_v1" > "sito_v2"). Property "sito_v1" resta connesso al sito di produzione, mentre a "sito_v2" si aggancia un sito di anteprima "v2" accessibile ad un numero ristretto di utenti approvatori (ad esempio, utilizzando una password).
• nella property "sito_v2" si effettuano tutte le modifiche in termini content model e, contestualmente, si allinea il frontend "v2" a tali modifiche.
• una volta che tutte le modifiche sono state approvate, si fa il deploy produzione di "sito_v2" e si interviene a livello di DNS per fare in modo che il sito ufficiale punti a "sito_v2". Occorre anche rimuovere la password di protezione.

Modifiche al CMS

Esempio: viene richiesto di aggiungere feature mancanti o personalizzazioni al CMS.

Se vengono richieste personalizzazioni al CMS in termini di funzionalità che devono essere aggiunte o personalizzazioni, è necessario un ambiente di test separato per il CMS stesso. Questo è l'unico caso in cui è necessario un doppio ambiente CMS.