Problem: 20 aplikacji, 20 marek, setki zrzutów ekranu

Kilka lat temu pracowałem jako deweloper w startupie, gdzie budowaliśmy aplikację mobilną whitelabel. Jedna baza kodu, ale 20 różnych klientów — każdy z własną identyfikacją wizualną, kolorami, logotypami i kartami w App Store. Każdy potrzebował własnego zestawu dopracowanych zrzutów ekranu do App Store i Google Play.

Jeśli kiedykolwiek opublikowałeś aplikację, znasz rutynę: Apple chce zrzutów ekranu dla każdego rozmiaru urządzenia (6.7", 6.5", 5.5", iPad Pro, iPad...), Google Play ma własny zestaw, a jeśli obsługujesz wiele języków, mnóż wszystko znowu. Teraz pomnóż to przez 20 klientów.

Mówimy o tysiącach zrzutów ekranu, które trzeba było wygenerować, oprawić w makiety urządzeń, opatrzyć właściwymi kolorami i przesłać — przy każdym cyklu wydania.

Co mieliśmy: zautomatyzowane zrzuty ekranu w pipeline'ie

Same surowe zrzuty ekranu nie były problemem. Z tym sobie poradziliśmy. Nasze testy UI, działające w naszym pipeline'ie GitLab CI, uruchamiały każdy wariant aplikacji, poruszały się po kluczowych ekranach i automatycznie robiły zrzuty ekranu. snapshot Fastlane (iOS) i screengrab (Android) wykonywały ciężką robotę.

Mieliśmy więc setki surowych plików PNG lądujących w naszych artefaktach pipeline'u po każdym buildzie. Świetnie. Ale surowe zrzuty ekranu nie trafiają do App Store. Muszą zostać przetworzone — umieszczone wewnątrz ramek urządzeń, z tłem odpowiadającym marce klienta, z nałożonymi tekstami marketingowymi i wyeksportowane w dokładnych wymiarach pikseli wymaganych przez każdy sklep.

Punkty bólu

1. Wąskie gardło projektanta

Nasz projektant był utalentowany, ale proszenie go o ręczne aktualizowanie plików Figma dla 20 marek przy każdym wydaniu było absurdalne. Spędzał dni tylko na wymienianiu zrzutów ekranu i dostosowywaniu kolorów. A jeśli klient zmienił identyfikację wizualną w trakcie cyklu? Zacznij od nowa.

2. Brak czasu na budowanie wewnętrznych narzędzi

Byliśmy startupem. Każdy sprint był wypełniony funkcjami, poprawkami błędów i prośbami klientów. Budowanie wewnętrznego serwisu do przetwarzania zrzutów ekranu — z systemem szablonów, renderowaniem ramek urządzeń, nakładaniem tekstu i eksportem specyficznym dla sklepu — było wielomiesięcznym projektem, którego po prostu nie mogliśmy uzasadnić. Musieliśmy dostarczać produkt, a nie narzędzia.

3. Ręczna praca, która nie skalowała się

Przez jakiś czas próbowaliśmy półautomatycznego podejścia: projektant tworzył szablony, skrypt przetwarzał je wsadowo, a ktoś ręcznie weryfikował i przesyłał. Ale to ciągle się psuło. Czcionka byłaby zła, ramka nie wyrównywała się, tekst wylewał się po niemiecku, ale wyglądał dobrze po angielsku. Każdy przypadek brzegowy stawał się kryzysem.

4. Integracja z pipeline'em była brakującym elementem

Chcieliśmy w pełni zautomatyzowanego przepływu: kod jest wypychany, pipeline uruchamia testy, zrzuty ekranu są przechwytywane, zrzuty ekranu są przetwarzane z właściwą identyfikacją wizualną i Fastlane przesyła je do sklepów. Brakującym elementem zawsze był krok przetwarzania. Nie było żadnego serwisu, który można by po prostu wywołać z naszego pipeline'u CI przez API.

Jak to rozwiązaliśmy

Ta frustracja jest dokładnie powodem, dla którego Screenshots Live istnieje. Pomysł był prosty: serwis przetwarzający, który przyjmuje surowe zrzuty ekranu, stosuje szablony stworzone przez projektantów z ramkami urządzeń i identyfikacją wizualną, i zwraca obrazy gotowe dla sklepów — wszystko przez proste wywołanie API, które pasuje do dowolnego pipeline'u CI/CD.

Integracja GitLab + Fastlane

Oto jak wyglądał nasz pipeline po integracji Screenshots Live:

Etap Build & Test: GitLab CI buduje aplikację dla każdego wariantu whitelabel. Testy UI uruchamiają się i przechwytują surowe zrzuty ekranu przy użyciu Fastlane snapshot / screengrab.
Etap przetwarzania zrzutów ekranu: Prosty skrypt przechodzi przez przechwycone zrzuty ekranu, wywołuje Screenshots Live z właściwym ID szablonu i parametrami identyfikacji wizualnej dla każdego klienta, i pobiera przetworzone obrazy.
Etap przesyłania: Fastlane deliver (iOS) i supply (Android) przesyłają przetworzone zrzuty ekranu do odpowiednich sklepów.

Cały przepływ — od wypchnięcia kodu do zrzutów ekranu gotowych dla sklepu — stał się w pełni zautomatyzowany. Bez angażowania projektanta przy rutynowych wydaniach. Bez ręcznego QA układów zrzutów ekranu. Bez kryzysów, gdy klient poprosił o hotfix w piątek o 17:00.

Co się zmieniło

Oszczędność czasu

To, co zajmowało naszemu projektantowi 2-3 dni na cykl wydania, teraz zajmuje zero czasu ludzkiego. Pipeline zajmuje się wszystkim. Dla 20 aplikacji wydawanych co dwa tygodnie, to około 40-60 dni projektanta zaoszczędzonych rocznie — czas, który nasz projektant mógł spędzić na prawdziwym projektowaniu produktu zamiast na powtarzalnym składaniu zrzutów ekranu.

Spójność

Każdy zrzut ekranu, dla każdego klienta, dla każdego rozmiaru urządzenia, podąża dokładnie za tym samym szablonem. Koniec z problemami w stylu "wersja iPhone 15 Pro Max ma tekst lekko nierówno". Szablony są idealnie pikselowe i są stosowane spójnie za każdym razem.

Niezależność projektanta

Nasz projektant mógł aktualizować szablony kiedy chciał — nowe ramki urządzeń, zaktualizowane teksty marketingowe, sezonowe wzory — bez potrzeby angażowania deweloperów. Aktualizował szablon w edytorze wizualnym, a następne uruchomienie pipeline'u pobierało go automatycznie.

Onboarding klientów

Dodawanie nowego klienta whitelabel przeszło z "zaplanuj 2 dni pracy projektanta" do "stwórz nowy wariant szablonu z ich kolorami i logo". Pipeline zajmował się resztą.

Dlaczego udostępniamy to innym

Po użyciu tego wewnętrznie i zobaczeniu, ile czasu oszczędzało, zdaliśmy sobie sprawę, że to nie był problem unikalny dla nas. Każdy deweloper aplikacji, który publikuje w App Store lub Google Play, ma do czynienia z generowaniem zrzutów ekranu. Deweloperzy whitelabel mają to najgorzej, ale nawet team z jedną aplikacją z obsługą wielu języków stoi przed tym samym problemem mnożenia.

Więc wyczyściliśmy to, zbudowaliśmy właściwe API z dokumentacją, dodaliśmy edytor szablonów, którego mogą używać nie-deweloperzy, i otworzyliśmy to. Jeśli spędzasz godziny ręcznie tworząc zrzuty ekranu App Store, lub jeśli twój pipeline ma lukę między "przechwytywaniem zrzutów ekranu" a "przesyłaniem do sklepu", Screenshots Live wypełnia tę lukę.

Zbudowaliśmy to, bo tego potrzebowaliśmy. Udostępniamy to, bo wiemy, że ty też tego potrzebujesz.