Frontend-arkkitehtuuri mittakaavassa suurille organisaatioille

(Daniel Ostapenko) ( 14. lokakuuta 2020)

Hei! Haluan keskustella kanssasi siitä, kuinka hallita Frontend-arkkitehtuuria suurissa organisaatioissa. Minusta tuntuu, että tästä aiheesta ei ole paljon artikkeleita, eikä sitä selitetä hyvin.

Tässä artikkelissa tarkoitan suurta organisaatiota, tarkoitan yrityksiä, joissa etupääinsinöörien määrä alkaa olla yli 15 ja yrityksellä on vähintään useita käyttöliittymähankkeita.

En halua keskustella johtamisongelmista tai liiketoiminta-alueisiin liittyvistä kysymyksistä, jotka ovat yleisiä tällaisissa suurissa yrityksissä, mutta keskitykäämme nyt vain sen sijaan Frontend-arkkitehtuurissa.

Frontend-arkkitehtuuri on nykyään mukana monilla alueilla, joten ehdotan aluksi, että se jaetaan seuraaviin osiin:

Käyttöliittymän arkkitehtuurikaavio

1. Visuaalinen koodi

Aloitetaan helpoimmasta aiheesta, mielestäni se on sovelluksemme visuaalinen koodi.

Todennäköisesti siksi, että kehitämme useita käyttöliittymäsovelluksia samassa yrityksessä kuin haluamme. on:

  • tuotemerkin tunnistus
  • sama käyttöliittymä / käyttöjärjestelmä

Tämän saavuttamiseksi meillä on oltava suunnittelujärjestelmä. Suunnittelutiimin on keksittävä suunnittelujärjestelmä ja noudatettava näitä suunnitteluohjeita kaikissa tulevissa tuotesuunnitelmissa. Jopa tämä on jo hyvin monimutkainen tehtävä, ja se vaatii paljon keskusteluja ja linjauksia suunnittelutiimin, insinöörien ja tuotteen välillä.

Etupään näkökulmasta meidän on tarjottava työkalu toteutettavaksi ja jaa tämä suunnittelujärjestelmä insinöörien kesken. Hyvä ratkaisu siihen voi olla npm-paketin luominen, jota edustaa visuaalisesti -kirjakirja tai jokin muu vastaava työkalu. Mielestäni on erittäin tärkeää, että sinulla on oma verkkoresurssi (URL-osoite), joka sisältää ohjeet tämän paketin käytöstä. Tätä verkkoresurssia käyttävät käyttöliittymän insinöörit ja suunnittelijat, ja se voi olla hyvä vertailukohde keskustelut niiden välillä.

Visuaalinen koodi

Yhteenveto:

Tällä hetkellä meillä on suunnittelujärjestelmä ja sen esitys paketissa ja sen interaktiivinen dokumentaatio. Jaamme ja otamme tämän paketin käyttöön kaikissa käyttöliittymässämme.

2. Koodirakenne

Let s talk a vähän suunnittelusta päivittäin. Teemme uusia ominaisuuksia, korjaamme virheitä, korjaamme koodin tarvittaessa. Me välitämme koodikannastamme, yritämme tehdä siitä mukavan ja helposti ymmärrettävän. Mutta mitä tapahtuu, kun yrityksessä ei ole yhtä, ei kahta, vaan kymmeniä pieniä tai suuria projekteja? Yleensä ihmiset ryhmitellään joidenkin projektien ympärille ja alkavat työskennellä vain tämän projektiryhmän kanssa. Inhimillisen luonteemme ja rajoitetun ajan perusteella emme yleensä voi huolehtia yli 2-3 projektista kerrallaan. Joten luonnollisesti meillä on niitä vaikutusryhmät. Btw, kiitos NASA: lle hämmästyttävästä kuvasta analogiani varten 😃

Vaikutusryhmät

Mutta meillä on yhä enemmän tapauksia, kun ihmiset ovat ristissä -joukkojen yhteistyö, täytyy tarkistaa toistensa koodi ja ratkaisut, korjata joitain virheitä myös muissa sovelluksissa tai lisätä jotain mitä tarvitset jossakin ulkoisessa sovelluksessa (vaikutusryhmänsä ulkoinen). Huono uutinen – että tämä prosessi tapahtuu suurissa yrityksissä lähes hallitsemattomana. Hyvä uutinen – voimme auttaa parantamaan sitä.

