A frontend architektúrája a nagy szervezetek skáláján

(Daniel Ostapenko) ( 2020. október 14.)

Sziasztok! Meg akarom vitatni Önnel, hogyan kezelhető a Frontend architektúrája nagy szervezeteknél. Számomra úgy érzi, hogy nincs sok cikk erről a témáról, és ez nincs jól megmagyarázva.

A cikk nagy szervezete alatt azokat a vállalatokat értem, amelyekben a front-end mérnökök száma kezd lenni 15-nél nagyobb, és a vállalatnak legalább több frontend projektje van.

Nem akarok megvitatni a vezetési problémákat vagy az üzleti terület problémáit, amelyeket általában az ilyen nagy cégeknél látni, de összpontosítsunk csak a Frontend architektúráján.

A frontend architektúrája manapság túl sok területen szerepel, ezért először azt javaslom, hogy ossza fel a következő szakaszokra:

Frontend architektúrája

1. Visual Code

Kezdjük a legegyszerűbb témával, véleményem szerint ez az alkalmazásaink vizuális kódja.

Valószínűleg azért, mert több frontend alkalmazást fejlesztünk ki ugyanazon a cégen, ahová szeretnénk őket hogy:

  • márkafelismerés
  • ugyanaz a felhasználói felület / felhasználói felület

Ennek eléréséhez tervezési rendszerre van szükségünk. A tervező csapatnak ki kell dolgoznia a tervezési rendszert, és minden jövőbeni terméktervezés során be kell tartania ezeket a tervezési irányelveket. Ez már most is nagyon összetett feladat, és sok megbeszélést és összehangolást igényel a tervezőcsapat, a mérnökök és a termék között. ossza meg ezt a tervezési rendszert a mérnökök között. Erre jó megoldás lehet az npm csomag létrehozása, amelyet vizuálisan egy mesekönyv vagy valamilyen hasonló eszköz képvisel. Véleményem szerint nagyon fontos egy dedikált webes erőforrás (URL-lel), amely dokumentálja a csomag használatát. Ezt a webes erőforrást front-end mérnökök és tervezők fogják használni, és nagyszerű referenciapont lehet a beszélgetések közöttük.

Visual Code

Összegzés:

Ebben az időpontban van egy tervezési rendszerünk és annak ábrázolása egy csomagban, valamint az ahhoz tartozó interaktív dokumentáció. Megosztjuk és elfogadjuk ezt a csomagot az összes kezelőfelületen.

2. Kódszerkezet

Beszéljünk a kicsit a mérnöki munkáról naponta. Új funkciókat valósítunk meg, javítjuk a hibákat, szükség esetén visszafejlesztjük a kódot. Nagyon érdekel a kódalapunk, igyekszünk szépé és könnyen érthetővé tenni. De mi történik, ha nem 1, hanem 2, hanem több tucat kis vagy nagy projekt van a cégben? Az emberek általában egyes projektek köré csoportosulnak, és csak ezzel a projektcsoporttal kezdenek dolgozni. Emberi természetünk és korlátozott időnk alapján általában nem tudunk 2-3 időszaknál több projektet ellátni egy adott időszakban. Tehát természetesen elkezdődnek azok a befolyások csoportjai. Btw, köszönet a NASA-nak, amiért ilyen csodálatos képet készítettem hasonlatomért 😃

Hatáscsoportok

De egyre több olyan eset fordul elő, amikor az emberek keresztbe lépnek – együttműködésekre van szükség, ellenőrizniük kell egymás kódját és megoldásait, meg kell javítaniuk néhány hibát még más alkalmazásokban is, vagy hozzá kell adniuk valami olyat, amire szükségük van valamilyen külső alkalmazásban (külső hatáscsoportjuk szempontjából). Rossz hír – hogy ez a folyamat a nagy vállalatoknál szinte kontrollálatlanul zajlik. Jó hír – segíthetünk javításában.

Hogyan? Helyes. azonos kódstruktúra biztosításával, kódolási és strukturálási irányelvek mindenki számára a vállalat projektjei.

Bemutassuk mélyebben, mit értünk kódszerkezet alatt:

  • A mappa felépítése a projektben
    Amikor a mérnökök először ugranak be egy új projektbe – ugyanazzal a mappaszerkezettel, mint a sajátjukban projekt, ahol tudják, hogy minden sokat segít a navigálásban és a keresésben.
  • Konfigurációs vagy támogató fájlok
    Olyan fájlok, mint package.json, .gitignore, .editorconfig, webpack.config stb. Minden projektnek mindig ugyanazon a helyen kell lennie. Ugyanez kapcsolódik a konfigurációs fájlokhoz vagy a CI fájlokhoz, ha szükséges.
  • A fájltípusok rögzített helye
    Ha ugyanazon fájltípusok helye követi mindig ugyanaz a szerkezet, ez remekül is működik. Például, ha az összetevő mappában mindig van style.css fájl:
