Flutter / utrzymanie
Co sprawdzić przed rozpoczęciem pracy nad istniejącą aplikacją Flutter?
Repozytorium Flutter to część produktu. Do jego utrzymania potrzebne są również konfiguracje platform, dostęp do API i możliwość wydania aktualizacji w sklepach. Warto sprawdzić je przed zadeklarowaniem terminu pierwszej zmiany.
1. Odtwórz wersję, którą mają użytkownicy
Ustal commit odpowiadający wersji w App Store i Google Play. Zapisz wersje Fluttera i Darta, kanał SDK oraz sposób wyboru wersji przez zespół. Sprawdź pubspec.yaml, pubspec.lock i ewentualne dependency_overrides. Nadpisana zależność może być świadomym obejściem błędu, którego nie wolno usunąć bez sprawdzenia.
Zbuduj aplikację w odizolowanym środowisku z dotychczasowym zestawem zależności. Nie zaczynaj od zbiorczej aktualizacji paczek. Sprawdź analizator i testy, ale także uruchom aplikację na obu platformach: poprawny build Androida nie mówi nic o kompletności konfiguracji iOS.
2. Poznaj przepływ danych i zarządzanie stanem
Prześledź jeden ważny scenariusz od ekranu, przez stan i warstwę danych, do API. Sprawdź odpowiedzialność modułów, zależności między nimi, nawigację i przechowywanie lokalnych danych. Nazwa biblioteki do zarządzania stanem nie wystarcza do oceny architektury.
Jeżeli projekt korzysta z BLoC, sprawdź zdarzenia, stany, obsługę błędów i anulowanie operacji. Przy innym rozwiązaniu zadawaj te same pytania o przepływ danych. Przejęcie nie wymaga od razu wymiany całego mechanizmu na preferowany przez nowy zespół.
W aplikacji Spontan Flutter i BLoC współpracują z backendem Laravel. To przykład konkretnego zestawu narzędzi, a nie wymóg dla każdego projektu.
3. Oddziel środowiska i sprawdź kontrakt API
Ustal, jak aplikacja wybiera adres API, identyfikator aplikacji i konfigurację usług: przez flavors, pliki środowiskowe czy parametry budowania. Wariant testowy powinien być rozpoznawalny i nie wysyłać danych do produkcji przez pomyłkę. Nie zakładaj, że sekret umieszczony w aplikacji mobilnej pozostanie tajny.
Sprawdź logowanie, przechowywanie tokenów, odświeżanie sesji i wylogowanie. Wykonaj scenariusze wygasłego tokenu, braku sieci i zmiany użytkownika. Ustal, jakie wersje API są wspierane i czy backend zachowuje zgodność ze starszą aplikacją.
4. Przetestuj push i deep links poza zwykłym otwarciem aplikacji
Przy powiadomieniach sprawdź konfigurację dostawcy, rejestrację i odświeżanie tokenu urządzenia oraz zgody systemowe. Przetestuj odbiór na pierwszym planie, w tle i otwarcie aplikacji z powiadomienia. Konfiguracja Firebase i APNs musi odpowiadać właściwej aplikacji oraz środowisku.
Deep link powinien prowadzić do właściwego ekranu również wtedy, gdy aplikacja nie działa lub użytkownik jest wylogowany. Ustal, co ma się stać z nieaktualnym identyfikatorem, usuniętą treścią albo linkiem do zasobu bez uprawnień. Link sam w sobie nie daje dostępu do danych.
5. Sprawdź Androida, iOS i prawo do wydania aktualizacji
Po stronie Androida przejrzyj identyfikator aplikacji, konfigurację Gradle i SDK, uprawnienia, warianty oraz podpisywanie wydania. Potrzebne są dostępy do właściwego konta Google Play i procesu zarządzania kluczami. Nie zastępuj klucza istniejącej aplikacji przypadkowo wygenerowanym nowym plikiem.
Po stronie iOS sprawdź Xcode, Bundle ID, zespół deweloperski, capabilities, certyfikaty i profile provisioning. Porównaj środowisko lokalne z procesem wydawania. Ustal, kto zarządza dostępem do App Store Connect; konto osobiste poprzedniego wykonawcy nie powinno być jedyną drogą do publikacji.
6. Odtwórz release i obserwację błędów
Jeżeli istnieje CI/CD, sprawdź konfigurację runnerów, wersje narzędzi, sekrety i przechowywanie artefaktów. Jeśli wydanie jest ręczne, zapisz kroki pozwalające innej osobie je powtórzyć. Przygotuj testowe wydanie w odpowiednim kanale dystrybucji przed zmianami funkcjonalnymi.
Zidentyfikuj analitykę i crash reporting, jeżeli są używane. Sprawdź, czy raporty dają się powiązać z wersją aplikacji i czy zespół ma do nich dostęp. Nie dodawaj nowego śledzenia tylko dlatego, że starej konfiguracji brakuje; zakres zbierania danych wymaga świadomej decyzji.
7. Ustal kolejność zmian i warunek gotowości
Najpierw oddziel problemy blokujące build lub publikację od prac porządkowych. Aktualizacje Fluttera, paczek i konfiguracji natywnej zaplanuj z testami regresji. Sprawdź, które biblioteki są utrzymywane, które wymagają migracji i czy zastąpienie jednej nie wymusi zmian w całej aplikacji.
Przejęcie można uznać za operacyjnie przygotowane, gdy zespół potrafi zbudować obie wersje, odtworzyć najważniejsze scenariusze, zdiagnozować błąd i wydać aktualizację. Braki w dostępach lub podpisywaniu są realnymi blokadami, nawet jeśli kod wygląda dobrze.
Zakres przejęcia i dalszego rozwoju opisujemy w ofercie aplikacji mobilnych Flutter.
Dokumentacja do dalszej pracy
Instrukcje wdrożeniowe dobierz do wersji używanej w swoim projekcie. Poniższe źródła rozwijają opisane zagadnienia.