Kuinka? Oikea. Tarjoamalla saman koodirakenteen , koodauksen ja jäsentämisen ohjeet kaikille yrityksen projektit .

Kaivetaan syvemmälle mitä tarkoitamme koodirakenteella:

  • Projektin kansiorakenne
    Kun insinöörit hyppäävät uuteen projektiin ensimmäistä kertaa – samalla kansiorakenteella kuin omassa projektissaan projekti, jossa he tietävät kaiken auttavan paljon navigoinnissa ja haussa.
  • Määritys- tai tukitiedostot
    Tiedostot, kuten package.json, .gitignore, .editorconfig, webpack.config jne. Niiden tulisi olla aina samassa paikassa, jokaisessa projektissa. Sama on kytketty testikokoonpanotiedostoihin tai tarvittaessa CI-tiedostoihin.
  • Tiedostotyyppien kiinteä sijainti
    Jos samojen tiedostotyyppien sijainti on seuraava aina sama rakenne, se toimii myös hyvin. Esimerkiksi, jos komponenttikansiossa on aina style.css -tiedosto:
/Component
--/Component.tsx
--/style.css
--/index.ts
  • Komponenttien sisäinen rakenne
    Tiedostojen sisäisen rakenteen tulee olla sama: tuonnin, viennin järjestys, julkisen toiminnon sijainti , tyypit jne. Jokaisessa tiedostotyypissä on tiedettävä mitä odottaa.
  • Nimeämiskäytännöt
    Tämä sisältää kansioiden, tiedostojen, muuttujien, funktioiden, luokkien, tyyppien jne. nimet.
  • Koodauskäytännöt
    Yleisesti sanoisin, että koodauskäytännöt ovat hyvin laaja osa, mutta tässä haluan vain sisällyttää asioita, jotka eivät sopineet muihin osioihin, kuten ; tai not ; 😁 ja samanlainen .

Sama koodirakenne ja projektityökalusarja käytännössä ovat hyvin tiukkoja auttavat toisiaan rinnakkaiselossa. Työkalusarjalla tarkoitan CLI-työkaluja (projektin käynnistysvaihe, nukkaus, testaus jne.), IDE-laajennuksia jne. Keskustelemme työkalusarjan aiheista seuraavissa osissa.

Koodirakenne

Yhteenveto:

Tämän osan soveltamisen ja hyväksymisen jälkeen organisaatiossamme tulisi olla kaikki projektit, joilla on sama kansiorakenne, nimeämisohjeet, tiedostorakenne jne. Jokainen kehittäjä ihannetapauksessa voi hypätä mihin tahansa muuhun projektiin eikä olla täysin eksynyt siellä. Tämä ”täysin kadonnut” on myös hyvin yhteydessä projektin sisällä käytettävään tekniikkapinoon, joten puhutaan siitä.

3. Tekninen pino

Samanlainen kuin edellinen osiossa haluamme, että organisaation projekteissa on yhtenäinen tekninen pino . Syy tähän on hyvin samanlainen – haluamme, että insinöörit viihtyvät yrityksen kaikissa projekteissa.

Frontend-projekteissa teknisen pinon komponentit voivat olla: kyseiseen projektiin perustuva kehys on rakennettu, pääkieli, tyyliprosessori, tietokerros (esim. Apollo), valtionhallinta, testit, koodin nukkaus, rakennusjärjestelmä ja muut.

Kaikissa säännöissä on tietysti poikkeuksia. Ja tässä aiheessa haluaisin myös tehdä huomautus, että joskus jotkut tekniikat sopivat erittäin hyvin tiettyihin hankkeisiin, vaikka nämä tekniikat eivät olisikaan osa maailmanlaajuista yrityksenlaajuista teknologiapinoa. Mutta silti joka kerta tämä ajatus siirtyy pois com sinun pitäisi miettiä kahdesti, koska tällaisten asioiden tukemisesta aiheutuvat kustannukset ovat erittäin korkeat, joten hyötyjen on oltava dramaattisia.