/Component
--/Component.tsx
--/style.css
--/index.ts
  • Az alkatrészek belső felépítése
    A fájlok belső felépítésének meg kell egyeznie: az import, az export sorrendje, a közfunkció helyzete , típusok stb. Minden fájltípusban tudnia kell, hogy mire számíthat.
  • Elnevezési megállapodások
    Ez magában foglalja a mappák, fájlok, változók, függvények, osztályok, típusok stb. nevét.
  • Kódolási konvenciók
    Általában azt mondom, hogy a konvenciók kódolása nagyon tág szakasz, de itt csak olyan dolgokat szeretnék felvenni, amelyek nem illettek a többi szakaszba, például a ; vagy not ; 😁 és hasonló .

Ugyanaz a kódszerkezet és a projekt eszközkészlete a gyakorlatban nagyon szoros és segítik egymás együttélését. Eszköztár alatt CLI eszközöket értek (projekt bootstrapping, szögelés, tesztelés stb.), IDE kiterjesztéseket stb. Az eszközkészlet témáját a következő szakaszokban tárgyaljuk.

Kódszerkezet

Összegzés:

A szakasz alkalmazása és elfogadása után a szervezetben minden projektnek rendelkeznie kell ugyanazzal a mappaszerkezettel, elnevezési irányelvekkel, fájlstruktúrával stb. Minden fejlesztő ideális esetben be tud ugrani bármely más projektbe, és nem veszik el ott teljesen. Ez a “teljesen elveszett” nagyon kapcsolódik a projektben használt technológiai veremhez is, szóval beszéljünk róla.

3. Tech Stack

Hasonló az előzőhöz szakaszban egy egységes technológiai verem van a szervezet projektjeiben. Ennek oka nagyon hasonló – azt akarjuk, hogy mérnökeink jól érezzék magukat a vállalat összes projektjében.

A Frontend projektekben a technikai verem összetevői lehetnek: keretrendszer, amelyre a projekt épül, a fő nyelv, a stílusok feldolgozója, adatréteg (pl. Apollo), állapotkezelés, tesztek, kódolás, rendszerépítés és egyebek.

Természetesen minden szabályban vannak kivételek. És ebben a témában azt is szeretném megtenni egy megjegyzés, hogy néha egyes technológiák rendkívül illeszkednek bizonyos projektekhez, még akkor is, ha ezek a technológiák nem részei a vállalat egészére kiterjedő technológiai veremnek. De mindig, amikor ez az ötlet elfordul, pany tech stack, érdemes kétszer is meggondolnod, mert az ilyen dolgok támogatásának költsége nagyon magas, ezért az előnyöknek drámainak kell lenniük.

Említsünk meg néhány általános tech stacket, amely a projektek többségéhez elfér ( természetesen csak a valódi technológiai verem egy részét fedi le, de jó kiindulópont lehet valakinek 🤷):

Verem

Miután meghatároztuk a cégünkben a technológiai verem és megegyeztünk benne, a siker más nagyon fontos pillérei is vannak .

Először – meg kell írja le a technikai verem az dokumentumba. A dokumentum, amelyet jól és egyszerűen meg kell osztani a mérnökök között , így bizonyítékként mindig tudnak linket adni egymásnak.

Másodszor – újra le kell írnunk és meg kell osztanunk a dokumentumot azzal, hogy hogyan kell elindítani és újrakezdeni az új projekteket , a meghatározott technikai verem használatával .

Technikai verem

Összegzés:

Miután megvalósítottuk és elfogadtuk mindazt, amit fentebb említettünk, érdemes legyen az összes projekt a szervezetnél, hogy ugyanazt a tech stacket használja. Ideális esetben különbségek nélkül. Nem ideális – jelentéktelen különbségekkel. Ha az előző szakaszt is hozzáadjuk, akkor a kódnak, mappáknak és fájlstruktúrának is szinte azonos a projektjeiben.Tehát bármely projekten való eligazodásnak nagyon egyszerű feladatnak kell lennie. Jó 😊

4. Eszközök

