Cum Braze a depreciat RequireJS și a modernizat stiva noastră de tehnologie front-end

De la Ziua Hack până la Migrare: Cum a început totul

Este amuzant de spus, dar am ajuns să lucrez la proiectul de depreciere RequireJS aproape din întâmplare. Lucrez în echipa de mesagerie și automatizare a Braze Engineering de aproximativ optsprezece luni, o echipă concentrată pe optimizarea conductei de trimitere de mesaje back-end pentru produsul nostru principal. La un moment dat, l-am întrebat pe un alt membru al echipei cum funcționează front-end-ul și, deși avea o idee vagă despre asta, nu era clar detaliile exacte.

Asta m-a făcut curios; Îmi doream foarte mult să înțeleg cum funcționează tabloul de bord. Și pentru că Braze organizează zile de hack care le permit angajaților să urmeze proiecte pasionale, am decis să profit de următoarea zi de hack pentru a explora dezavantajele tabloului de bord, cartografiind și documentând codul front-end. Cam în aceeași perioadă, echipa de bord Braze se gândea să facă trecerea de la RequireJS la Webpack, care se aștepta să fie o activitate majoră. Dar pe parcursul explorării, am început să văd o cale de urmat despre care credeam că ar putea ajuta echipa de bord să automatizeze o parte din munca implicată în modernizarea software-ului care sprijină front-end-ul platformei Braze.

Dar pentru a obține o imagine completă a ceea ce căutam să schimbăm și de ce am fost atât de entuziasmat de asta, trebuie să înțelegeți diferențele dintre RequireJS și Webpack.

Evoluția tabloului de bord Braze: RequireJS vs. Webpack

Deci, ce este tabloul de bord Braze, oricum? La cel mai elementar nivel, este o aplicație JavaScript cu o singură pagină. Și când un agent de marketing vizitează site-ul web Braze și se conectează la platforma noastră, vizualizarea web pe care o primește este, în general, informată de o versiune combinată a codului tabloului de bord. Acest pachet, care colectează fișiere disparate pentru producție, are aplicate mai multe optimizări diferite care ajută tabloul de bord să funcționeze mai eficient, inclusiv:

• Minimizare pentru a-i permite să se încarce mai rapid

• Modificări automate ale codului care permit tabloului de bord să se adapteze la diferite browsere web

• Divizarea codului pentru a permite codului front-end să se încarce la cerere, după cum este necesar

La Braze, acel proces de grupare a activelor pentru codul nostru JavaScript a fost susținut inițial de RequireJS, un încărcător de fișiere și module JavaScript conceput pentru utilizare web. Dar, de-a lungul timpului, a crescut un consens cu organizația Braze Product and Engineering că trebuia să evoluăm modul în care grupam codul pentru tabloul de bord.

Cel mai mare factor motivant a fost nevoia de a accelera procesul de construire. În general, un dezvoltator trebuie să treacă prin procesul de construire de fiecare dată când dorește să valideze modificările pe care le-a făcut la o bucată de cod, pentru a se asigura că ajustarea lor afectează software-ul așa cum se așteaptă. Odată ce a fost clar că Webpack – un pachet de module JavaScript open source – poate realiza aceste versiuni complicate mai rapid și mai eficient decât RequireJS, am știut că este timpul să facem schimbarea.

În special, am simțit că efectuarea schimbării ar avea trei beneficii cheie:

1. O bază de cod unificat

La acel moment, partea frontală a tabloului de bord a fost în esență împărțită în două, cu o jumătate scrisă în CoffeeScript și construită folosind RequireJS, în timp ce cealaltă a fost scrisă în JavaScript și TypeScript și construită cu Webpack. După cum v-ați putea aștepta, partajarea codului de-a lungul diviziunii a fost o problemă și, în multe cazuri, a fost nevoie de niște hackuri foarte fragile pentru ca totul să funcționeze. Deci, un avantaj major al efectuării muncii implicate în migrarea către un singur proces a fost că a reprezentat o oportunitate de aur de a unifica cu adevărat – și de a moderniza – baza de cod.

2. Cicluri de feedback mai scurte

După cum am menționat mai sus, una dintre marile priorități asociate acestui proiect a fost găsirea unor modalități de a scurta ciclul de feedback pentru inginerii care lucrează la tabloul de bord. Pe atunci, dacă ați făcut o modificare a codului front-end, procesul de grupare cu RequireJS ar dura în medie trei minute – și uneori ar putea dura până la opt minute. Este mult timp pentru ca un inginer să aștepte să afle dacă codul său funcționează normal. Cu Webpack, există un timp inițial de pornire care durează aproximativ 90 de secunde, dar fiecare modificare suplimentară poate fi efectuată mult mai rapid, permițând inginerilor să-și folosească mai bine timpul și să facă mai multe.

