Ongelma: 20 sovellusta, 20 brändiä, satoja kuvakaappauksia

Muutama vuosi sitten työskentelin kehittäjänä startup-yrityksessä, jossa rakensimme whitelabel-mobiilisovellusta. Yksi koodipohja, mutta 20 eri asiakasta — jokaisella oma brändi-identiteettinsä, värinsä, logonsa ja App Store -merkintänsä. Jokainen tarvitsi oman sarjansa kiillotettuja App Store- ja Google Play -kuvakaappauksia.

Jos olet koskaan julkaissut sovelluksen, tunnet rutiinin: Apple haluaa kuvakaappauksia jokaiselle laitteen koolle (6.7", 6.5", 5.5", iPad Pro, iPad...), Google Play haluaa oman sarjansa, ja jos tuet useita kieliä, kerrot kaiken jälleen. Kerro nyt se 20 asiakkaalla.

Puhumme tuhansista kuvakaappauksista, jotka piti luoda, kehystää laitteen mockupeihin, brändätä oikeilla väreillä ja ladata — jokaisessa julkaisusyklissä.

Mitä meillä oli: automaattiset kuvakaappaukset putkessa

Raa'at kuvakaappaukset itsessään eivät olleet ongelma. Se oli ratkaistu. UI-testimme, joita ajettiin GitLab CI -putkessamme, käynnistivät jokaisen sovellusversion, navigoivat avainruutujen läpi ja ottivat kuvakaappauksia automaattisesti. Fastlanen snapshot (iOS) ja screengrab (Android) hoitivat raskaan työn.

Joten meillä oli satoja raakoja PNG-tiedostoja, jotka laskeutuivat putken artefakteihimme jokaisen buildin jälkeen. Hienoa. Mutta raa'at kuvakaappaukset eivät mene App Storeen. Ne täytyy käsitellä — sijoittaa laitekehyksiin, antaa tausta, joka vastaa asiakkaan brändiä, peittää markkinointitekstillä ja viedä tarkoissa pikselimitoissa, joita kukin kauppa vaatii.

Kipupisteet

1. Suunnittelijan pullonkaula

Suunnittelijamme oli lahjakas, mutta pyytää häntä manuaalisesti päivittämään Figma-tiedostoja 20 brändille jokaisessa julkaisussa oli absurdia. Hän vietti päiviä vain kuvakaappausten vaihtamiseen ja värien säätämiseen. Ja jos asiakas muutti brändi-identiteettiään syklin puolivälissä? Aloita alusta.

2. Ei aikaa rakentaa sisäisiä työkaluja

Olimme startup. Jokainen sprintti oli täynnä ominaisuuksia, virheenkorjauksia ja asiakaspyyntöjä. Sisäisen kuvakaappausten käsittelypalvelun rakentaminen — mallijärjestelmällä, laitekehysten renderöinnillä, tekstin peittämisellä ja kauppakohtaisella viennillä — oli kuukausien projekti, jota emme yksinkertaisesti voineet perustella. Meidän piti toimittaa tuote, ei työkaluja.

3. Manuaalinen työ, joka ei skaalannut

Jonkin aikaa kokeilimme puolimanuaalista lähestymistapaa: suunnittelija loi malleja, skripti käsitteli ne eränä ja joku tarkisti ja latasi manuaalisesti. Mutta tämä hajosi jatkuvasti. Fontti olisi väärä, kehys ei kohdistuisi, teksti valuisi yli saksaksi mutta näyttäisi hyvältä englanniksi. Jokainen reunatapaus muuttui hälytystilanteeksi.

4. Putken integrointi oli puuttuva pala

Halusimme täysin automatisoitua virtausta: koodi työnnetään, putki ajaa testit, kuvakaappaukset kaapataan, kuvakaappaukset käsitellään oikealla brändäyksellä ja Fastlane lataa ne kaupoille. Puuttuva pala oli aina käsittelyvaihe. Ei ollut palvelua, jota voisimme yksinkertaisesti kutsua CI-putkellemme API:lla.

Miten ratkaisimme sen

Tämä turhautuminen on tarkalleen syy, miksi Screenshots Live on olemassa. Idea oli yksinkertainen: käsittelypalvelu, joka ottaa raa'at kuvakaappaukset, soveltaa suunnittelijoiden luomia malleja laitekehyksillä ja brändäyksellä, ja palauttaa kauppavalmiin kuvat — kaikki yksinkertaisella API-kutsulla, joka sopii mihin tahansa CI/CD-putkeen.

GitLab + Fastlane -integraatio

Näin putkemme näytti Screenshots Liven integroinnin jälkeen:

Rakennus- ja testausvaihe: GitLab CI rakentaa sovelluksen jokaiselle whitelabel-versiolle. UI-testit ajetaan ja raa'at kuvakaappaukset kaapataan Fastlane snapshot / screengrab -työkaluilla.
Kuvakaappausten käsittelyvaihe: Yksinkertainen skripti käy läpi kaapatut kuvakaappaukset, kutsuu Screenshots Liveä oikealla malli-ID:llä ja brändäysparametreillä jokaiselle asiakkaalle ja lataa käsitellyt kuvat.
Latausvaihe: Fastlane deliver (iOS) ja supply (Android) lataavat käsitellyt kuvakaappaukset kyseisiin kauppoihin.

Koko virtaus — koodin työntämisestä kauppavalmisiin kuvakaappauksiin — tuli täysin automatisoiduksi. Ei suunnittelijan osallistumista rutiinijulkaisuihin. Ei manuaalista QA:ta kuvakaappausten asetteluille. Ei hälytystilanteita, kun asiakas pyysi hotfix-julkaisua perjantaina klo 17.

Mitä muuttui

Ajansäästöt

Se, mikä vei suunnittelijaltamme 2-3 päivää julkaisusykliä kohden, vie nyt nolla ihmisaikaa. Putki hoitaa kaiken. 20 sovellukselle, jotka julkaisevat kahden viikon välein, se on noin 40-60 suunnittelijan työpäivää säästettyinä vuodessa — aikaa, jonka suunnittelijamme saattoi käyttää todelliseen tuotesuunnitteluun toistuvien kuvakaappausten kokoamisen sijaan.

Johdonmukaisuus

Jokainen kuvakaappaus, jokaiselle asiakkaalle, jokaiselle laitteen koolle, noudattaa täsmälleen samaa mallia. Ei enää ongelmia, kuten "iPhone 15 Pro Max -versiossa teksti on hieman väärin kohdistettu". Mallit ovat pikselinä täydellisiä ja niitä sovelletaan johdonmukaisesti joka kerta.

Suunnittelijan riippumattomuus

Suunnittelijamme saattoi päivittää malleja milloin halusi — uudet laitekehykset, päivitetty markkinointiteksti, sesonkisuunnitelmat — ilman kehittäjien osallistumista. Hän päivitti mallin visuaalisessa editorissa ja seuraava putken ajo poimi sen automaattisesti.

Asiakkaiden onboarding

Uuden whitelabel-asiakkaan lisääminen muuttui "suunnittele 2 päivän suunnittelutyötä" -tilasta "luo uusi mallivariantti heidän brändiväreillään ja logollaan" -tilaan. Putki hoiti loput.

Miksi teemme sen saataville

Käytettyämme tätä sisäisesti ja nähtyämme kuinka paljon aikaa se säästää, tajusimme, että tämä ei ollut meille ainutlaatuinen ongelma. Jokainen sovelluskehittäjä, joka julkaisee App Storeen tai Google Playhin, käsittelee kuvakaappausten luomista. Whitelabel-kehittäjillä on se vaikeinta, mutta jopa yhden sovelluksen tiimillä, jolla on monikielinen tuki, on sama kerroinongelma.

Joten siistimme sen, rakensimme asianmukaisen API:n dokumentaatiolla, lisäsimme mallieditorin, jota ei-kehittäjät voivat käyttää, ja avoimme sen. Jos käytät tunteja App Store -kuvakaappausten manuaaliseen luomiseen, tai jos putkessasi on aukko "kaappaa kuvakaappauksia" ja "lataa kauppaan" välillä, Screenshots Live täyttää tuon aukon.

Rakensimme sen, koska tarvitsimme sitä. Jaamme sen, koska tiedämme, että sinäkin tarvitset sitä.