Mainitsemme tässä joitain yleisiä teknisiä pinoja, jotka sopivat nyt suurimpaan osaan projekteja tietysti se kattaa vain osan todellisesta tekniikkapinosta, mutta voi olla hyvä lähtökohta jollekin 🤷):

Pino

Kun olemme määrittäneet yrityksessämme teknisen pinon ja sopineet siitä, on olemassa myös muita erittäin tärkeitä menestyksen pilareita .

Ensin – meidän on kirjoita tekninen pino dokumenttiin . Asiakirja, , jonka pitäisi olla hyvin ja helposti jaettavissa insinöörien kesken , jotta he voivat aina antaa linkin toisiinsa todisteena.

Toiseksi – meidän pitäisi kirjoittaa uudelleen ja jakaa -asiakirja miten miten uudet projektit tulisi aloittaa ja määritellä käynnistysvyö käyttämällä määriteltyä teknistä pinoa .

Tekninen pino

Yhteenveto:

Kun olemme toteuttaneet ja hyväksyneet kaikki edellä mainitut, sinun tulisi sinulla on kaikki projektisi organisaatiossa jakamaan sama tekninen pino. Ihannetapauksessa ilman eroja. Ei ihanteellisessa – merkityksettömillä eroilla. Jos lisäämme myös edellisen osan, myös koodin, kansioiden ja tiedostorakenteen tulisi olla melkein identtinen projekteissasi.Joten projektin läpi liikkumisen pitäisi olla erittäin helppo tehtävä. Hyvä 😊

4. Työkalut

Tämä aihe on erittäin tärkeä. Käytämme joitain lisätyökaluja nyt melkein kaikkialla – nukkaamiseen, sovellusten, CI: n, komponenttigeneraattoreiden rakentamiseen ja paljon muuta. Joten siksi näen, voimmeko valita oikean työkalun projektiisi – se on ratkaisevan tärkeää. Hyvä työkalu vs. huono työkalu (tai ei lainkaan työkaluja), se on sama kuin vertailu automaation ja manuaalisen testauksen välillä .

Puhuimme edellisissä osioissa juuri tekniikkapinoista ja koodirakenteesta ja mainitsimme, että meidän on kirjoitettava paljon asiakirjoja, jotta ihmiset voivat seurata heitä. Oikea työkalupakki voi kuitenkin antaa sinulle mahdollisuuden automatisoida yrityksesi ohjeita noudattamalla .

Esimerkiksi, jos sinulla on määritetty koodityyli – voit antaa ihmisille nukkaustyökalusarjan, joka oletusarvoisesti noudattaa näitä sääntöjä. Jos sinulla on määritelty tekninen pino, hyvä CLI-työkalu antaa sinulle mahdollisuuden käynnistää uuden projektin kyseisten tekniikoiden avulla tekniikkapinostasi paikallaan.

Yritetään keskustella minkä osan käyttöliittymäarkkitehtuurisi voidaan peittää työkaluilla:

  • Koodityyli ja rakenne
    Kuten aiemmin keskustelimme, tämä voidaan helposti automatisoida työkaluilla
  • Projektin käynnistyshihna
    Et ” Sinun ei tarvitse luoda uutta projektirakennetta, asentamalla kaikki tarvittavat paketit jne. manuaalisesti.
  • Komponenttien luominen
    Useimmiten jokin sovelluksesi komponentti ei sisällä edes yhtä tiedostoa, joten tiedostojen luominen, linkittäminen / tuominen voi viedä aikaa, joten tämä voidaan automatisoida.
  • Käynnistä ja rakenna
    Tietysti ilmeisin asia, jonka automaattinen kaveri – miten rakennat tai käynnistät sovelluksesi.
  • Testit
    Sovelluksen luominen sovellus testeille ja kaiken tyyppisten testien suorittaminen – yksikkö, integraatio jne.
  • Riippuvuuksien hallinta
    Kuten tiedämme, noin 80\% koodistamme on nyt riippuvuuksia. Joten meidän on pidettävä ne ajan tasalla, ja sen hallinta suuressa yrityksessä ei ole helppoa.
  • Hankkeiden väliset riippuvuudet
    Todennäköisesti projektimme eivät toimi erillään ja saattavat riippua muista projekteista tai olla riippuvaisia ​​jostakin muusta projektista, joten tarvitsemme joitain työkaluja helpottamaan niiden linkittämistä, kehittyminen useiden projektien (kuten bitti ) yhdistelmänä jne.
  • CI
    CI on olennainen osa päivittäistä työkalupakettiamme, ja sen automatisointi ja yhdistäminen voi olla erittäin hyödyllistä työtä organisaatiollesi.

