Creșterea pisicilor – Lecții învățate în timpul dezvoltării pentru mediul WordPress

Publicat: 2021-12-02

Când Elementor 3.0 a fost lansat în urmă cu peste un an, în 2020, l-am văzut ca un pas semnificativ către un editor mai rapid și mult mai puternic. Deși acest lucru este adevărat, această versiune a avut și consecințe importante, neașteptate - a făcut ca un număr semnificativ de site-uri să nu mai funcționeze și, sincer, ne-a afectat reputația. După această lansare, a trebuit să venim cu o serie de remedieri pentru ca aceste site-uri să funcționeze din nou. Mai mult, întreaga experiență ne-a arătat că trebuie să ne revizuim întreaga procedură de testare și eliberare. Deși dureros, acest proces dă roade astăzi, așa cum se reflectă în scăderea extraordinară a problemelor, în special a celor critice, între lansarea versiunilor noastre v3.0 și v3.4:

Acum, pe măsură ce ne apropiem de un an de aniversare a Elementor 3.0, este un moment bun să ne uităm în urmă și să examinăm procedurile pe care le-am pus în aplicare pentru a ne asigura că problemele care însoțesc lansarea sa nu mai apar. Pentru a fi cât mai transparent cu comunitatea noastră, aș dori să examinez contextul problemelor legate de lansarea 3.0, pașii pe care i-am luat în ultimul an, cum am putut să asigurăm lansări stabile și ce ne rezervă viitorul. Dar, mai întâi, este important să înțelegem puțin din istoria Elementor și provocările cu care ne confruntăm în dezvoltarea unui plugin complicat și sofisticat în mediul WordPress.

Cuprins

  • Elementor și provocarea WordPress
  • Dezvoltarea de noi funcții fără a rupe vechiul
  • Bucla de feedback
  • Prezentarea caracteristicilor „experimentale”.
  • Etichete de compatibilitate
  • Spre un viitor și mai bun

Elementor și provocarea WordPress

În iunie 2016, când am lansat prima versiune a Elementor, eram doar câțiva „copii”, cărora le plăcea să dezvolte pluginuri și să ajutăm oamenii să construiască site-uri web. Acesta nu a fost primul nostru produs, dezvoltasem deja câteva plugin-uri folosite de comunitatea WordPress. Cu toate acestea, pe măsură ce lucram la Elementor, ne-am convins că dezvoltăm ceva special. După cum sa dovedit, aveam dreptate – la doar câteva luni după prima noastră lansare, zeci de mii de utilizatori instalaseră deja Elementor și îl foloseau pentru a construi site-uri web în întreaga lume.

De atunci, compania noastră a crescut în toate privințele, cu mai mulți dezvoltatori, mai mulți utilizatori și mai multe funcții. Odată cu această creștere, au apărut o serie de probleme noi, inclusiv un deficit tehnologic în creștere, deoarece ne-am concentrat pe probleme urgente, lăsând deoparte problemele importante, dar mai banale.

Tratarea acestor probleme a fost făcută și mai dificilă de provocarea generală reprezentată de natura mediului WordPress.

Ca platformă deschisă, WordPress oferă o serie de avantaje mari pentru dezvoltatori. Există câteva obstacole în monitorizarea și încetinirea lansărilor. Conceptele sunt imaginate, dezvoltate și adăugate la depozit. Utilizatorii încearcă, testează și judecă aceste produse, piața decidând care dintre ele vor prospera și care vor eșua. Cu toate acestea, această viteză și simplitate au un preț.

Există puțină uniformitate în mediul WordPress și niciun flux de lucru ordonat. Creatorii web sunt liberi să-și definească mediul site-urilor în timp ce folosesc o gamă largă de plugin-uri, teme etc. Aceasta înseamnă că site-urile WordPress conțin nenumărate combinații de plugin-uri, teme și configurații de server.

În plus, simplitatea procesului de lansare și lipsa unor instrumente robuste de implementare înseamnă că dezvoltatorii WordPress nu sunt capabili să folosească conceptele moderne de lansare, cum ar fi CI/CD, Canary Deployment și Feature Flags.