Ez a téma nagyon fontos. Néhány további eszközt használunk most szinte mindenhol – szöszölésre, alkalmazások, CI építéséhez, alkatrész-generátorokhoz és még sok máshoz. Ezért látom, hogy kiválaszthatjuk-e a megfelelő szerszámot projektjeinkhez – ez kulcsfontosságú. Jó szerszámok vs rossz eszközök (vagy egyáltalán nincsenek szerszámok), ez ugyanaz, mint az automatizálás és a kézi tesztelés összehasonlítása .

Korábban az előző szakaszokban beszéltünk a tech veremről és a kódstruktúráról, és megemlítettük, hogy írnunk kell sok dokumentáció, hogy az emberek kövessék őket. De a megfelelő eszközkészlet lehetőséget ad arra, hogy automatizálja a vállalat irányelveinek betartásával .

például, ha van egy meghatározott kódolási stílusa – megadhatja az embereknek a szöszölés eszközkészletet, amely alapértelmezés szerint ezeket a szabályokat követi. Ha rendelkezik a definiált technikai veremmel, akkor egy jó CLI eszköz lehetőséget nyújt arra, hogy egy új projektet indítson el az adott speciális technológiákkal a technikai verem helyén.

Próbáljuk megvitatni a a frontend architektúráját eszközök fedhetik le:

  • Kódstílus és szerkezet
    Amint azt korábban megbeszéltük, ez eszközökkel egyszerűen automatizálható.
  • A projekt indítása
    Ön nem ” Nem kell új projektstruktúrát kitalálni, manuálisan telepítve az összes szükséges csomagot stb.
  • Az alkatrészek generálása
    Legtöbbször az alkalmazás egyes összetevői nem tartalmaznak egyetlen fájlt sem, így a fájlok létrehozása, összekapcsolása / importálása időt vehet igénybe, így ez automatizálható.
  • Indítás és felépítés
    Természetesen a legkézenfekvőbb dolog az automatikus társ – az alkalmazás felépítésének vagy indításának módja.
  • Tesztek
    Az alkalmazás létrehozásának folyamata alkalmazás tesztekhez és minden típusú teszt futtatása – egység, integráció stb.
  • Függőségkezelés
    Mint tudjuk, kódunk körülbelül 80\% -a függőség. Ezért naprakészen kell tartanunk őket, és ennek kezelése egy hatalmas vállalatnál nem könnyű dolog.
  • Projektek közötti függőségek
    Valószínűleg a projektjeink nem elszigetelten működnek, és más projektektől függhetnek, vagy függhetnek más projektektől, ezért szükség lehet néhány eszközre, hogy megkönnyítsük a kapcsolataikat, fejlesztés több projekt (például Bit ) kombinációjában stb.
  • CI
    A CI a mindennapi eszközkészletünk elengedhetetlen része, és automatizálása és egyesítése nagyon hasznos munka lehet a szervezete számára.

Ha nem szeretne új saját eszközkészletet fejleszteni, akkor az NX eszközkészletet javasolhatom, mint az egyik legérdekesebb jelöltet. , úgy tűnik, hogy a Bábel alkotói hasonló megoldást csinálnak, amelyet érdemes megnézni – Róma . Ezek az eszközök nem mindent fednek le, hanem annak nagy részét, amiről beszéltünk, így jó kiindulópont lehet.

Eszközök

Összegzés:

Képzelje csak el, milyen nagyszerűvé válhat az architektúránk az összes szakasz elkészítése és elfogadása után 🧙

Minden projekt ugyanaz, az egységes eszközkészlet fenntartja és kezeli őket. Minden projekt ugyanúgy indulhat és épülhet fel. Új összetevőket ugyanazon a helyen és ugyanazokkal a névadási irányelvekkel állítanak elő.

De vajon „édes”-e vagy vannak-e hátrányai? Mint minden megoldásnál, van hátránya is. Az egyikük – némi időre van szükség ahhoz, hogy új mérnököket helyezhessenek el a vállalatához. De ha mindent nagyon természetes módon végeznek (ahogy az emberek megszokták már más meglévő eszközökben) és dokumentálják, akkor ez nem válik óriási kérdéssé, ha összehasonlítjuk a fejlesztési sebesség előnyeivel, a mérnökök számára ezzel a lehetőséggel. bármilyen kódbázis könnyen stb.

5. Gyártás

A frontend architektúra ezen részéről általában a mérnökök gondoskodnak a legkevésbé.Talán azért, mert ez legtöbbször nem kapcsolódik magához a kódoláshoz🤷 és valószínűleg nem is olyan izgalmas, de nem utolsósorban fontos ☝️