Jos et halua kehittää uutta omaa työkalupakettia, voin suositella NX -työkalupakettia yhtenä mielenkiintoisimmista ehdokkaista. , näyttää siltä, ​​että Babelin luojat tekivät samanlaisen ratkaisun, jonka haluat ehkä tarkistaa – Rooma . Nämä työkalut eivät kata kaikkea, mutta suuren osan puhumastamme, joten ne voivat olla hyvä lähtökohta.

Työkalut

Yhteenveto:

Kuvittele vain, kuinka hienosta arkkitehtuuristamme voi tulla, kun kaikki osat on tehty ja otettu käyttöön adopted

Jokainen projekti on sama ja sitä ylläpitää ja hallinnoi yhtenäinen työkalusarja. Jokainen projekti voidaan aloittaa ja rakentaa samalla tavalla. Uusia komponentteja luodaan samassa paikassa ja samoilla nimitysohjeilla.

Mutta onko se ”makeaa” vai onko sillä haittoja? Kuten kaikilla ratkaisuilla, on haittoja. Yksi niistä – se vaatii jonkin aikaa uusien insinöörien aloittamiseen yrityksellesi. Mutta jos kaikki tehdään hyvin luonnollisella tavalla (kuten ihmiset tottuivat jo muihin olemassa oleviin työkaluihin) ja dokumentoidaan, tästä ei tule suuri ongelma, kun verrataan sitä kehityksen nopeuden etuihin, insinöörien tilaisuuteen työskennellä mikä tahansa koodipohja helposti jne.

5. Tuotanto

Tästä käyttöliittymäarkkitehtuurin osasta yleensä insinöörit huolehtivat vähiten.Ehkä koska se ei ole yhteydessä itse koodaukseen suurimman osan ajasta🤷 eikä luultavasti niin jännittävä, mutta ei vähäisintäkään tärkeämpää ☝️

