Herding Cats: lezioni apprese durante lo sviluppo per l'ambiente WordPress

Quando Elementor 3.0 è stato rilasciato più di un anno fa, nel 2020, lo abbiamo visto come un passo significativo verso un editor più veloce e significativamente più potente. Sebbene ciò sia vero, questa versione ha avuto anche conseguenze importanti e inaspettate: ha causato l'interruzione del funzionamento di un numero significativo di siti e, francamente, ha danneggiato la nostra reputazione. In seguito a questa versione, dovevamo trovare una serie di correzioni per far funzionare nuovamente questi siti. Inoltre, l'intera esperienza ci ha mostrato che dovevamo rivedere l'intera procedura di test e rilascio. Sebbene doloroso, questo processo sta dando i suoi frutti oggi, come si evince dallo straordinario calo dei problemi, specialmente quelli critici, tra il rilascio delle nostre versioni v3.0 e v3.4:

Ora, mentre ci avviciniamo al primo anniversario di Elementor 3.0, è un buon momento per guardare indietro ed esaminare le procedure che abbiamo messo in atto per garantire che i problemi che accompagnano il suo rilascio non si ripetano. Per essere il più trasparente possibile con la nostra community, vorrei esaminare il background dei problemi che circondano la versione 3.0, i passaggi che abbiamo compiuto nell'ultimo anno, come siamo stati in grado di garantire versioni stabili e cosa riserva il futuro. Ma prima, è importante comprendere un po' della storia di Elementor e le sfide che dobbiamo affrontare sviluppando un plug-in complicato e sofisticato all'interno dell'ambiente WordPress.

Elementor e la sfida di WordPress

Nel giugno 2016, quando abbiamo rilasciato la prima versione di Elementor, eravamo solo alcuni "bambini", a cui piaceva sviluppare plug-in e aiutare le persone a creare siti Web. Questo non è stato il nostro primo prodotto, avevamo già sviluppato alcuni plugin utilizzati dalla community di WordPress. Tuttavia, mentre lavoravamo su Elementor, ci siamo convinti che stavamo sviluppando qualcosa di speciale. Come si è scoperto, avevamo ragione: solo pochi mesi dopo la nostra prima versione, decine di migliaia di utenti avevano già installato Elementor e lo stavano utilizzando per creare siti Web in tutto il mondo.

Da allora, la nostra azienda è cresciuta sotto ogni aspetto, con più sviluppatori, più utenti e più funzionalità. Con questa crescita è arrivata una serie di nuovi problemi, incluso un crescente deficit tecnologico mentre ci siamo concentrati su questioni urgenti, mettendo da parte problemi importanti, ma più banali.

Affrontare questi problemi è stato reso ancora più difficile dalla sfida generale posta dalla natura dell'ambiente WordPress.

Come piattaforma aperta, WordPress offre una serie di grandi vantaggi per gli sviluppatori. Ci sono alcuni blocchi stradali che monitorano e rallentano i rilasci. I concetti vengono immaginati, sviluppati e aggiunti al repository. Gli utenti provano, testano e giudicano questi prodotti, con il mercato che decide quali prospereranno e quali falliranno. Tuttavia, questa velocità e semplicità hanno un prezzo.

C'è poca uniformità nell'ambiente WordPress e nessun flusso di lavoro ordinato. I creatori di siti Web sono liberi di definire l'ambiente dei propri siti utilizzando una vasta gamma di plug-in, temi, ecc. Ciò significa che i siti WordPress contengono innumerevoli combinazioni di plug-in, temi e configurazioni del server.

Inoltre, la semplicità del processo di rilascio e la mancanza di robusti strumenti di distribuzione significano che gli sviluppatori di WordPress non sono in grado di sfruttare concetti di rilascio moderni come CI/CD, Canary Deployment e Feature Flags.

Sebbene l'apertura faccia parte della bellezza di WordPress, la moltitudine intrinseca di configurazioni di siti e server presenta agli sviluppatori una vera sfida quando si tratta di tenere conto dei conflitti dei plug-in e di problemi specifici del server.