A produkcióban általában a következő dolgokra kell törekednünk:

  • Analytics
    Mindenféle különféle nyomkövetési esemény stb. Ilyenek például: Google Analytics , szegmens , HotJar stb.
  • Állapotfigyelés
    Ez magában foglalja például az állapotellenőrzéseket még tesztek is futnak a gyártáson, hibajelentések (például Sentry ) stb.
  • Teljesítmény
    Ez hasonló az előző tételhez, de jobban orientálódik a teljesítményre. Ide tartozik a válaszidő mérése, az első értelmes festék stb. (Valószínűleg 1. eszköz – Világítótorony )
  • A / B tesztelés
    Mindenféle A / B tesztelési megoldás vagy szolgáltatásjelző.
  • Gyorsítótárazás
    Ilyen eszközök, például a Lakk , Cloudflare .

Mindegyik egységesíthető a vállalat kezelőfelületein, ami megkönnyíti mérnökei életét . Például az eredeti konfigurációval előre definiált csomagok hozzáadásával és a csomagok hozzáadásával a bootstrapping projektbe.

A produkció másik része a kód előkészítése, például:

  • Minimalizálás
    Csak a kód tömörítése 😄
  • Forrás feltérképezése
    A forrás térképekre szükség lehet más eszközöknél is, például a Sentrynél.
  • Eszközök előkészítése
    Előkészítés különböző felbontású képernyőkhöz, képek kivágásához stb.

Ezek nagyszerű jelöltek, akiket hozzá lehet adni a kezelőfelületek kezeléséhez szükséges eszközkészlet, amelyről a Szerszámozás részben beszéltünk.

Gyártás

Összegzés:

Ideális esetben mindannak kellene lennie alapértelmezés szerint hozzáadódik az egyes frontend projektekhez a rendszerindítási szakaszban. A mérnökök pedig csak arra törekednének, hogy helyes API kulcsokat adnak hozzá az eszközök megfelelő helyeihez.

6. Fejlesztés

CLI eszköz

Részben a fejlesztési tapasztalatokról már az Eszköztár részben beszéltünk, amikor megérintettük a frontend CLI eszközt. Az egységes szerszámozás a mérnökök napi nagy része, de nem minden.

API

A kényelmes API, amellyel helyi szinten lehet együtt dolgozni, a második félelmetes dolog, amit tehetünk a fejlesztő fejlesztésében tapasztalat és fejlesztési sebesség. Az API-k helyi kiszolgálása a front-end mérnökök számára általában nem triviális folyamat: ez magában foglalhat olyan eszközök vagy keretrendszerek telepítését, amelyeket nem ismerhetnek. Még akkor is, ha a telepítés dokkolt, ez óriási számítást igényel a fejlesztő gépeinek erőforrásai (ha nem – ez telepítésnek tekinthető). Mi lehet a megoldás ebben az esetben – külső kiszolgáló API. Ez lehet egyetlen szerver az összes mérnök számára, vagy valamilyen mechanizmus a bootstrap egyszerűen a saját dedikált szerver fejlesztéshez.

CI

A CI a harmadik nagy rész. Feltételezhetem, hogy cége már választott néhány CI eszközt a frontendhez, és ezt az egyetlen eszközt használja (pl. CI kör ,

Concourse CI vagy bármely más). Ha nem – akkor ezt egységesítenie kell.

Az adott projekt CI konfigurációjának véleményem szerint a projekten dolgozó csapat munkájának részét kell képeznie. Ez esélyt ad arra, hogy a CI stabil legyen, mert vannak olyan emberek, akik érdeklik, hogy a CI dolgozzon, minden nap használja, és van ereje és készségei a javításhoz, konfiguráláshoz és fejlesztéshez.

Azonban nem minden munkát kell elvégeznie a csapatnak. Az elülső alkalmazások számára elég sok olyan feladat létezik, amelyekre potenciálisan szükség lehet. Különösen, ha sikerül egységesíteni a mappa- / kódstruktúrát, a technikai halmot stb. valamilyen “építőelem”, és lehetőséget ad a mérnökeinek, hogy építsék meg CI csővezetékeiket azokból az egységes “építőelemekből”.

Bemutató környezetek