Tuotannossa meidän on yleensä huolehdittava seuraavista asioista:

  • Analytics
    Kaikenlaiset erilaiset seurantatapahtumat jne. Esimerkiksi Google Analytics , Segmentti , HotJar jne.
  • Tilan valvonta
    Tämä sisältää asioita, kuten terveystarkastukset, voidaan jopa testit suoritetaan tuotannossa, virheilmoituksissa (kuten Sentry ) jne.
  • Suorituskyky
    Tämä on tavallaan samanlainen kuin edellinen, mutta suuntautunut enemmän suorituskykyyn. Tähän sisältyy vasteajan mittaus, ensimmäinen mielekäs maali jne. (Todennäköisesti työkalu # 1 – majakka )
  • A / B-testaus
    Kaikenlaiset A / B-testausratkaisut tai ominaisuusliput.
  • Välimuisti
    Tällaiset työkalut, kuten Lakka , Cloudflare .

Kaikki ne voidaan yhdistää yrityksen käyttöliittymiin, mikä helpottaa insinöörien elämää . Esimerkiksi lisäämällä paketteja, joiden alkuperäiset määritykset on määritelty ennalta, ja lisäämällä nämä paketit käynnistysstrapointiprojektiisi.

Toinen tuotannon osa on koodin valmistelu, kuten:

  • Minimointi
    Pelkkä koodin pienentäminen 😄
  • Lähteen kartoitus
    Lähdekarttoja voidaan tarvita myös joillekin muille työkaluille, kuten Sentrylle.
  • Varojen valmistelu
    Valmistautuminen eri resoluutioisten kuvien, kuvien rajaamiseen jne.

Nämä ovat upeita ehdokkaita lisättäviksi työkalupaketti, jota meillä on käyttöliittymäsovellusten hallintaan ja josta puhuimme Työkalut-osiossa.

Tuotanto

Yhteenveto:

Ihannetapauksessa kaikkien niiden pitäisi olla lisätään oletuksena kullekin käyttöliittymän projektille käynnistysvaiheen vaiheessa. Ja insinöörit huolehtivat vain siitä, että lisätään oikeat API-avaimet työkalujen oikeisiin paikkoihin.

6. Kehitys

CLI-työkalu

Keskustelimme jo osittain kehityskokemuksesta Työkalut-osiossa, kun kosketimme käyttöliittymän CLI-työkalua. Yhtenäinen työkalu on suuri osa insinöörien päivittäin, mutta ei kaikkea.

API

Mukava sovellusliittymä paikalliseen työskentelyyn on toinen mahtava asia, jonka voimme tehdä kehittäjän parantamiseksi kokemus ja kehitysnopeus. Yleensä sovellusliittymän tarjoaminen paikallisesti käyttöliittymän insinööreille ei ole triviaali prosessi: tämä voi sisältää työkalujen tai kehysten asentamisen, joita he eivät voi tuntea. Vaikka asennus telakoituna, tämä voi viedä valtavasti tietojenkäsittelyä resurssit kehittäjän koneilta (jos se ei ole – tätä voidaan pitää asennuksena) .Mikä voi olla ratkaisu tässä tapauksessa – ulkoinen palveleva sovellusliittymä. Tämä voi olla yksi palvelin kaikille insinööreille tai jokin mekanismi käynnistysvaiheelle helposti oma oma palvelimesi kehitystä varten.

CI

CI on kolmas iso osa. Oletan, että yrityksesi on jo valinnut jonkin käyttöliittymän työkalun käyttöliittymään ja käyttää tätä ainoaa työkalua (esim. Ympyrä CI ,

Concourse CI tai mikä tahansa muu). Jos ei – sinun tulisi yhtenäistää se.

Kyseisen projektin CI-kokoonpanon pitäisi mielestäni olla osa projektissa työskentelevän tiimin työtä. Tämä antaa CI: lle mahdollisuuden olla vakaa, koska on ihmisiä, jotka ovat kiinnostuneita siitä, että CI työskentelee, käyttää sitä joka päivä ja jolla on voimaa ja taitoja korjata, konfiguroida ja parantaa sitä.

Kuitenkin, ryhmän ei pitäisi tehdä kaikkea työtä. Etupään sovelluksille on olemassa melko erityinen joukko töitä, joita mahdollisesti voidaan tarvita. Varsinkin, jos pystyisimme yhtenäistämään kansio- / koodirakenteen, teknisen pinon jne. Joten jonkin ajan kuluttua yrityksessäsi saattaa tulla piste, kun pystyt havaitsemaan nämä mallit CI-työkalusi vaiheille, toteuta nämä vaiheet jonkinlaiset ”rakennuspalikat” ja anna insinööreillesi mahdollisuus rakentaa CI-putkistonsa yhtenäisistä ”rakennuspalikoista”.

Demoympäristöt

Ja viimeinen – toteutettu ominaisuus.Kun insinöörit ovat kaikki tehneet ja toteuttaneet – heidän on melkein aina tarkistettava miltä se näyttää ja miten se toimii, ja jakaa tämän muiden insinöörien, suunnittelijoiden tai muiden sidosryhmien kanssa. Tällaisiin tarpeisiin se toimii erittäin hyvin sovelluksen väliaikaisella käyttöönotetulla versiolla tietylle PR: lle annetulla URL-osoitteella.

Sovellus väliaikaisesti käyttöönotettu
Sovellus väliaikaisesti otettu käyttöön

Tämä ratkaisu nopeuttaa viestintää eri tiimien ja ihmisten välillä paljon ja mielestäni tämä on vain täytyy olla. Tämän väliaikaisesti asennetun version tulisi kuitenkin olla mahdollisimman lähellä tuotantoa, koska se voi olla myös erinomainen työkalu joidenkin pintavirheiden tai virheiden tarkistamiseen.

Tämä voidaan helposti lisätä projektiisi ja automatisoida, jos käyttöliittymäsi sovellusten rakennus- ja käyttöönottoprosessilinjat ovat yhtenäisiä. Myös sellaiset tai vastaavat työkalut, kuten Kubernetes ja Helm , voivat auttaa paljon toteutuksessa.

Kehitys

Yhteenveto:

Mukavat ja tehokkaat kehitysvirrat yhdellä CI-työkalulla ja rakennuspalikoilla CI-putki, yhtenäisillä CLI-käyttöliittymän työkaluilla ja demoympäristöillä. Kaikkien näiden pitäisi tehdä kehitysprosessistamme mahdollisimman sujuva. Kerro tämä yrityksessäsi olevien insinöörien lukumäärällä ja ymmärrät, kuinka hyödyllistä se on.

7. Modulaarisuus

Tämä aihe on erittäin iso ja saattaa vaatia erillisen artikkelin, josta yritän puhua, mutta yritän käydä sen läpi lyhyesti.

Suurissa organisaatioissa valtavat koodipohjat eivät ole harvinainen asia. Kaikilla heidän kanssaan tunnetuilla ongelmilla, kuten hitailla CI-putkistoilla, yhteistyötyössä, hitailla testeillä jne. Joten iso käyttöliittymän arkkitehtuurin osa on päätös siitä, kuinka rakeista haluamme nähdä itsenäiset käyttöliittymän sovellukset / moduulit.

Meillä on nyt kolme päämallia:

  • Monoliitti
    Yksi iso arkisto, jossa on yksi projekti ja kaikki siellä olevat koodit, kaikki tiimit työskentelevät tässä arkistossa samanaikaisesti.
  • Monorepo
    Monet projektit, mutta silti yksi iso arkisto ( monorepo wikissä ). Kaikki tiimit työskentelevät edelleen samassa arkistossa, mutta erilaisilla projekteilla. Jo nyt on olemassa mahdollisuuksia korjata joitain ongelmia, jotka meillä on monoliittisella lähestymistavalla, ajamalla putkistoja vain tietyille projekteille, projekteissa on pienempiä testipaketteja jne. Tällaisia ​​työkaluja, kuten Lerna voi tehdä elämästäsi paljon helpompaa, jos valitset tämän lähestymistavan.
  • Repo projektia kohti
    Jokaisella projektilla on oma arkisto ja kaikki tukevat asiat, kuten CI-putkistot, käyttöönotot jne.

Kaikissa näissä malleissa projekti voi tarkoittaa itsenäistä käyttöliittymän sivua, riippumaton käyttöliittymämoduuli jne. Tämä riippuu siitä, kuinka rakeinen haluat päättää jakaa käyttöliittymäsovelluksesi. Useimmissa tapauksissa tämän jaon on oltava synkronoituna halutun organisaatiorakenteen ja henkilöiden hallinnan kanssa.

Toinen iso aihe sen jälkeen, kun olet päättänyt jakaa sovelluksesi, on kuinka nämä kappaleet yhdistetään toisiinsa (jos päätit jakaa sovelluksesi).

Ja tässä meillä on seuraavat lähestymistavat:

  • Koontiajan sommittelu
    Projektisi voivat olla vain npm-paketteja, asennettuja ja koostettuja rakennuksen aikana.
  • Palvelin- sivukoostumus
    Tämä lähestymistapa sisältää yleensä palvelinpuolen renderoinnin ja palvelimella tapahtuvan kokoonpanon. Tällaiset työkalut, kuten Hypernova , voivat auttaa sen järjestämisessä.
  • Asiakaspuolen kokoonpano
    Selaimen sisällä olevien projektien kokoonpano. Martin Fowlerin blogissa on melko hyvä selitys joistakin lähestymistavoista – täällä . Lisäksi on erittäin tärkeää mainita Moduulien yhdistäminen , uusi lähestymistapa, joka on otettu käyttöön Webpack 5: ssä .
  • Reitin kokoonpano
    Erittäin yksinkertainen – vain jokaisella projektilla on oma URL-osoite ja ”Nginx-tasolla” päätämme, mihin käyttäjät ohjataan uudelleen.(anteeksi, tällaisesta selityksestä 😄 mutta ajattelin, että tämä on helpoin ymmärtää)

Kuten sanoin aiemmin, on erittäin vaikeaa käsitellä tätä aihetta niin pienessä muodossa, mutta toivon, että olet ainakin löytänyt mielenkiintoisia ideoita itsellesi ja syvennät itse aiheita 🙏🏻 .

modulaarisuus

Yhteenveto:

Löysimme tavan tehdä tiimeistämme onnellisia ja tuottavia järjestämällä arkistot, jakamalla projektimme pienempiin kappaleisiin (todennäköisesti), tekemällä joukkueista itsenäisempiä toisistaan.

Tervetuloa paratiisiin 😁

8. Testaus

Etupään sovellusten testaamisesta on saatavilla niin paljon resursseja, joten yritän olla käsittelemättä yksityiskohtia, jotka voit helppoa Löydä, mutta keskity enemmän suurten organisaatioiden kysymyksiin ja siihen, miten voimme ratkaista ne.

Ensimmäinen niistä – jokainen insinööri ymmärtää testaustekniikat eri tavalla, myös mitä tekniikkaa missä tilanteessa soveltaa, miten kirjoittaa hyvät ”testit jne. Joten on järkevää dokumentoida melko tarkasti kaikki yrityksessä käytetyt testaustasojen vivahteet ja ohjeet sekä ohjeet kullekin niistä.

Mahdolliset testaustasot sisällyttää testausstrategiaasi:

  • Yksikkötestaus
  • Integraatiotestaus
  • E2E-testaus
  • … ja muut

Lisäksi meidän on toisessa vaiheessa yhdistettävä ne yrityksen eri käyttöliittymäsovelluksissa, jotta ihmisillä ei olisi kysymyksiä siitä, miten ja mitä testata siirrettäessä toiseen projektiin.

Jos onnistut yhtenäistämään testaustasot ja lähestymistavat, voit auttaa ratkaisemaan toisen ongelman – testaamaan infrastruktuurin asetuksia. Jokaisen projektin on itse määritettävä ja konfiguroitava se paikallisesti ja CI: ssä jonkin testausinfrastruktuurin. Esimerkiksi päätimme käyttää Cypressia ja se on ajettava telakointikuvan sisällä. Tämä vaatii jonkin aikaa, jotta se voidaan määrittää paikallisesti ja CI: lle. Jos kerrotaan se hankkeiden lukumäärällä – se on valtava määrä aikaa. Joten, ratkaisu – yhdistää se uudestaan ​​ja tarjota työkaluja projekteille. Kuulostaa helpolta, mutta toteuttaa valtavasti aikaa.

Muu kuin kehitysajan testaus

Halusin myös koskettaa toista tapaa testata sovelluksiasi jo toteutettujen ja käyttöönotettujen ominaisuuksien jälkeen. Ja kyllä, tietysti sen seuranta on osa sitä 😁.

Olemme jo maininneet edellisissä osioissa käyttöliittymäsovellusten virheiden ja suorituskyvyn seurannan, käyttöajan seurannan, vastaukset eri paikoista.

On myös hienoa, että sinulla on Lighthouse -testit suoritetaan verkkosivustollasi (voidaan sisällyttää CI-putkilinjoihin). Löydät helpommat suorituskyvyn pullonkaulat, esteettömyysongelmat ja parantavat verkkosivujen laatua yleensä.

Ja viimeinen – tuotantotestit tärkeimmistä liiketoimintavirroista. Todennäköisesti ne toimivat parhaiten, jos suoritat ne suoraan tuotannossa ympäristöön, mutta voi olla myös mahdollista muunnos, kun voimme suorittaa tällaisia ​​testejä lavastus- / testiympäristössä, joka on hyvin lähellä tuotantoympäristöä tai jopa peilaa sitä. Aiheesta on erittäin mukava artikkeli – (täällä).

Testaus

Yhteenveto:

Meillä on selkeät testausohjeet ja määritellyt tarvittavat testaustasot kullekin käyttöliittymäsovellukselle. Meillä on yksi CI-putki jokaista sovellusta varten ja meillä on yksi CLI-työkalu, joka auttaa suorittamaan testejä paikallisesti.

Viimeinen sana

Toivon todella, että löysit jotain mielenkiintoista artikla. Olen hyvin pahoillani siitä, että useimmissa aiheissa olen vain naarmuuntunut asioiden pintaan. Ja keskustelee mielellään niistä enemmän, joten jätä kysymyksesi kommentteihin tai pingistä suoraan twitteriin – @denieler .