Da anni mi interrogo su quale sia la soluzione più veloce e duttile per effettuare deploy su progetti seguiti da piccoli team di sviluppo che lavorano in PHP. Nel caso di piccole aziende effettuare dei deploy su progetti basati su framework complessi come Magento 2 rappresenta sempre un mezzo dramma, una grande perdita di tempo per eseguire sempre la medesima procedura e un’operazione in cui l’errore umano è all’ordine del giorno.

C’è da dire poi che la difficoltà non sta unicamente nel deploy in sé e per sé ma soprattutto nella gestione di più deploy realizzati da più persone di uno stesso team di sviluppo sul medesimo progetto.
Nel dettaglio nasce un problema sulla concorrenza dei deploy: mettere un flag per far fallire in partenza nuovi deploy nel caso ce ne sia già un’altro in esecuzione non è una soluzione accettabile.
Bisogna identificare un sistema semplice che permetta ai vari sviluppatori di gestire i deploy ed avere immediata visibilità su quali siano andati a buon fine, quali siano in esecuzione o in attesa.
Considerato ciò trovare un software per effettuare i vari comandi necessari alla creazione di una release e realizzarne il live non è sufficiente. Serve qualcosa che amministri questo software, che permetta a più persone di consultarlo e manipolarlo… una GUI agile e possibilmente facile da manipolare nel caso serva personalizzare il flusso di deploy e/o la sua gestione.

CHE SOFTWARE CONVIENE ADOTTARE?

Ci sono varie soluzioni open-source sul mercato come ad esempio Jenkins, tuttavia credo che la vera sfida stia nel dare un strumento che sia vicino al know-how del team che dovrà utilizzarlo.
Questo perchè nel caso il software in oggetto non si comporti esattamente come il team vuole si renderà necessario modificarlo. Va da sé che se il linguaggio che più utilizzi è PHP imparare Java per fare delle modifiche a quello che poi è “solo il sistema di deploy” diventa stressante.
Questo senza contare che poi in Jenkins dovremo codificare ed ordinare le operazioni che il deploy dovrà eseguire, quindi scrivere un Jenkinsfile e tutti i relativi “stage” con una sua propria sintassi. Impossibile? No, ma è veramente la via più semplice e pratica per il nostro team di dev esperti nello sviluppo in PHP? Io credo di poter dire che No, non è la soluzione più immediata.

LA MIA SCELTA

Mi sono concentrato nel capire quali fossero le soluzioni scritte in PHP per sviluppatori PHP ed ho trovato un grande amico in deployer, ottimo per scrivere le nostre pipelines in PHP, ricco di soluzioni già pronte per integrarsi anche con altri software, processi e strumenti e di recipes per diverse tipologie di software PHP.
Come scritto sopra però codificare il processo di deploy per eseguirlo da una shell non è sufficiente, serve la GUI per gestirlo.
Non c’è molto in PHP devo dire, anzi nulla, solo un programmino in Laravel scritto da un dev Giapponese “Yuta Nagamiya“. Questo software è webloyer e fa buona parte di ciò che serve ad un piccolo team di sviluppo, tra cui la gestione delle code dei deploy. Un piccolo particolare: L’ultimo commit risale a Maggio 2020, utilizza Laravel 5.2 (versione rilasciata nel 2015) e non è compatibile con Deployer 7 (la versione 7.0 è stata rilasciata nel Luglio 2022).
E’ stato doveroso aggiornare webloyer ad una versione più recente di Laravel e rendendo possibile l’utlizzo di Deployer alle sue ultime versioni, ho quindi realizzato l’aggiornamento della piattaforma: https://github.com/dadolun95/webloyer

CONSIDERAZIONI, PRO E CONTRO DI WEBLOYER

Da poco tempo ho trovato necessario l’utilizzo di webloyer in quanto lavoravo quasi sempre da solo e devo dire che l’adozione e configurazione è stata semplice. Nel dettaglio sono riuscito a gestire gli eventi push di bitbucket tramite webhook e collegarli a deploy automatizzati in webloyer. Collegare in seguito le notifiche sulla chat interna di slack è stato semplice in quanto ci sono già le recipe pronte su deployer. Modificare webloyer se si ha una buona conoscenza di PHP è relativamente semplice, sarebbe interessante migliorarne alcuni aspetti come la gestione del log di deploy, limitare l’accesso degli utenti unicamente a specifici progetti in webloyer.
Nei contro c’è sicuramente da annotare il fatto che la repo del “nuovo” webloyer non è seguita come la repo di Jenkins tuttavia credo che sia un compromesso ottimo per un piccolo team che vuole realizzare un sistema di CI/CD senza spendere mesi in ricerca e sviluppo e/o configurazione di tool distanti dal proprio linguaggio principe.
Quindi mi rivolgo a voi amanti del PHP e sviluppatori Magento2, se siete interessati contattatemi sarò lieto di fornirvi documentazione tecnica su come configurare le recipe deployer in webloyer, se poi voleste contribuire alla repo ancora meglio!