Implementazioni graduali per sviluppatori di plugin e temi WordPress: evitare un "rilascio di cluster"
Pubblicato: 2020-12-23Ricordi l'ultima volta che hai rilasciato una nuova versione del tuo plugin o tema WordPress per scoprire rapidamente di aver erroneamente aggiunto un nuovo bug importante che è sfuggito alle crepe della sequenza di test?
Yoast SEO 3.0 ha rotto molti siti Web nel 2015. Elementor 3.0 ha fatto lo stesso quest'anno. E questi sono solo due esempi in cima alla mia testa di aziende fantastiche nel nostro spazio con oltre 100 dipendenti e personale QA dedicato (e no, non è correlato alla versione 3.0, ma forse è un segno per saltare quella versione nel tuo software; )).
Che tu sia un programmatore autodidatta o un ingegnere del software, uno sviluppatore indipendente o parte di un grande negozio di plugin/temi, tutti abbiamo a che fare con i bug. È una parte inevitabile dello sviluppo del software.
Indipendentemente dalle fantastiche automazioni CI/CD/test che metti in atto, non sarai mai in grado di testarle tutte. Il numero di configurazioni del server (PHP, MySql, caching, web server), versioni WP, combinazioni di plugin e temi... è tutto infinito.
Ed è controintuitivo. Più popolari e stabili diventano i tuoi prodotti, maggiori sono le possibilità di un temuto rilascio "Clusterbug", che prosciugherà il tuo supporto, potrebbe avere un impatto significativo sulla fiducia e la fedeltà dei tuoi clienti e potenzialmente danneggiare la reputazione generale del marchio.
Anche se non puoi evitare i bug, puoi, e sicuramente dovresti, mitigare il rischio il più possibile.
Se hai uno smartphone, probabilmente hai notato che alcuni dei tuoi amici ricevono aggiornamenti Android/iOS giorni, settimane, a volte anche mesi prima che tu li riceva. Non è una coincidenza, e no, non è niente di personale contro di te. È un processo di distribuzione progressiva intenzionale chiamato Staged Rollouts che aiuta aziende come Apple a spedire importanti aggiornamenti software a oltre un miliardo di dispositivi.
Sì, un miliardo!
Riesci anche a comprendere la quantità di responsabilità che una versione leader di Apple avrebbe sulle spalle se dovessero inviare un aggiornamento live a 1,5 miliardi di dispositivi mobili contemporaneamente? non posso. Scommetto che nessun uomo sano di mente accetterebbe di assumersi una tale responsabilità.
Quindi, come funziona il meccanismo Staged Rollouts? Come puoi implementarlo? E cosa sta aspettando WordPress.org? Questi sono gli argomenti che tratterò di seguito.
Cosa sono le implementazioni graduali per i plugin e i temi di WordPress?
Le implementazioni graduali ti consentono di specificare il numero (o la percentuale) di siti Web su cui desideri implementare una nuova versione. Un meccanismo di implementazione graduale ti consente di iniziare il tuo ciclo di rilascio con un'esposizione limitata e quindi aumentarlo in modo incrementale mentre monitori il supporto e il feedback, creando così fiducia nella tua versione per te e per i tuoi utenti.
Quali sono i vantaggi delle implementazioni graduali?
Invece di rischiare l'intera base di installazione con il rilascio di potenziali bug, conflitti con plugin/temi di terze parti o persino problemi di interfaccia utente/UX, puoi rilasciare versioni progressivamente, riducendo al minimo il numero di persone e siti Web che verranno esposti a problemi imprevisti. Una volta risolti tutti i problemi e i bug scoperti durante il processo di implementazione, la stragrande maggioranza dei tuoi utenti verrà esposta a una versione "matura" e molto più stabile.
Utilizziamo aggiornamenti continui per garantire la qualità delle nostre nuove versioni. Se si verifica un problema con una nuova versione, possiamo identificarlo rapidamente e solo un piccolo sottoinsieme di utenti sarebbe stato interessato.
John Turner, fondatore di SeedProd
L'uso di implementazioni graduali è LA migliore pratica per il rilascio responsabile del software, un processo seguito da molte aziende (indipendentemente dalle dimensioni) al di fuori della bolla WP.
C'è una grande opportunità per la comunità di WordPress di sfruttare le implementazioni a fasi, di cui parlerò tra poco.
I programmi beta sono simili alle implementazioni graduali?
Configurare un programma beta per il tuo prodotto WordPress è un ottimo inizio, ma è ben lungi dall'essere efficace come le implementazioni graduali e ha uno scopo e una dinamica fondamentalmente diversi.
A meno che il tuo plugin o tema non sia estremamente popolare e abbia una vasta comunità, è piuttosto difficile reclutare un gruppo beta statisticamente sufficiente poiché solo una piccola parte di utenti sarà interessata a partecipare. Anche se eccelli nel reclutare un gruppo decente di beta-tester, devi fare affidamento sulla loro disponibilità e buona volontà per testare il prodotto, e quindi sperare che facciano lo sforzo extra per segnalare i problemi che riscontrano.
Quante persone pensi che vedranno attraverso questo intero processo? Non molti.
Il beta testing è un processo di pre-produzione in cui i tuoi sforzi di supporto sono completamente controllati e i tester si aspettano di avere problemi con le versioni beta. Pertanto, le aspettative dei tester sulla qualità non rappresentano il sentimento generale della tua base di utenti.
Inoltre, un programma Beta responsabile avviserà i suoi tester di evitare di utilizzare versioni beta in ambienti di produzione, quindi il beta-testing non simula realmente i siti Web di produzione live.
Come gestire una versione di rollout graduale per il tuo plugin o tema WordPress?
Nell'ambito della mia ricerca su Staged Rollouts, ho avuto la possibilità di incontrare Amir Helzer e imparare dai loro oltre 2 anni di esperienza nell'utilizzo di Staged Rollouts con WPML e Toolset, plug-in in esecuzione su oltre 1.000.000 di siti Web WordPress.
Ecco cosa ha condiviso Amir sulla loro implementazione Staged Rollouts:
Quando un sito Web installa uno qualsiasi dei nostri plugin, disegniamo un numero casuale compreso tra 1 e 100 e lo memorizziamo nel database del sito per ricordarlo. Questo metodo essenzialmente divide i siti Web in 100 contenitori in modo casuale.
Quando una versione è pronta per essere pubblicata, diventerà disponibile in modo incrementale solo per un singolo bin selezionato. Ogni giorno aumentiamo l'esposizione della pubblicazione a un ulteriore 5% di siti Web nel cestino designato. E risolvi e correggi i problemi in arrivo mentre procediamo.
Per diversificare gli ambienti utilizzando la versione aggiornata ed evitare di avere ripetutamente le stesse "vittime" di rilascio anticipato, Amir ha confermato che ogni nuova versione va prima a un diverso bin di utenti.
Questo approccio significa anche che un ciclo di rilascio medio impiega circa un mese per essere disponibile per ogni utente.
Ci vuole tempo prima che le persone vedano una nuova versione disponibile in WP Admin e aggiornino la loro versione. E anche dopo che lo fanno, possono volerci giorni prima che scoprano un problema.
Con la dimensione del nostro pubblico, inevitabilmente, ogni pubblicazione presenta alcuni problemi. Il nostro obiettivo principale è assicurarci di evitare di introdurre nuovi problemi e, se lo facciamo, disponiamo di un processo affidabile per risolverli.
Il ciclo di rilascio è davvero lungo, ma anche se, nel peggiore dei casi, c'è qualche bug pazzesco che ci siamo persi durante i test, il 95% dei nostri utenti non è nemmeno a conoscenza di tutto il dramma, poiché non è esposto al rilascio finché non è stabile.
Amir ha anche sottolineato l'importanza della sincronizzazione con l'intero team prima dei rilasci, in particolare l'assistenza clienti e lo sviluppo. In questo modo, i membri del team possono concentrarsi maggiormente sui ticket attivati a causa di problemi relativi al rilascio in corso, con l'obiettivo di controllare, confermare e risolvere problemi validi e rilasciare patch il più rapidamente possibile.
Abbiamo tre livelli di supporto nel nostro team. Il livello 1 esaminerà il problema, convaliderà che si tratta in realtà di un problema relativo al rilascio del plug-in riproducendolo. Quando un caso sembra correlato alla nuova versione, passa al livello 2, che eseguirà il debug del problema per verificare che sia effettivamente correlato alla versione e individuare le parti rilevanti nel codice che attiva il problema. Se convalidato, lo sviluppatore responsabile di quel codice riceverà immediatamente una notifica per dare la priorità a una correzione.
OnTheGoSystems è una grande azienda con quasi 100 dipendenti, quindi è logico che abbiano perfezionato il loro processo di implementazione graduale. Ma, anche come sviluppatore di prodotto singolo con un livello di supporto (tu e te stesso), l'intuizione di Amir può insegnarci che è fondamentale allocare risorse dedicate alle versioni. È buona norma dare la priorità ai ticket di supporto che anche "puzzano" per essere correlati alla tua nuova versione e ridurre il più possibile l'esposizione a nuovi problemi.
Perché non ci sono (quasi) plugin o temi che supportano le implementazioni graduali?
In preparazione alla stesura di questo articolo, ho provato a chiedere alla community di vedere chi sta utilizzando le implementazioni graduali al fine di ottenere feedback sulla propria esperienza, su ciò che hanno appreso, ecc.
Non sorprende che ho trovato solo due società WordPress nella mia rete che hanno impostato implementazioni graduali come parte del loro ciclo di rilascio. Molti sviluppatori non conoscevano nemmeno il concetto e gli altri non lo usano poiché la loro soluzione di distribuzione non lo supporta (o potrebbero aver pensato di svilupparlo e non hanno tempo).
La maggior parte degli sviluppatori di plugin e temi che non vendono tramite Freemius vendono dal proprio sito Web tramite EDD o WooCommerce, che entrambi non supportano le implementazioni graduali. Anche coloro che vendono attraverso mercati come CodeCanyon e ThemeForest non hanno una soluzione pronta all'uso e molto probabilmente non l'avranno mai.
Anche gli sviluppatori che sono a conoscenza del concetto non hanno altra scelta che sviluppare il proprio meccanismo per supportare Staged Rollouts. Questo sviluppo infrastrutturale è in genere molto difficile da stabilire per priorità all'interno di un'azienda di prodotti.
Iscriviti e prendi una copia gratuita del nostro
Libro di affari del plugin di WordPress
Esattamente come creare una prospera attività di plugin per WordPress nell'economia degli abbonamenti.
Condividi con un amico
Inserisci l'indirizzo email del tuo amico. Gli invieremo solo questo libro via email, onore dello scout.
Grazie per aver condiviso
Fantastico: è stata appena inviata una copia di "The WordPress Plugin Business Book". . Vuoi aiutarci a spargere la voce ancora di più? Vai avanti, condividi il libro con i tuoi amici e colleghi.
Grazie per esserti iscritto!
- abbiamo appena inviato la tua copia di "The WordPress Plugin Business Book" a .
Hai un errore di battitura nella tua email? clicca qui per modificare l'indirizzo email e inviare nuovamente.
In che modo le implementazioni graduali ti danno un vantaggio commerciale?
Dal momento che quasi nessuno sfrutta le implementazioni a fasi al momento, se inizi a utilizzare le implementazioni a fasi e le commercializzi correttamente sul tuo sito Web per far sapere ai visitatori che hai cicli di rilascio responsabili, ti dà sicuramente un vantaggio competitivo e aumenta la fiducia nel tuo prodotto /marca!
Se analizzi il mercato dal punto di vista di uno sviluppatore, noterai che molti sviluppatori seguono da vicino i loro concorrenti e di solito fissano i loro prezzi all'interno della fascia di prezzo del mercato nel loro verticale, il che porta a prodotti WordPress concorrenti che offrono funzionalità simili nella stessa fascia di prezzo.
Dal punto di vista dell'acquirente, ciò significa che spesso si tratta di scegliere il prodotto da acquistare perché hanno tutti caratteristiche e prezzi comparabili. Ma, quando si valutano diversi plugin che costano lo stesso e, dare o prendere, hanno le stesse caratteristiche, non saresti propenso ad andare con il prodotto che offre Staged Rollout sapendo che le sue versioni di produzione dovrebbero essere più stabili rispetto ai concorrenti?
Le implementazioni graduali aumentano la fiducia nel tuo prodotto e nella tua attività. È un vantaggio su cui puoi capitalizzare prima che le implementazioni a fasi diventino una pratica standard (cosa che spero davvero che lo facciano).
Freemius ora supporta le implementazioni graduali per plugin e temi a pagamento
Siamo entusiasti di essere i pionieri degli Staged Rollouts nell'ecosistema di plugin e temi premium di WordPress. I nostri partner di vendita possono ora rilasciare aggiornamenti in modo sicuro, affidabile e affidabile, con un contraccolpo minimo per i loro utenti o risorse di supporto/sviluppo.
Sappiamo quanto possano essere impegnative e snervanti le major release, soprattutto perché c'è sempre il potenziale rischio di avere un impatto negativo sul tuo marchio dopo una release "Clusterbug".
Con Staged Rollouts in atto, c'è una rete di sicurezza per la sostenibilità e la difendibilità del marchio dei nostri partner e allevia lo stress non necessario associato ai rilasci per una vasta base di utenti.
Questo va di pari passo come vantaggio per i clienti dei nostri partner. Quando gli utenti acquistano prodotti venduti tramite Freemius, ora possono avere la certezza che stanno optando per una soluzione basata su Staged Rollouts e possono aspettarsi versioni molto più stabili da plugin e temi premium che utilizzano il meccanismo.
Se vendi con Freemius, ecco come utilizzare correttamente il nostro meccanismo Staged Rollouts.
In che modo Freemius ha implementato le implementazioni graduali?
Ogni sito Web che attiva una licenza per sbloccare un plug-in o un tema premium ottiene un record nel nostro database. La prima cosa che abbiamo fatto è introdurre una nuova proprietà last_served_update_version per memorizzare l'ultima versione del prodotto che è stata resa disponibile per un sito web.
Quindi, abbiamo arricchito la tabella responsabile della memorizzazione dei dati di rilascio con due nuove proprietà: limit , uniques .
Quando uno sviluppatore contrassegna una versione come rilasciata, gli verrà visualizzata la seguente finestra di dialogo, che consente loro di impostare la percentuale (o il numero) di siti Web che dispongono di una licenza attiva a cui desiderano distribuire la versione a pagamento:
Se impostano un'implementazione di una versione limitata, il sistema conteggerà il totale dei siti Web attivi con una licenza attiva e quindi imposterà di conseguenza la nuova proprietà limit della versione.
Infine, abbiamo aggiornato l'endpoint API chiamato dai siti Web per verificare se c'è una nuova versione e introdotto la seguente logica (in pseudo-codice):
latest_version = load latest version of product X
If (website is on latest_version)
return “no new version”
If (last_served_update_version of website same as latest_version)
return “no new version”
If (latest_version is limited)
If (latest_version is limited AND uniques >= limit)
return “no new version”
previous_version = load the previous version of product X
If (previous_version is limited too AND uniques <= previous_version.uniques)
If (website not using previous_version AND
last_served_update_version different from previous_version)
return “no new version”
else If (random({true, false}) )
return “no new version”
Set last_served_update_version of website to latest_version
Increment uniques by 1
return latest_version
Questo algoritmo garantisce che:
- L'esposizione della release è limitata in base alla percentuale di rollout impostata.
- Se la versione precedente è ancora a fasi, ovvero non è mai stata esposta all'intera base di installazione, i siti Web che hanno ricevuto la versione a fasi precedente verranno prima esposti all'ultima versione a fasi.
A differenza dell'architettura Staged Rollouts di WPML che assicura che ogni versione passerà a un sottoinsieme diverso della loro base di installazione utilizzando i bin logici, la nostra implementazione si basa sulla casualità. Pertanto, un sito Web può ottenere due versioni iniziali in due cicli di rilascio consecutivi. Tuttavia, il vantaggio di questo approccio è che siamo stati in grado di spedire implementazioni graduali a tutti i clienti dei nostri partner senza la necessità di inviare un aggiornamento dell'SDK, che può richiedere molti mesi, anche anni, per propagarsi a tutti i clienti.
Perché le implementazioni graduali sono essenziali per il futuro di WordPress?
Quando ho chiesto ad Amir quale fosse il loro motivo per sviluppare Staged Rollouts per i cicli di rilascio di WPML, questo è quello che mi ha detto:
3 anni fa, a WordCamp Europe, ho trascorso del tempo a chattare con i clienti WPML per raccogliere tutti i tipi di feedback sulla loro esperienza complessiva. La frustrazione n. 1 che ho riscontrato è stata che i nostri clienti avevano paura di aggiornare il plug-in in quanto potrebbe interrompere inaspettatamente il loro sito.
Amir Helzer,
Fondatore di OnTheGoSystems (WPML, set di strumenti)
Mi riferisco assolutamente a questo.
La nostra politica interna di Freemius quando si tratta di aggiornare plugin e temi è... semplicemente no! Con due eccezioni: se è presente un problema di sicurezza noto o una funzionalità disponibile in una versione più recente di cui abbiamo bisogno per il nostro sito.
La nostra politica sugli aggiornamenti è stata "scritta dal sangue" dopo diversi incidenti di aggiornamenti che sono andati storti e hanno causato mal di testa imprevisti e perdite di tempo, interrompendo il nostro funzionamento e le nostre scadenze. E sì, avremmo potuto evitare parte dello stress con un ambiente di allestimento, ma questo non ci avrebbe risparmiato tempo e fatica se avessimo voluto continuare l'aggiornamento alla produzione.
WordPress si è evoluto un po' da allora e ora abbiamo la disattivazione automatica in caso di errori dei plug-in. Tuttavia, ciò non si applica ai temi e la disattivazione di un plug-in mission-critical per il nostro sito Web è ancora un grosso problema.
La conclusione è che se io, come sviluppatore di plugin e CEO di un'azienda che aiuta migliaia di sviluppatori di plugin e temi a far crescere le loro attività, sono preoccupato di rompere il nostro sito ogni volta che aggiorniamo plugin o temi sul nostro sito, questo significa sicuramente la maggior parte degli utenti non ha fiducia nell'aggiornamento del software nel nostro spazio.
La mancanza di implementazioni graduali trattiene noi e l'intero ecosistema WP e offre alle soluzioni concorrenti basate su SaaS un vantaggio considerevole. Gli utenti WiX e Shopify non devono assolutamente pensare agli aggiornamenti! Gli aggiornamenti avvengono solo per loro in background e il loro software è sempre aggiornato, in termini di sicurezza e funzionalità.
La mancanza di implementazioni graduali trattiene l'intero ecosistema WP e offre alle soluzioni basate su SaaS un vantaggio considerevole. Gli utenti di WiX e Shopify non devono pensare agli aggiornamenti del software: accadono solo in background.Tweet
Se hai visto lo stato della parola della scorsa settimana, il co-fondatore di WordPress, Matt Mullenweg, capisce chiaramente l'importanza di un software aggiornato. Ecco la visione di Matt per gli aggiornamenti del WP:
... consentendoti di attivare gli aggiornamenti automatici per Core. Questo è il primo passo verso il nostro obiettivo che consente al tuo WordPress di mantenersi essenzialmente da solo, quando puoi impostarlo e dimenticarlo, e riceverà aggiornamenti automatici, in background e senza problemi a tutti i tuoi plugin, temi e core.Tweet
L'unico modo in cui posso immaginare che WordPress diventi un "imposta e dimentica" è se gli aggiornamenti software possono essere più affidabili e affidabili, e ciò può accadere solo con implementazioni graduali.
WordPress.org: ecco come introdurre implementazioni graduali per il repository di plugin e temi
Simile alla nostra implementazione, è necessario aggiungere due nuove meta opzioni a ogni rilascio di plugin e temi nel database di WordPress.org: limit e uniques .
La modifica dell'opzione limit meta può essere esposta nella vista avanzata per il proprietario registrato (e forse per altri committer):
Uno sviluppatore avrà un modo per controllare l'esposizione di ogni versione, nonché la possibilità di impostare un limite per la versione successiva.
Poiché WordPress.org non memorizza dati strutturati per ogni sito Web che riceve aggiornamenti da WordPress.org, invece di memorizzare l'ultima versione “vista” da un sito Web nel database di WordPress.org, la memorizzazione dei dati può essere delegata ai siti Web . Ciò significa che il transitorio 'update_plugins' e i dati inviati all'API di WordPress.org durante il controllo degli aggiornamenti dovranno essere arricchiti con un last_served_update_version .
Infine, gli endpoint dell'API degli aggiornamenti di WordPress.org possono essere arricchiti con la stessa logica utilizzata per l'implementazione di Freemius Staged Rollouts. Solo invece di fare affidamento su last_served_update_version dal database wp.org, il meccanismo dipenderà dal valore inviato dal sito Web dal core.
Facile, no?
sta assumendo 
Riportiamo la fiducia degli utenti per premere il pulsante di aggiornamento
Tutti noi vogliamo vedere WordPress avere successo e crescere costantemente sempre più grande!
Con così tante risorse destinate a Gutenberg, è chiaro che la leadership di WordPress riconosce che dobbiamo rendere la piattaforma più accessibile per il Joe medio non tecnico. Il fatto è che finché non ci si può fidare degli aggiornamenti software, anche con Gutenberg e tutti i fantastici page builder che abbiamo a disposizione, una persona non tecnologica scapperà su Wix al loro primo aggiornamento non funzionante e non potrei biasimarlo loro.
Sto chiamando il fondatore di EDD, Pippin Williamson, CEO di WooCommerce, Paul Maiorana e il team di WordPress.org: abbiamo l'opportunità di rendere l'ecosistema di plugin e temi molto più stabile per la più ampia comunità di WordPress. Consentiamo agli utenti di mantenere il loro software sicuro e aggiornato con meno paura e frustrazione. Anche se potrebbe non sembrare una priorità assoluta a breve termine, sono sicuro che tutti ne trarremo vantaggio a lungo termine.