Kuvakaappausautomaatio: täydellinen resurssiopas

Tyypillinen mobiilisovelluksen lanseeraus julkaisee 6–10 kuvakaappausta laitekokoa kohden, 4–8 laitekoossa, 8–20 kieliversiossa. Matematiikka karkaa nopeasti käsistä: pieni lanseeraus on 200–800 kuvakaappausta, ja suuri monikielilanseeraus voi helposti ylittää 2 000. Ensimmäinen versio vie suunnittelijaviikon. Viides versio, kun markkinointi on iteroinut tekstejä, vie sekin suunnittelijaviikon. On selvä piste, jossa mikä tahansa aktiivisesti tuotetta kehittävä tiimi ei enää pysty pysymään kärryillä manuaalisesti.

Automaatio on ainoa ulospääsy. Kun voit renderöidä koko ruudukon ohjelmallisesti, vaihdat suunnittelijaviikon julkaisua kohden CI-työhön, joka pyörii 90 sekunnissa. Tämä avaa korkean nopeuden silmukan, jossa julkaiset käyttöliittymämuutoksia ja kauppapäivityksiä samassa julkaisussa — sen sijaan, että kaupan kuvakaappaukset jäävät pysyvästi neljänneksen tai enemmän jälkeen elävästä sovelluksesta.

Kypsässä putkessa on neljä liikkuvaa osaa: versionhallinnoitu lähteen totuus (mallien määrittelyt Gitissä, yleensä YAML- tai JSON-muodossa), datakerros (merkkijonot, kuvakaappaukset ja tuotekuvat, jotka täyttävät mallit), renderöintimoottori (palvelu, joka muuttaa mallin + datan PNG/JPEG-tulosteeksi jokaisessa vaaditussa koossa) ja toimituskohde (App Store Connect API, Google Play Publishing API tai aineistokoria, josta kauppalistauksen tiimi vetää aineistot). Jokainen kerros voidaan vaihtaa itsenäisesti.

Mielenkiintoiset suunnitteluvalinnat ilmenevät saumakohdissa. Kuinka versioit mallin? Tarkistatko renderöidyn tulosteen repoon vai luotko sen uudelleen jokaisella CI-ajolla? Välimuistitatko renderöinnit sisältötiivisteen mukaan? Kuinka esikatselet muutoksia PR-katselmuksessa käynnistämättä koko putkea? Alla olevat linkit kattavat jokaisen näistä syvällisesti.

Kuvakaappausautomaatiossa on kaksi arkkitehtuurileiriä: API-renderöintipalvelut, jotka ottavat mallimäärittelyn ja tuottavat tulosteen hallitun renderöintimoottorin kautta, ja oma-tee-itse headless-selainputket (Puppeteer, Playwright, Cypress), jotka ottavat kuvakaappauksen verkkosivusta ja jälkikäsittelevät tuloksen. Molemmat toimivat; kompromissit ovat todellisia.

Headless-selainputket ovat joustavia mutta operatiivisesti raskaita: ylläpidät selainfarmia, fonttien hallintaa, fonttien vaihtoehtoa jokaiselle kieliversiolle, uudelleenyrityslogiikkaa epävakaille renderöinneille ja jonoa. API-renderöinti siirtää tämän kaiken palveluun, joka on viritetty erityisesti kuvakaappauskäyttötapaukseen. Useimmille tiimeille API-renderöinti on nopeampi pystyttää ja nopeampi renderöintiä kohden; headless-selaimet ovat oikea valinta, kun kuvakaappauksesi sisältävät raskaita DOM- tai CSS-ominaisuuksia, joita mallinnusmoottori ei pysty toistamaan.

fastlane on ollut iOS:n tosiasiallinen automaatiotyökalu yli vuosikymmenen, ja siinä on kaksi olennaista lanea kuvakaappauksille: sisäänrakennettu snapshot-toiminto (joka käyttää XCUITestejä kuvakaappausten ottamiseen simulaattorista) ja frameit (joka ympäröi otetut kuvakaappaukset laitekehyksillä). Simulaattoripohjaisille testeille tämä toimii edelleen, mutta sillä on rajoituksia: suunnittelukielioppi määräytyy sen mukaan, mitä sovelluksesi voi renderöidä automatisoidussa UITestissä, eikä sen mukaan, mitä markkinointitiimisi haluaa julkaista, ja frameit-mallikieli on rajoittunut.

Moderni malli on käyttää fastlanea orkestroijana (lähetys App Store Connectiin, version nostot, TestFlight-jakelu) ja API-renderöintipalvelua, kuten Screenshots.liveä, varsinaisten kuvakaappaustiedostojen tuottajana. fastlanella on ensiluokkainen lisäosatuki, joten voit pudottaa sisään kuvakaappauslisäosan, joka renderöi ja lähettää samassa lanessa.

Kolme järkevää mallia. (1) Jokaisella main-haaran työnnöllä: regeneroit kuvakaappaukset spekulatiivisesti, tallennat ne build-artefakteina ja edistät niitä vain julkaisutageissä. Nopea palaute, hieman tuhlaavaa. (2) Vain julkaisutageissä: siisteintä, mutta kuvakaappausten regressiot huomataan vasta version lukitsemisen jälkeen. (3) Erillisessä vain kuvakaappauksille tarkoitetussa työnkulussa, joka käynnistyy mallitiedostojen muuttuessa: paras tiimeille, joilla on vahva ero tuotekehityksen ja kasvun välillä.

Mihin tahansa malliin päädyt, käsittele kuvakaappaustiedostoja kuten muitakin generoituja artefakteja: älä tarkista niitä Gitiin. Lähteen totuus elää malleissa, ei renderöidyissä PNG-tiedostoissa. Tämä on suurin yksittäinen virhe, jonka tiimit tekevät kytkiessään kuvakaappausautomaation olemassa olevaan repoon.

Modernissa automaatioputkessa tulisi olla pikselivertailu- tai havaintotiivistetarkistuksia renderöidylle tulosteelle. Tavoite on saada kiinni hiljainen rikkoutuminen: fontti, joka putosi varafonttiin, käännös, joka vuoti yli, kuvavarallisuus, joka 404. Työkaluja kuten BackstopJS, Percy ja Chromatic voi käyttää uudelleen kauppakuvakaappauksiin, tai voit kirjoittaa pienen diff-työn, joka kaataa CI:n, kun renderöinti ylittää kynnyksen.

Tässä myös monikieliautomaatio muuttuu mielenkiintoiseksi: 60 kuvakaappauksen renderöinti on hyvä, mutta 60:n manuaalinen tarkastaminen tekstin yli vuotamisen varalta on mahdotonta. Automatisoidut visuaaliset tarkistukset ovat se, mikä tekee monikieliautomaatiosta turvallista skaalassa.