Nel nostro caso, poiché Elementor è stato utilizzato per un numero sempre maggiore di siti Web, la necessità di supportare tutte queste diverse combinazioni stava rallentando il nostro programma di rilascio e ci ha persino reso titubanti nello sviluppo di nuove funzionalità. Inutile dire che questa situazione era inaccettabile e dovevamo scuotere le cose.

Sviluppare nuove funzionalità senza rompere il vecchio

Tutti i fattori di cui sopra ci hanno lasciato con il dilemma di come potremmo continuare a sviluppare e migliorare senza avere un impatto negativo sul lavoro di coloro che si affidavano già a Elementor?

Abbiamo iniziato implementando alcune piccole modifiche nel nostro processo di rilascio. In Elementor 1.5, abbiamo iniziato a offrire agli sviluppatori l'accesso alle versioni Beta. Lo abbiamo fatto tramite Github e altre comunità che ci hanno permesso di ricevere feedback prima di un rilascio, indicando come questa versione interagiva con un'ampia varietà di combinazioni di plugin/tema/ambiente e avvisandoci di eventuali incompatibilità all'inizio. Questo approccio ha funzionato bene per un po', ma man mano che Elementor cresceva, ancora di più, abbiamo scoperto che non era abbastanza.

A questo punto, avevamo superato la soglia di cinque milioni di installazioni. Sebbene fosse un risultato incredibile, significava anche che ora eravamo responsabili del corretto funzionamento di tutti questi siti Web.

Le cose sono finalmente arrivate al culmine con il rilascio di Elementor 3.0. In questa versione, abbiamo deciso di eliminare alcune vecchie funzioni apparentemente obsolete, rimuovendo gli elementi DOM per aumentare le velocità di caricamento. Questo è stato, almeno in parte, in risposta a lamentele giustificate secondo cui stavamo sovraccaricando inutilmente il sistema.

Sfortunatamente, questa modifica ha causato la rottura di un certo numero di siti, che facevano affidamento sul codice che avevamo eliminato, durante l'aggiornamento. Nonostante i nostri sforzi per coinvolgere sviluppatori di terze parti nel processo, questi bug erano rimasti sconosciuti e dovevamo agire rapidamente per correggere la situazione. Alla fine, siamo stati in grado di farlo rendendo opzionali parti dell'aggiornamento, ma non prima che alcuni membri della nostra comunità avessero avuto la loro fiducia nella stabilità del nostro plugin, scossi.

Questa esperienza ci ha costretto a dare uno sguardo lungo e approfondito al nostro processo di sviluppo, con l'obiettivo di apportare una serie di importanti cambiamenti. I nostri processi semplicemente non erano adatti per un'azienda delle nostre dimensioni e base di installazione. La prima, e forse la mossa più ovvia, è stata quella di aumentare le dimensioni e la portata del nostro team di controllo qualità, ma questo ci ha comunque lasciato alle prese con una serie di problemi in sospeso:

• Verifica della compatibilità di una versione con innumerevoli configurazioni del sito
• Garantire la compatibilità con le versioni precedenti con oltre cinque milioni di siti esistenti
• Verifica della compatibilità di centinaia di estensioni Elementor di terze parti

Per affrontare tutti questi problemi, dovevamo portare metodi di sviluppo software più aggiornati nel mondo di WordPress.

Il ciclo di feedback

Uno dei grossi problemi che devono affrontare lo sviluppo, in generale, è che gli utenti sperimentano gli aggiornamenti solo una volta che sono stati rilasciati. Ciò significa che una funzionalità è già stata progettata, sviluppata e rilasciata quando riceviamo qualsiasi feedback dagli utenti. Nel nostro caso, trattando centinaia di centinaia di estensioni e plugin di terze parti, il problema di questo ciclo di feedback è ancora più importante.