În timp ce deschiderea face parte din frumusețea WordPress, multitudinea inerentă de configurații de site și server le prezintă dezvoltatorilor o adevărată provocare atunci când vine vorba de contabilizarea conflictelor de pluginuri și a problemelor specifice ale serverului.

În cazul nostru, deoarece Elementor a fost folosit pentru tot mai multe site-uri web, nevoia de a sprijini toate aceste combinații diferite a încetinit programul nostru de lansare și chiar ne-a făcut să ezităm să dezvoltăm noi funcții. Inutil să spun că această situație era inacceptabilă și trebuia să zdruncăm lucrurile.

Dezvoltarea de noi funcții fără a rupe vechiul

Toți factorii de mai sus ne-au lăsat cu dilema cum am putea continua să ne dezvoltăm și să ne îmbunătățim fără a avea un impact negativ asupra muncii celor care se bazau deja pe Elementor?

Am început prin a implementa câteva mici modificări în procesul nostru de lansare. În Elementor 1.5, am început să oferim dezvoltatorilor acces la versiunile Beta. Am făcut acest lucru prin Github și alte comunități care ne-au permis să primim feedback înainte de o lansare, indicând modul în care această versiune a interacționat cu o mare varietate de combinații de plugin/temă/mediu și avertizându-ne de la început despre orice incompatibilități. Această abordare a funcționat bine pentru o vreme, dar pe măsură ce Elementor a crescut, și mai mult, am descoperit că acest lucru nu era suficient.

Până atunci, depășisem pragul de cinci milioane de instalare. Deși o realizare incredibilă, aceasta însemna și că acum suntem responsabili pentru funcționarea fără probleme a tuturor acestor site-uri web.

Lucrurile au ajuns în sfârșit la un cap odată cu lansarea Elementor 3.0. În această versiune, am decis să renunțăm la unele funcții vechi, aparent învechite, eliminând elementele DOM pentru a crește viteza de încărcare. Acest lucru a fost, cel puțin parțial, ca răspuns la plângeri justificate conform cărora am încărcat inutil sistemul.

Din păcate, această modificare a făcut ca un număr de site-uri, care se bazau pe codul pe care l-am șters, să se întrerupă în timpul upgrade-ului. În ciuda eforturilor noastre de a implica dezvoltatori terți în proces, aceste erori au rămas nedescoperite și a trebuit să ne mișcăm rapid pentru a corecta situația. În cele din urmă, am reușit să facem acest lucru făcând opționale părți ale upgrade-ului, dar nu înainte ca unii membri ai comunității noastre să-și fi zdruncinat încrederea în stabilitatea pluginului nostru.

Această experiență ne-a forțat să aruncăm o privire lungă și serioasă asupra procesului nostru de dezvoltare, cu un ochi către realizarea unor schimbări majore. Procesele noastre pur și simplu nu erau potrivite pentru o companie de dimensiunea și baza noastră de instalare. Prima, și poate cea mai evidentă mișcare, a fost să creștem dimensiunea și sfera de aplicare a echipei noastre de QA, dar acest lucru ne-a lăsat în continuare să ne confruntăm cu o serie de probleme restante:

  • Verificarea compatibilității unei versiuni cu nenumărate setări de site
  • Asigurarea compatibilității cu peste cinci milioane de site-uri existente
  • Verificarea compatibilității a sute de extensii Elementor terțe

Pentru a face față tuturor acestor probleme, trebuia să aducem metode de dezvoltare software mai actualizate în lumea WordPress.

Bucla de feedback

Una dintre marile probleme cu care se confruntă dezvoltarea, în general, este că utilizatorii experimentează actualizări doar după ce au fost lansate. Aceasta înseamnă că o funcție a fost deja proiectată, dezvoltată și lansată până când primim feedback de la utilizatori. În cazul nostru, având de-a face cu sute de sute de extensii și pluginuri terțe, problema acestei bucle de feedback este și mai importantă.