3. Depanare mai eficientă

Găsirea și abordarea erorilor de cod este o parte esențială a muncii oricărei echipe de inginerie. La Braze, folosim un produs numit Sentry care ajută la organizarea și urmărirea sursei problemelor atunci când apar în tabloul de bord al producției. Dar, deoarece acel cod a fost creat cu CoffeeScript cu RequireJS, atunci când a fost compilat și redus, numele descriptiv al unei funcții precum „navigateToPill” ar fi redenumit în ceva de genul „a”. Aceasta, la rândul său, însemna că vom vedea o eroare de tip în „a” pe linia unu, coloana 200.000 – ceea ce, după cum vă puteți imagina, a făcut multă muncă pentru a determina sursa acelei erori. Webpack, pe de altă parte, are un instrument numit Hărți sursă care permite echipelor să preia acel cod redus și să mapeze o anumită coloană și linie la fișierul sursă; asta înseamnă că veți primi rapoarte Sentry care spun că „navigateToPill” a avut o eroare pe o anumită linie, facilitând rezolvarea problemelor mai rapid.

Procesul de migrare: trecerea de la RequireJS la Webpack

Necesitatea de a face trecerea de la RequireJS la Webpack a fost clară, dar amploarea întreprinderii a însemnat că se așteptau ca procesul să dureze cel puțin un an și să implice multă complexitate și lățime de bandă de inginerie. Gândul la acea vreme era că va trebui să parcurgem sistematic baza codului secțiune cu secțiune și să migrăm manual totul, ceea ce ar fi fost cu adevărat oneros.

Descoperirea mea, dacă vreți să o numiți așa, a fost să realizez că aș putea scrie cod capabil să modifice în bloc codul tabloului de bord Braze printr-un proces automat – și, de asemenea, să nu modific codul nostru, dacă ar fi nevoie să anulăm aceste modificări. repede. Am ajuns să fac o demonstrație de concept în urma proiectului meu de hack day, doar pentru a arăta că ar putea funcționa, apoi am continuat să lucrez la el în timpul meu liber ca un fel de proiect pasional.

Acestea fiind spuse, lucrurile nu au demarat cu adevărat până când Greg Beaver, care este inginer senior software în echipa Braze Dashboard, s-a implicat. El a putut să ia scripturile pe care le scrisesem ca parte a demonstrației mele de concept și să le încorporeze într-un instrument pe care l-am putea împărtăși cu alți ingineri. Asta, la rândul său, a însemnat că am putea migra de la RequireJS la Webpack fără a forța toți inginerii care lucrează la codul legat de tabloul de bord să se oprească în timp ce o făceam; în schimb, au putut folosi instrumentul pentru a aduce automat orice cod la care lucrau în sincronizare cu modificările generale.

Instrumentul a ajuns să fie atât de rapid – durează doar două minute pentru a rula – și a funcționat atât de bine încât, în timp ce ne pregătim pentru migrare, am avut de fapt un inginer să-l folosească ca o soluție pentru versiunile lente asociate cu RequireJS. Tocmai și-au convertit ramura în Webpack, au făcut schimbarea pe care trebuiau să o facă și apoi au convertit-o înapoi, astfel încât să poată să o comite în vechiul cod.

Având la dispoziție această nouă capacitate, planul nostru de migrare a fost să rulăm instrumentul lui Greg pe filiala noastră principală în fiecare seară, timp de câteva săptămâni, și să îi facem pe oameni să verifice manual în mediul QA din acea sucursală, doar pentru a vedea dacă s-a stricat ceva. Odată ce am fost încrezători că totul arată bine, am informat restul organizației despre actualizarea planificată, i-am explicat cum își pot migra codul de la RequireJS la Webpack și le-am informat cu privire la câteva considerente cheie înainte de a ajunge. în curs de desfăşurare.

Datorită abordării noastre, un proiect care era de așteptat să dureze peste un an a ajuns să fie încheiat în doar trei săptămâni, ceea ce este destul de incredibil. Și mai neașteptat a fost impactul migrării - în special, procesul de construire pe Webpack acum durează în general doar aproximativ o secundă, reducând timpul necesar pentru fiecare verificare a codului cu mai mult de 99%.

La Braze, ne angajăm să construim un mediu în care indivizi precum Guerra să poată profita la maximum de perspectivele și talentele lor unice. Sunteți cineva care caută să depășească limitele și să reimaginați ce este posibil? Consultați pagina noastră de cariere pentru a afla mai multe despre pozițiile noastre deschise.