Nella ricerca di modi per abbreviare questo ciclo di feedback, abbiamo esaminato il modo in cui gli sviluppatori di browser affrontano problemi abbastanza simili ai nostri: devono anche garantire la compatibilità con innumerevoli pagine Web, app, estensioni e altro di terze parti.

Ad esempio, abbiamo esaminato il sistema sviluppato da Google per il loro browser Chrome. In qualsiasi momento, gli sviluppatori hanno accesso a tre versioni del browser: una versione beta, una versione per sviluppatori e una versione notturna. Ciò significa che gli sviluppatori danno un'occhiata in anteprima alle nuove funzionalità di Chrome e possono iniziare a fornire feedback a Google molto prima che la versione venga rilasciata ufficialmente.

Applicando queste lezioni al nostro plug-in, Elementor ha iniziato a rilasciare la propria edizione per sviluppatori: Elementor Beta (Developer Edition), disponibile dal repository di WordPress e rivolta agli sviluppatori interessati a dare un'occhiata alle nostre nuove funzionalità "a caldo", per così dire.

Per noi, ovviamente, traiamo vantaggio dalla ricezione di avvisi precoci di problemi di compatibilità. L'edizione per sviluppatori non solo consente agli utenti di accedere a tutte queste nuove funzionalità, ma c'è anche un collegamento diretto a Github per segnalare bug. Ciò significa che possiamo implementare continuamente nuove funzionalità e ricevere feedback su di esse, senza mettere in pericolo i siti Web esistenti. Per gli sviluppatori, ciò consente loro di prepararsi per le prossime versioni ufficiali con largo anticipo, aiutando a prevenire i propri problemi di compatibilità e dando loro anche l'opportunità di fornire feedback sul prodotto e tecnico mentre la funzionalità è ancora in fase di elaborazione.

Va notato che le versioni dell'edizione per sviluppatori vengono eseguite in parallelo al normale - alfa, beta, RC e produzione - un processo utilizzato per sviluppare le versioni di Elementor. Quando sviluppiamo una nuova funzionalità, non appena è abbastanza stabile da poter essere utilizzata, ma mentre è ancora in alpha, la aggiungiamo all'edizione per sviluppatori. In questo modo, i nostri sviluppatori possono darci un feedback, anche prima che la funzione raggiunga la versione beta. Significa anche che l'edizione per sviluppatori include funzionalità che non hanno raggiunto la fase beta.

In sostanza, la fase beta è riservata a un processo di debug deliberato, mentre l'edizione per sviluppatori viene aggiornata più frequentemente, incorporando funzionalità nelle primissime fasi.

Dalla sua introduzione, l'edizione per sviluppatori si è rivelata un grande successo, ottenendo oltre 40mila installazioni in meno di un anno.

Presentazione delle funzionalità "sperimentali".

Nel corso degli anni, un altro concetto che gli sviluppatori hanno abbracciato sono le flag di funzionalità, che sono particolarmente diffuse nel mondo di SaaS. L'idea generale è che questi flag di funzionalità consentano agli sviluppatori di testare nuove funzionalità attivandole e disattivandole per diversi segmenti di utenti per testarle e vedere come funzionano.

Come accennato in precedenza, molti dei problemi derivanti dalla versione 3.0 erano dovuti alle nuove funzionalità che eliminavano il codice precedente. Per evitare questo tipo di problemi, abbiamo deciso di adottare un approccio simile a quello dei flag di funzionalità.

A partire da Elementor 3.1, abbiamo iniziato a rilasciare le nuove funzionalità con maggiore attenzione, contrassegnandole come "sperimentali". Ciò include un sistema di introduzione di nuove funzionalità in più fasi. In questo sistema, una funzionalità appena sviluppata verrà contrassegnata come "Alpha". Ciò significa che è disattivato, per impostazione predefinita, su tutti i siti. Man mano che si dimostra più stabile, diventa una "Beta", il che significa che ora è attivato, per impostazione predefinita, per i nuovi siti e disattivato per i siti esistenti. Una volta che siamo sicuri che sia stabile, viene attivato, per impostazione predefinita, per tutti i siti. Anche allora, ci sarà un'opzione per gli utenti per disattivare la funzione, per un periodo di tempo limitato.