Căutând modalități de a scurta această buclă de feedback, ne-am uitat la modul în care dezvoltatorii de browsere abordează probleme destul de asemănătoare cu ale noastre - trebuie, de asemenea, să asigure compatibilitatea cu nenumărate pagini web, aplicații, extensii și multe altele terțe.

De exemplu, am examinat sistemul dezvoltat de Google pentru browserul Chrome. În orice moment, dezvoltatorii au acces la trei versiuni ale browserului - o versiune beta, o versiune dev și o versiune de noapte. Aceasta înseamnă că dezvoltatorii primesc o privire devreme asupra noilor funcții Chrome și pot începe să ofere feedback către Google cu mult înainte ca versiunea să fie lansată oficial.

Aplicând aceste lecții plugin-ului nostru, Elementor a început să-și lanseze propria ediție pentru dezvoltatori – Elementor Beta (Ediția pentru dezvoltatori), disponibilă din depozitul WordPress și destinată dezvoltatorilor care sunt interesați să verifice noile noastre funcții „fierbinte” ca să spunem așa.

Pentru noi, desigur, beneficiem primind avertismente timpurii cu privire la probleme de compatibilitate. Ediția pentru dezvoltatori nu numai că permite utilizatorilor să acceseze toate aceste funcții noi, dar există chiar și un link direct către Github pentru raportarea erorilor. Aceasta înseamnă că putem implementa în mod continuu noi funcții și putem primi feedback despre ele, fără a pune în pericol site-urile web existente. Pentru dezvoltatori, acest lucru le permite să se pregătească pentru viitoarele lansări oficiale cu mult timp în avans, ajutându-și la prevenirea propriilor probleme de compatibilitate și, de asemenea, oferindu-le posibilitatea de a oferi feedback despre produs și tehnic în timp ce funcția este încă în curs de lucru.

Trebuie remarcat faptul că versiunile ediției pentru dezvoltatori rulează în paralel cu cele normale - alfa, beta, RC și producție - un proces folosit pentru a dezvolta versiuni Elementor. Când dezvoltăm o nouă caracteristică, de îndată ce este suficient de stabilă pentru a fi utilizată, dar cât timp este încă în alfa, o adăugăm la ediția pentru dezvoltatori. În acest fel, dezvoltatorii noștri ne pot oferi feedback, chiar înainte ca caracteristica să ajungă la versiunea beta. De asemenea, înseamnă că ediția pentru dezvoltatori include funcții care nu au ajuns în stadiul beta.

În esență, etapa beta este rezervată unui proces de depanare deliberat, în timp ce ediția pentru dezvoltatori este actualizată mai frecvent, încorporând caracteristici în stadiile lor incipiente.

De la introducere, ediția pentru dezvoltatori s-a dovedit un mare succes, strângând peste 40 de mii de instalări în mai puțin de un an.

Prezentarea caracteristicilor „experimentale”.

De-a lungul anilor, un alt concept pe care dezvoltatorii l-au îmbrățișat este steagurile de caracteristici, care sunt predominante în special în lumea SaaS. Ideea generală este că aceste semne de caracteristică le permit dezvoltatorilor să testeze noi funcții, pornindu-le și dezactivându-le pentru diferite segmente de utilizatori, pentru a le testa și a vedea cum funcționează.

După cum am menționat mai sus, multe dintre problemele care decurg din lansarea versiunii 3.0 s-au datorat noilor funcții care elimină codul mai vechi. Pentru a evita astfel de probleme, am decis să adoptăm o abordare similară cu cea a steagurilor de caracteristici.

Începând cu Elementor 3.1, am început să lansăm noi funcții cu mai multă atenție, semnalându-le ca „experimentale”. Aceasta include un sistem de introducere de noi funcții în etape. În acest sistem, o caracteristică nou dezvoltată va fi marcată ca „Alpha”. Aceasta înseamnă că este dezactivat, în mod implicit, pe toate site-urile. Pe măsură ce se dovedește mai stabil, devine o „Beta”, ceea ce înseamnă că acum este activat, implicit, pentru site-urile noi și dezactivat pentru site-urile existente. Odată ce suntem siguri că este stabil, este activat, implicit, pentru toate site-urile. Chiar și atunci, va exista o opțiune pentru utilizatori de a dezactiva funcția, pentru o perioadă limitată de timp.