És végül az utolsó – a a megvalósított funkció.Miután a mérnökök mindent megtettek és végrehajtottak – szinte mindig meg kell valahogy ellenőrizniük, hogy néz ki és hogyan működik, és meg kell osztaniuk ezt más mérnökökkel, tervezőkkel vagy más érdekeltekkel. Ilyen igények esetén rendkívül jól működik az alkalmazás ideiglenesen telepített verziója a megadott PR-hez a megadott URL-címmel.

Alkalmazás ideiglenesen telepített
Alkalmazás ideiglenesen telepítve

Ez a megoldás nagyon felgyorsítja a kommunikációt a különböző csapatok és emberek között, és szerintem ez csak egy kell. Ennek az ideiglenesen telepített verziónak azonban a lehető legközelebb kell lennie a gyártáshoz, mert nagyszerű eszköz lehet egyes felületi hibák vagy hibák ellenőrzésére is.

Ez könnyen hozzáadható a projektekhez és automatizálható, ha a kezelőfelülete az alkalmazások felépítése és a telepítési folyamat csővezetékei egységesek. Az ilyen vagy hasonló eszközök, például a Kubernetes és a Helm is sokat segíthetnek a megvalósításban.

Fejlesztés

Összefoglaló:

Kényelmes és hatékony fejlesztési folyamatok egyetlen CI eszközzel, építőelemekkel CI csővezeték, egységes CLI frontend eszközökkel és a bemutató környezetekkel. Mindezeknek a lehető legsimábbá kell tenniük fejlesztési folyamatunkat. Szorozza ezt össze a vállalatnál lévő mérnökök számával, és meg fogja érteni, mennyire előnyös.

7. Modularitás

Ez a témakör nagyon nagy, és külön cikket is igényelne, de megpróbálnám röviden átnézni.

Nagy szervezetekben a hatalmas kódbázisok nem ritkák dolog. A velük együtt járó összes ismert kérdéssel, például a lassú CI-csővezetékekkel, az együttműködő munkával, a lassú tesztekkel stb. Kapcsolatos problémákkal. Tehát a frontend architektúrájának nagy része egy döntés arról, mennyire szemléletesnek akarjuk látni a független frontend alkalmazásokat / modulokat.

Jelenleg 3 fő modellünk van:

  • Monolit
    Egy nagy lerakat egyetlen projekttel és az ott található összes kóddal, az összes csapat egyszerre dolgozik ebben a lerakatban.
  • Monorepo
    Sok projekt, de még mindig egy nagy tárház ( monorepo a wikiben ). Az összes csapat továbbra is ugyanabban az adattárban dolgozik, de különböző projektekkel. Már vannak lehetőségek egyes problémák megoldására, amelyek monolit megközelítéssel megvannak, a csővezetékek futtatásával csak meghatározott projektekhez, a projektek kisebb tesztcsomagokkal rendelkeznek stb. Ilyen eszközök, például A / a> sokkal könnyebbé teheti életét abban az esetben, ha ezt a megközelítést választja.
  • Repo projektenként
    Minden projektnek megvan a saját adattára és minden támogató dolog, például CI-csővezetékek, telepítések stb.

Mindegyik modellben a projekt jelenthet egy független frontend alkalmazást, oldalt, független frontend modul stb. Ez attól függ, hogy mennyire részletesen el akarja dönteni a front-end alkalmazások felosztását. A legtöbb esetben ennek a felosztásnak szinkronban kell lennie a kívánt szervezeti felépítéssel és az emberek kezelésével.

A második nagy téma az alkalmazás felosztásának eldöntése után az lesz, hogy ezeket a darabokat hogyan kell összekapcsolni (ha úgy döntöttél az alkalmazás felosztásához).

És itt van a következő megközelítés:

  • Build-time kompozíció
    A projektek csak npm csomagok lehetnek, telepíthetők és összeállíthatók a készítés ideje alatt.
  • Szerver- oldalkompozíció
    Ez a megközelítés általában magában foglalja a kiszolgálóoldali renderelést és a kiszolgálón történő kompozíciókat. Ilyen eszközök, például a Hypernova segíthetnek annak jobb rendezésében.
  • Ügyféloldali összetétel
    A böngészőben található projektek összetétele. Martin Fowler blogjában néhány megközelítés elég jól magyarázható – itt . Ezenkívül nagyon fontos megemlíteni a Modul Összevonás , egy új megközelítés, amelyet a 5-ös webcsomagban vezettek be.
  • Útvonalösszetétel
    Nagyon egyszerű – csak minden projektnek megvan a saját URL-je, és “Nginx szinten” eldöntjük, hova irányítsuk át a felhasználókat.(elnézést, egy ilyen magyarázatért 😄, de azt gondoltam, hogy ezt lesz a legkönnyebb megérteni)