Questo sistema ci consente di continuare a sviluppare Elementor, aggiungendo sia il suo set di funzionalità che la sua velocità, consentendo ai creatori di accettare o meno questi nuovi aggiornamenti in base alle esigenze del loro sito. Questo aiuta anche i creatori ad aggiornare i loro siti consentendo loro di adottare nuove funzionalità con maggiore attenzione.

Tag di compatibilità

La crescita della community di sviluppatori molto attiva di Elementor è stata un grande motivo di orgoglio, ma ha anche posto le proprie sfide. Gli sviluppatori di terze parti hanno creato centinaia di estensioni, temi, kit e widget, tutti basati sulla nostra tecnologia esistente.

Per supportare gli sviluppatori di questi componenti aggiuntivi di terze parti, abbiamo utilizzato il blog degli sviluppatori e la nostra mailing list per avvisarli in anticipo sulle modifiche che stavamo apportando all'API e sui deprecati. Tuttavia, come accennato in precedenza, abbiamo scoperto che questo non era abbastanza. Molti dei problemi che stavamo riscontrando con le nuove versioni presentavano problemi di compatibilità a causa di questi componenti aggiuntivi di terze parti. Il nostro plug-in è stato considerato instabile, non a causa della nostra tecnologia, ma a causa di queste incompatibilità di terze parti.

Ancora una volta, abbiamo guardato a ciò che gli altri stavano facendo per trarre ispirazione. In questo caso, WooCommerce e il loro approccio al lavoro con sviluppatori di terze parti. A partire dalla nostra versione 3.1, abbiamo avviato un sistema in cui sviluppatori di terze parti certificano che le loro estensioni sono compatibili con la nuova versione (Ulteriori informazioni). Quindi, quando agli utenti viene data la possibilità di aggiornare Elementor, viene loro presentato un elenco di estensioni di terze parti che stanno utilizzando e se sono stati certificati o meno come compatibili con la nuova versione di Elementor. In questo modo gli utenti possono prendere una decisione informata sull'aggiornamento.

Verso un futuro ancora migliore

Delineando queste sfide e i cambiamenti che abbiamo implementato, spero di averti dato un'idea di com'è sviluppare un prodotto per l'uso mondiale, in un ambiente open source e in continua evoluzione. Come parte di questa cultura dell'open source, è fondamentale essere trasparenti con la nostra comunità di utenti e sviluppatori, a maggior ragione man mano che l'azienda cresce e diventa più difficile mantenere un "tocco personale". Non solo perché il dolore dei nostri utenti è il nostro dolore, ma perché è il modo migliore per Elementor di rimanere uno strumento stabile, aperto alla più ampia gamma di utenti possibile.

Crediamo fermamente che i cambiamenti che abbiamo implementato abbiano contribuito e continueranno a contribuire alla crescita e al successo di Elementor. Tuttavia, siamo anche consapevoli che c'è ancora del lavoro da fare e che la comunicazione tra Elementor e la comunità di Elementor deve rimanere aperta e persino migliorata. Ad esempio, stiamo aggiornando il nostro sito di risorse per sviluppatori, fornendo una documentazione di facile utilizzo per aiutare gli sviluppatori a personalizzare e sviluppare Elementor.
Ma forse il passo più importante che abbiamo fatto per migliorare la comunicazione è creare l'Elementor Community Hub. Qui, i creatori di siti Web di tutto il mondo possono riunirsi per scambiare idee tra loro e con noi, collaborando insieme per rendere Elementor il meglio che può essere. Dopotutto, come suggerisce il vecchio proverbio, allevare i gatti può essere quasi impossibile, ma quando lavorano insieme, si chiama Pride.