Acest sistem ne permite să continuăm să dezvoltăm Elementor, adăugând atât setului de caracteristici, cât și vitezei sale, permițând în același timp creatorilor să accepte sau să renunțe la aceste noi actualizări în funcție de nevoile site-ului lor. Acest lucru îi ajută și pe creatori să își actualizeze site-urile, permițându-le să adopte noi funcții cu mai multă atenție.

Etichete de compatibilitate

Creșterea comunității de dezvoltatori foarte active a lui Elementor a fost o mare sursă de mândrie, dar și-a pus și propriile provocări. Dezvoltatorii terți au creat sute de extensii, teme, kituri și widget-uri, toate bazate pe tehnologia noastră existentă.

Pentru a sprijini dezvoltatorii acestor suplimente terță parte, am folosit blogul dezvoltatorilor noștri și lista noastră de corespondență pentru a le anunța din timp despre modificările pe care le aduceam API-ului, precum și despre deprecieri. Cu toate acestea, așa cum am menționat mai sus, am descoperit că acest lucru nu este suficient. Multe dintre problemele pe care le-am confruntat cu noile versiuni se confruntau cu probleme de compatibilitate din cauza acestor suplimente terțe. Pluginul nostru a fost văzut ca instabil, nu din cauza tehnologiei noastre, ci din cauza acestor incompatibilități terță parte.

Din nou, ne-am uitat la ceea ce făceau alții pentru inspirație. În acest caz, WooCommerce și abordarea lor de a lucra cu dezvoltatori terți. Începând cu versiunea noastră 3.1, am început un sistem în care dezvoltatorii terți certifică că extensiile lor sunt compatibile cu noua versiune (Aflați mai multe). Apoi, când utilizatorilor li se oferă opțiunea de a face upgrade Elementor, li se prezintă o listă de extensii terță parte pe care le folosesc și dacă au fost sau nu certificați ca compatibile cu noua versiune a Elementor. În acest fel, utilizatorii pot lua o decizie informată cu privire la actualizare.

Spre un viitor și mai bun

Subliniind aceste provocări și schimbările pe care le-am implementat, sper că v-am dat o privire asupra cum este să dezvoltați un produs pentru utilizare la nivel mondial, într-un mediu open-source și în continuă schimbare. Ca parte a acestei culturi open-source, este esențial să fim transparenți cu comunitatea noastră de utilizatori și dezvoltatori – cu atât mai mult pe măsură ce compania crește și devine mai dificil să menținem „o notă personală”. Nu numai pentru că durerea utilizatorilor noștri este durerea noastră, ci pentru că este cea mai bună modalitate prin care Elementor să rămână un instrument stabil, deschis pentru cea mai largă gamă posibilă de utilizatori.

Credem cu tărie că schimbările pe care le-am implementat au contribuit și vor continua să contribuie la creșterea și succesul Elementor. Cu toate acestea, suntem, de asemenea, conștienți că mai este de făcut și că comunicarea dintre Elementor și comunitatea Elementor trebuie să rămână deschisă și chiar îmbunătățită. De exemplu, ne actualizăm site-ul de resurse pentru dezvoltatori, oferind documentație ușor de utilizat pentru a ajuta dezvoltatorii să personalizeze și să construiască pe Elementor.
Dar poate cel mai important pas pe care l-am făcut în îmbunătățirea comunicării este înființarea Elementor Community Hub. Aici, creatorii web din întreaga lume se pot aduna pentru a face schimb de idei între ei și cu noi – colaborând împreună pentru a face din Elementor cel mai bun posibil. La urma urmei, așa cum sugerează vechea zicală, păstorirea pisicilor poate fi aproape imposibilă, dar atunci când lucrează împreună, se numește Mândrie.