Mint korábban mondtam, nagyon nehéz ezt a témát ilyen kis formátumban lefedni, de remélem, hogy legalább talált néhány érdekes ötletet magának, és egyedül fog beleásni a témákba 🙏🏻 .

Modularitás

Összefoglaló:

Megtaláltuk a módját, hogy csapatainkat boldoggá és produktívvá tegyük az adattárak megszervezésével, projektjeink kisebb darabokra bontásával (valószínűleg), a csapatok egymástól függetlenebbé tételével.

Üdvözöljük a paradicsomban 😁

8. Tesztelés

Annyi erőforrás áll rendelkezésre a front-end alkalmazások teszteléséhez, ezért megpróbálnék nem belemenni a részletekbe, amelyeket megtehet könnyű Keresse meg, de inkább koncentráljon a nagy szervezetek kérdéseire és azok megoldására.

Az első ezek közül – minden mérnök másképp érti a tesztelési technikákat, azt is, hogy melyik technikát melyik helyzetben alkalmazza, hogyan írjon “ jó ”tesztek, stb. Tehát nagyon sok értelme van, hogy pontosan pontosan dokumentáljuk a vállalatnál alkalmazott tesztelési szintek összes árnyalatát és irányelveit, valamint mindegyikre vonatkozó irányelveket.

Lehetséges tesztelési szintek vegye be a tesztelési stratégiáját:

  • Egységtesztelés
  • Integrációs tesztelés
  • E2E tesztelés
  • … és mások

Ezenkívül második lépésként egyesítenünk kell őket a vállalat különböző frontend alkalmazásai között, így az embereknek nem lennének kérdéseik arról, hogyan és mit kell tesztelni, ha másik projektbe költöztek.

Ha sikerült egységesíteni a tesztelési szinteket és megközelítéseket, akkor automatikusan segíthet a második probléma – az infrastruktúra beállításának tesztelése – megoldásában. Minden projektnek saját maga kell létrehoznia és konfigurálnia helyileg, valamint a CI-nél valamilyen tesztelési infrastruktúrát. Például úgy döntöttünk, hogy a Cypress-t használjuk, és azt egy dokkoló képen belül kell futtatni. Ehhez egy kis időre van szükség a helyben és a CI-n történő beállításhoz. Ha ezt megszorozzuk a projektek számával – ez óriási idő. Szóval, a megoldás – ennek újbóli egyesítése és a szerszámok biztosítása a projektekhez. Könnyen hangzik, de a végrehajtáshoz nagyon sok idő kell.

Nem fejlesztési idő tesztelése

Szeretném megérinteni az alkalmazások tesztelésének egy másik módját is a már bevezetett és telepített funkciók után. És igen, természetesen ennek figyelemmel kísérése 😁.

Az előző szakaszokban már említettük a frontend alkalmazások hibáinak és teljesítményének figyelemmel kísérését, az üzemidő figyelemmel kísérését, a különböző helyekről érkező válaszokat.

Nagyon jó, hogy Lighthouse tesztek futnak az Ön webhelyén (beépíthetők a CI csővezetékébe). Könnyebb teljesítmény-szűk keresztmetszetek, akadálymentességi kérdések és általában a weboldalak minőségének javítása érdekében.

És utolsó – gyártási tesztek a legfontosabb üzleti folyamatokról. Valószínűleg akkor működnek a legjobban, ha közvetlenül a productien futtatja őket a környezettel, de lehetséges módosítás is, amikor ilyen teszteket futtathatunk egy staging / tesztkörnyezeten, amely nagyon közel áll a gyártáshoz, vagy akár tükrözi azt. Van egy nagyon kedves cikk erről a témáról – (itt).

Tesztelés

Összegzés:

egyértelmű tesztelési irányelvek a szükséges tesztelési szintekkel minden frontend alkalmazáshoz. Minden alkalmazáshoz egyetlen CI-csővezeték áll rendelkezésünkre, és egyetlen CLI eszközünk van, amely segít a tesztek helyi futtatásában.

Végső szó

Nagyon remélem, hogy srácok találtak valami érdekeset ebben cikk. Nagyon sajnálom, hogy a legtöbb témában csak megvakartam a kérdések felületét. És szívesen megvitatja őket tovább, ezért kérjük, hagyja meg kérdéseit a megjegyzésekben, vagy pingeljen közvetlenül a twitteren – @denieler .