Procedura deploymentu i lista kontrolna
Połączysz przygotowanie, backup, aktualizację, restart i weryfikację w jedną powtarzalną procedurę ręcznego deploymentu aplikacji.
1. Krótka teoria
Procedura deploymentu zmienia zbiór pojedynczych poleceń w powtarzalny proces z punktami kontroli. Przed wdrożeniem należy przejrzeć zakres zmian, potwierdzić branch i czyste working tree, uruchomić lokalnie ruff check . oraz pytest, a następnie doprowadzić zatwierdzoną wersję do main zgodnie z workflow zespołu. Trzeba znać wymagane zmiany konfiguracji, zależności i bazy oraz przygotować kryteria sukcesu i plan rollbacku. Na serwerze najpierw zapisuje się git rev-parse HEAD, tworzy sprawdzony backup danych i konfiguracji, a dopiero potem pobiera kod przez git pull --ff-only origin main. Zależności aktualizuje się tylko, gdy zmienił się odpowiedni plik lub wymaga tego wydanie. Po restarcie kontrola przebiega od najbliższej warstwy: status i journal usługi, bezpośredni endpoint Uvicorna na 127.0.0.1:8000, test i stan Nginxa, a następnie publiczna domena i HTTPS. Smoke test powinien sprawdzić nie tylko kod 200 strony głównej, lecz także najważniejsze funkcje właściwe dla aplikacji, bez modyfikowania produkcyjnych danych w niekontrolowany sposób. Wynik wdrożenia, commit, czas, operator, backup i anomalie należy zapisać. Jeśli kryteria sukcesu nie są spełnione, nie improwizuje się: zatrzymuje dalsze zmiany, zbiera logi i wykonuje przygotowany rollback kodu lub danych zależnie od diagnozy. Checklista powinna mieć trzy fazy. Przed: zakres, review, testy, branch, konfiguracja, backup i plan powrotu. W trakcie: zapis commita, pull --ff-only, zależności, restart i obserwacja logów. Po: Uvicorn, Nginx, domena, HTTPS, funkcje, monitoring i dokumentacja. Ręczny deployment daje operatorowi kontrolę, ale zależy od konsekwencji i jest podatny na pominięcia. CI/CD automatyzuje powtarzalne kroki i bramki jakości; zostanie rozwinięte w module DevOps, po zrozumieniu procesu ręcznego.
2. Przykłady komend
ruff check . && pytest
Uruchamia lokalny lint i testy przed dopuszczeniem zmiany do wdrożenia.
$ ruff check .
$ pytest
git status --short && git rev-parse HEAD
Potwierdza czyste repozytorium i zapisuje wersję wyjściową.
$ git status --short
$ git rev-parse HEAD
git pull --ff-only origin main
Pobiera zatwierdzoną wersję main bez tworzenia merge commita na serwerze.
$ git pull --ff-only origin main
sudo systemctl restart example-app && sudo systemctl status example-app --no-pager -l
Uruchamia nową wersję procesu i sprawdza stan jednostki.
$ sudo systemctl restart example-app
$ sudo systemctl status example-app --no-pager -l
journalctl -u example-app -n 100 --no-pager
Kontroluje logi nowego uruchomienia pod kątem błędów.
$ journalctl -u example-app -n 100 --no-pager
curl -sS -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8000/
Sprawdza bezpośrednio lokalny endpoint Uvicorna.
$ curl -sS -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8000/
200
curl -sS -o /dev/null -w "%{http_code}\n" https://app.example.com/
Sprawdza publiczną ścieżkę przez DNS, TLS i Nginx.
$ curl -sS -o /dev/null -w "%{http_code}\n" https://app.example.com/
2003. Zadanie praktyczne
example-app.service z trzema checklistami. Przed: zakres i review zmian, branch main, czyste working tree, ruff, pytest, zmiany konfiguracji, plan backupu i rollbacku. W trakcie: zapis commita, backup SQLite i .env, pull --ff-only, opcjonalna aktualizacja zależności, restart, status i logi. Po: lokalny curl do 127.0.0.1:8000, test Nginxa, publiczny HTTPS, kluczowe funkcje i dokumentacja wyniku. Dla każdego punktu dodaj oczekiwany wynik oraz decyzję STOP przy błędzie.
4. Typowe błędy
- Wdrażanie zmian, które nie przeszły lokalnych testów i lintowania.
- Pobieranie kodu przed zapisaniem commita i wykonaniem backupu.
- Aktualizowanie zależności bez użycia venv lub bez potrzeby.
- Uznanie aktywnego statusu systemd za pełne potwierdzenie działania.
- Pomijanie bezpośredniego testu Uvicorna albo publicznego testu HTTPS.
- Brak przygotowanego kryterium rollbacku i sprawdzonej kopii danych.
- Niedokumentowanie wersji, czasu, wyników oraz problemów wdrożenia.
5. Podsumowanie
Kompletna procedura obejmuje przygotowanie i lokalne testy, zapis stanu serwera, backup, bezpieczne pobranie kodu, zależności, restart i weryfikację każdej warstwy. Checklista przed, w trakcie i po wdrożeniu ogranicza pominięcia, a plan rollbacku wyznacza reakcję na błąd. Ręczny proces stanowi podstawę do późniejszej automatyzacji CI/CD w module DevOps.