Wdrażanie za pomocą Zinnector®: połącz, sprawdź, wypchnij

Gdy projekt działa lokalnie, cztery polecenia przenoszą go na działającą stronę w hostingu Zinn Digital®: zaloguj się, powiąż projekt z gniazdem hostingu, odczytaj kontrolę przedstartową i wyślij. W tym artykule omówiono każde z nich, wypisywane przez nie komunikaty oraz polecenia, z których korzysta się później — ponowne wdrożenia, historię wdrożeń i logi budowania.

Zaloguj się za pomocą klucza API

Utwórz klucz w panelu sterowania w sekcji Ustawienia → Klucze API, a następnie:

zinnector login

Klucz wpisuje się po wyświetleniu monitu — nigdy nie jest akceptowany w wierszu poleceń, dzięki czemu nie trafia do historii powłoki ani listy procesów. W środowisku CI przekaż go potokiem: echo "$ZINN_API_KEY" | zinnector login --profile ci lub ustaw ZINNECTOR_TOKEN i całkowicie pomiń login. Klucz jest weryfikowany przed zapisaniem i zapisywany z uprawnieniami pliku 600. zinnector whoami --scopes pokazuje, do której organizacji jesteś zalogowany i jakie uprawnienia posiada klucz; klucz piaskownicy jest odpowiednio oznaczony.

Powiąż projekt z gniazdem

zinnector link                                   # wybierz stronę z listy
zinnector link example.com --repo acme/site --branch main

Polecenie link zapisuje identyfikator strony w pliku zinnector.json i, o ile nie przekazano parametru --no-repo, łączy zdalne repozytorium git projektu ze stroną na platformie, dzięki czemu wysłanie zmian powoduje wdrożenie. Zatwierdź plik zinnector.json w repozytorium: współpracownik, który klonuje repozytorium, wdraża zmiany w to samo miejsce bez konieczności udzielania mu dodatkowych instrukcji. Plik ten nie zawiera żadnych poufnych danych.

Odczytaj kontrolę przedstartową

zinnector check

To jest polecenie, dla którego istnieje interfejs CLI. Porównuje ono projekt z gniazdem, do którego ma zostać wdrożony, i wypisuje każdą niezgodność oraz każde porównanie, którego nie udało się wykonać:

• Wersja PHP, przy czym różnica w wersji głównej jest oceniana jako wysoka, ponieważ niezawodnie powoduje awarię strony, a mniejsza różnica jest oceniana niżej, ponieważ traktowanie wszystkiego jako krytyczne uczy ludzi pomijania ostrzeżeń.
• Informacja, czy gniazdo może przełączyć się na wersję, na której zbudowano projekt, czy wersja PHP w gnieździe jest przestarzała (po zakończeniu wsparcia) oraz czy maszyna zastosowała tę wersję, czy tylko otrzymała takie polecenie.
• Rozmiar i liczba plików Twojego projektu w odniesieniu do faktycznie pozostającej do dyspozycji przestrzeni dyskowej i limitu węzłów (inode) w gnieździe — drzewo katalogów WordPress może wyczerpać liczbę plików, mimo że zajętość dysku jest znacznie poniżej limitu.
• Wersje WordPress po obu stronach, informacja, czy gniazdo zakończyło udostępnianie, oraz czy połączono repozytorium, do którego można wysyłać zmiany.

Narzędzie ostrzega, ale nigdy nie blokuje. Każde znalezisko można pominąć za pomocą polecenia zinnector push --force, ponieważ wiesz o swojej stronie rzeczy, których program sprawdzający nie zna. Porównanie, którego nie można było wykonać, jest zgłaszane jako nieznane, nigdy jako pomyślne, a podsumowanie zawsze zawiera informację, ile takich przypadków wystąpiło. Domyślnie lokalna wersja PHP to wersja zadeklarowana w pliku zinnector.json; flaga --probe uruchamia lokalne środowisko wykonawcze i mierzy je. Flaga --strict powoduje zakończenie z kodem różnym od zera również w przypadku wartości nieznanych, czego wymaga brama CI.

Wyślij

zinnector push

Polecenie push uruchamia kontrolę przedstartową, wysyła zatwierdzenia, inicjuje wdrożenie i monitoruje je aż do zakończenia, wypisując ostateczny status oraz wdrożone zatwierdzenie. Flaga --dry-run wykonuje wszystko oprócz wdrożenia; --no-wait inicjuje wdrożenie i kończy działanie; --no-git wdraża to, co platforma już posiada, bez wysyłania zmian. Jeśli wdrożone zatwierdzenie nie jest tym, które właśnie wysłano, pojawia się odpowiedni komunikat.

Co zrobić, gdy coś pójdzie nie tak

zinnector deploys example.com        # historia wdrożeń — status, zatwierdzenie, wyzwalacz, komunikat
zinnector logs example.com --build   # log budowania ostatniego wdrożenia
zinnector logs example.com --error   # log błędów strony
zinnector deploy example.com         # ponowne wdrożenie tego, co platforma już posiada
zinnector ai "why is my deploy failing?"

Polecenie zinnector ai działa na platformie w ramach Twojego konta, dzięki czemu ma dostęp do tej samej historii wdrożeń i logów. Z wnętrza projektu przesyła on strukturę projektu — nazwy katalogów, wersje oraz identyfikator strony — i nigdy zawartości plików.

Powiązane

• Pierwsze kroki · Rozwój lokalny · Dokumentacja poleceń · Rozwiązywanie problemów