Wdrożenie nowej wersji aplikacji na produkcję potrafi przyprawić o szybsze bicie serca. Czy na pewno o wszystkim pamiętaliśmy? Nawet drobne przeoczenie - zapomniany connection string, wyłączony monitoring, brak backupu - potrafi zamienić spokojny wieczór w gorączkowe gaszenie pożaru i pilną łatkę tuż po release.
Dlatego warto mieć checklistę. Taką, dzięki której przed każdym wdrożeniem przejdziesz krok po kroku przez kluczowe obszary: od testów, przez wydajność i konfigurację, aż po plan awaryjny. To prosty nawyk, który oszczędza nerwów - szczególnie liderowi technicznemu, który w natłoku zadań przed releasem musi mieć pewność, że nic nie umknęło.
Oto 6 rzeczy, które warto sprawdzić, zanim aplikacja .NET trafi na produkcję.
1. Wszystkie testy przechodzą na zielono
Żadne wdrożenie nie powinno ruszyć, jeśli pakiet testów automatycznych - jednostkowych i integracyjnych - nie przechodzi w całości. Ignorowanie czerwonych testów to proszenie się o kłopoty: błędy, które mogłeś złapać na pipeline, ujawnią się dopiero na produkcji, u użytkowników.
Najlepiej, gdy dotnet test jest częścią Twojego CI i blokuje merge, gdy cokolwiek się wywala - wtedy "zielono" nie jest kwestią dobrej woli, tylko warunkiem wejścia. Warto też rzucić okiem na pokrycie kodu (code coverage), ale traktuj je jako sygnał, a nie cel sam w sobie - 100% pokrycia nie znaczy, że przetestowałeś to, co naprawdę ważne.
Na koniec upewnij się, że najważniejsze ścieżki w aplikacji zostały sprawdzone ręcznie - przez QA lub samych programistów - pod kątem krytycznych scenariuszy. Dzięki temu minimalizujesz ryzyko, że nowa wersja wprowadzi regresję, którą jako pierwsi zauważą użytkownicy końcowi.
2. Wydajność sprawdzona pod obciążeniem
Brak testów wydajnościowych to jedna z najczęstszych przyczyn niemiłych niespodzianek po wdrożeniu - zwłaszcza jeśli spodziewasz się większego ruchu. Aplikacja, która śmiga na Twoim laptopie, potrafi paść pod obciążeniem, którego nikt wcześniej nie zasymulował.
Przed releasem sprawdź, jak zachowuje się pod presją. Do testów obciążeniowych świetnie nadają się narzędzia takie jak k6, NBomber (napisany w .NET, więc naturalny wybór dla wielu zespołów) czy JMeter. Jeśli chcesz zmierzyć wydajność konkretnego fragmentu kodu, sięgnij po BenchmarkDotNet.
Na co patrzeć?
• Czas odpowiedzi kluczowych endpointów - nie tylko średnią, ale też percentyle p95 i p99, bo to one pokazują, jak aplikacja traktuje "pechowych" użytkowników.
• Zużycie zasobów - CPU i pamięć pod docelowym obciążeniem, z zapasem na szczyty.
• Skalowalność - czy aplikacja obsłuży zakładany ruch i co się dzieje, gdy go przekroczysz.
Przy okazji łatwo wychwycić klasyczne wąskie gardła: zapytania N+1 do bazy, brakujące async/await blokujące wątki czy wyczerpujący się pool połączeń. Zdecydowanie lepiej znaleźć je w kontrolowanym teście niż na produkcji, gdy użytkownicy już czują ból.
3. Konfiguracja produkcyjna zweryfikowana
Upewnij się, że aplikacja naprawdę działa w trybie produkcyjnym z odpowiednimi ustawieniami. W ASP.NET Core zmienna środowiskowa ASPNETCORE_ENVIRONMENT powinna mieć wartość Production - to m.in. wyłącza szczegółowe strony błędów (które potrafią wyciekać wrażliwe informacje) i pozwala włączyć optymalizacje takie jak HSTS.
Przejdź po kolei przez konfigurację:
• Pliki ustawień (appsettings.Production.json), zmienne środowiskowe i connection stringi - wszystkie powinny wskazywać na produkcyjne zasoby: bazy danych, kolejki, usługi zewnętrzne.
• Żadnych tymczasowych ustawień, kluczy testowych ani sekretów zaszytych w kodzie. Wrażliwe dane powinny trafiać do aplikacji bezpiecznym kanałem - np. z Azure Key Vault, AWS Secrets Manager czy zmiennych środowiskowych - a nie z repozytorium.
• Publikacja w kompilacji Release, nie Debug (dotnet publish -c Release), żeby uzyskać zoptymalizowany kod i lepszą wydajność.
Dobrą praktyką jest też walidacja konfiguracji przy starcie aplikacji (np. przez wzorzec Options z ValidateOnStart), tak aby brakujący klucz czy literówka w ustawieniach wysadziły aplikację od razu przy uruchomieniu - a nie dopiero przy pierwszym żądaniu użytkownika.
Domyślny szablon ASP.NET Core używa poniższej konstrukcji, żeby stosować odpowiednie ustawienia na produkcji:
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error"); /* Strona błędów dla produkcji */
app.UseHsts(); /* HTTP Strict Transport Security */
}4. Logi i monitoring działają
Monitoring i logi to Twoja pierwsza linia obrony po wdrożeniu. Bez nich pierwszym "alertem" o awarii będzie wiadomość od zdenerwowanego klienta.
Zadbaj o kilka rzeczy:
• Logowanie zdarzeń i wyjątków na odpowiednim poziomie szczegółowości. Warto postawić na logi strukturalne (np. Serilog), które łatwo przeszukiwać i filtrować.
• Miejsce, do którego trafiają logi - Seq, Application Insights, ELK, Grafana Loki czy choćby uporządkowane pliki na serwerze. Ważne, żebyś wiedział, gdzie ich szukać, zanim zaczniesz ich potrzebować.
• Health checki - endpoint zdrowia (AddHealthChecks), po którym load balancer i monitoring poznają, że instancja żyje i ma dostęp do zależności (bazy, kolejek).
• Metryki i alerty - CPU, pamięć, czas odpowiedzi, liczba błędów. Ustaw alerty na nietypowe skoki błędów lub spadek dostępności, żeby dowiedzieć się o problemie od systemu, a nie od użytkownika.
I jedno praktyczne sprawdzenie: zanim uznasz temat za zamknięty, wywołaj kontrolowany błąd i zobacz, czy faktycznie pojawił się tam, gdzie się spodziewasz. Monitoring, którego nikt nie przetestował, lubi milczeć w najgorszym momencie.
5. Backup bazy danych wykonany
Przed wprowadzeniem zmian upewnij się, że masz aktualną kopię zapasową produkcyjnej bazy danych. W razie poważnego błędu lub nieudanej migracji schematu będziesz mógł szybko wrócić do poprzedniego stanu.
Nigdy nie zakładaj, że "nic się nie stanie" - backup to polisa ubezpieczeniowa, która potrafi uratować aplikację przed długim przestojem albo utratą danych. Wykonaj pełny backup tuż przed wdrożeniem i, co równie ważne, upewnij się, że potrafisz go odtworzyć. Kopia, której nigdy nie próbowałeś przywrócić, to tak naprawdę tylko nadzieja, a nie backup.
6. Plan wycofania (rollback) gotowy
Każdy doświadczony zespół ma przygotowany scenariusz na wypadek niepowodzenia. Jeśli po wypuszczeniu nowej wersji coś pójdzie nie tak, musisz wiedzieć, jak szybko przywrócić poprzednią stabilną wersję - bez improwizacji o 2 w nocy.
W praktyce oznacza to najczęściej:
• utrzymanie poprzedniego builda gotowego do natychmiastowego wdrożenia,
• albo przełączenie ruchu na starszą wersję (strategia blue-green lub canary),
• a coraz częściej - ukrycie nowej funkcji za feature flagą, którą można wyłączyć bez ponownego deployu.
Jeśli wdrożenie zawiera zmiany w bazie danych, zaplanuj z góry, jak cofnąć migracje (w EF Core przemyśl, czy Twoje migracje da się bezpiecznie odwrócić) - albo przynajmniej zabezpiecz dane backupem z punktu 5. Rolą lidera technicznego jest mieć ten scenariusz opracowany zanim pojawi się problem, nawet jeśli prawdopodobnie nigdy nie trzeba będzie z niego skorzystać.
Podsumowanie
Wdrożenie aplikacji .NET na produkcję zawsze będzie wyzwaniem, ale z taką checklistą możesz podejść do niego znacznie pewniej. To inwestycja kilkudziesięciu minut (czasem godzin) przed releasem, która potrafi oszczędzić Ci nieprzespanych nocy spędzonych na gaszeniu pożarów.
Kluczem jest konsekwencja - stosuj tę listę przy każdym wydaniu, a z czasem wejdzie w nawyk całemu zespołowi i przestanie być "dodatkową robotą", a stanie się po prostu sposobem, w jaki wdrażacie.
Jeśli takie konkretne, praktyczne wskazówki to coś, czego szukasz, mam dla Ciebie propozycję.
Raz na jakiś czas wysyłam zamkniętemu gronu programistów .NET maile z rzeczami, których nie publikuję na blogu: sprawdzonymi wzorcami, checklistami jak ta powyżej, wnioskami z realnych wdrożeń i błędami, na których sam się kiedyś przejechałem - po to, żebyś Ty nie musiał. Bez spamu i lania wody, tylko wiedza, która realnie pomaga pisać lepszy kod i spać spokojniej po release.
Jeśli chcesz do nich dołączyć, wpadnij tutaj: modestprogrammer.pl/vip
To najprostszy sposób, żeby zostać w kontakcie i regularnie podkręcać swoje umiejętności w .NET. Do zobaczenia na liście - i powodzenia przy kolejnym wdrożeniu.
