Z tego poradnika dowiesz się, jak obsługiwać nasze firmowe narzędzie CI/CD (Jenkins) i jak stworzyć Jenkinsowy job, który odpowiedzialny będzie za automatyczny deploy na środowisku produkcyjnym (lub innym, jeśli zachodzi taka potrzeba konfiguracji), jeśli tylko pojawią się nowe zmiany na branchu, np. master.
Aby zalogować się do firmowego Jenkinsa, należy skorzystać z tego adresu http://138.68.166.65:8080/ i użyć danych do logowania udostępnionych na naszym LastPassie.
Tak naprawdę konfiguracja procesu buildowania projektu i jego deployu na produkcję zależy od niego samego – w jakich technologiach został stworzony, jakie komponenty są wykorzystywania do buildowania, w czym napisane są testy i jak powinny być uruchamiane itd.
W tym tutorialu zaprezentuję, jak powinien wyglądać job na Jenkinsie odpowiedzialny za deploy projektu stworzonego na Alfredzie. Zasada powinna być prosta: jeżeli cokolwiek ląduje na branchu master, dzięki webhookowi ustawionemu w ustawieniach repozytorium powinien uruchomić się job na Jenkinsie, który powinien uruchomić testy (jeśli istnieją), połączyć się do serwera produkcyjnego, wykonać pull zmian z brancha master, uruchomić nowe migracje bazy danych (jeśli istnieją), wyczyścić cache konfiguracji i całego projektu. Jeśli projekt jest dodatkowo uruchomiony WAFie takim jak Cloudflare i w jego obrębie działa dodatkowy cache statycznych assetów, Jenkins powinien automatycznie usunąć ten cache, aby najnowsze zmiany były widoczne na stronie.
Krok 1: skonfiguruj połączenie do serwera produkcyjnego
- Przejdź do zakładki Konfiguracji systemu (http://138.68.166.65:8080/configure) i znajdź sekcję Publish over SSH. Na dole znajdziesz przycisk Dodaj.
- Nadaj nazwę projektu, adres IP serwera, nazwę użytkownika/hasło (preferencyjnie ustaw połączenie bezhasłowe, bazując na kluczu SSH – zerknij na konfiguracje innych połączeń) oraz domyślny katalog (sugeruję ustawiać na /var/www, gdyż da nam to większą swobodę w przypadku większej liczby jobów na Jenkinsie, które muszą się łączyć do tego samego serwera, ale czyniąc operacje w obrębie różnych katalogów – startując z /var/www możemy ustawić katalog w poszczególnym jobie i wtedy będzie korzystać z lokacji dla danego projektu, np. /var/www/some-domain.com).
- Po konfiguracji wszystkich niezbędnych ustawień, kliknij w Test configuration, aby przetestować połączenie.
- Jeśli wszystko jest w porządku, zastosuj i zapisz wszystkie zmiany i przejdź do głównego dashboardu Jenkinsa.
Krok 2: stwórz job
- Aby maksymalnie uprościć ten proces, postanowiłem, że stworzę ogólny template dla typowego joba 🙂 – w tym celu stwórz nowy job (projekt) – http://138.68.166.65:8080/view/all/newJob i nadaj najpierw nazwę projektu
- Ważne: nazwa projektu powinna zaczynać się od nazwy środowiska docelowego (drukowanymi literami), w którym mają uruchomić się procesy, np. PRODUCTION – Some project name, STAGING – Some project name itd.
- Po nadaniu nazwy, na dole znajdziesz sekcję Kopiuj z i wpisz nazwę: PRODUCTION – DEPLOY TEMPLATE – po jego wybraniu, kliknij OK i powinieneś przejść do nowego joba.
- Teraz Twoim zadaniem jest skonfigurowanie joba – zacznij od wpisania adresu URL repozytorium i ustawienia brancha, z którego mają być pobierane zmiany
- Przejdź do sekcji Budowanie. Jeżeli projekt ma napisane testy, uruchom je np. za pośrednictwem uruchomienia Shellowego skryptu.
- Najważniejszym etapem w sekcji Budowanie jest połączenie do serwera i ustawienie komend/operacji, jakie mają być na nim wykonane – domyślny template ma ustawione połączenie do serwera bigpic.dev – wybierz serwer, który ustawiłeś w kroku 1
- Ustaw zdalny folder z obrębu tego katalogu, jaki ustawiłeś w kroku 1 – czyli np. domain.com (dzięki czemu folderem będzie /var/www/domain.com)
- Sekwencja operacji wykonanych na serwerze jest stworzona w tym template’cie bazując na najważniejsznych operacjach, jakie zawsze uruchamiany podczas deployów – możesz zostawić je tak jak jest lub dostosować do projektu
- Jeżeli projekt jest uruchomiony na Cloudflare, musimy inwalidować cache statycznych assetów – w tym template’cie znajdziesz shellowy skrypt, który jest odpowiedzialny za tę operację. Jednak, żeby działał prawidłowo, musi być skonfigurowany – potrzebujesz Zone ID, login do Cloudflare oraz API key. Instrukcję, jak tego dokonać krok po kroku, znajdziesz tutaj: https://bitbucket.org/snippets/snowflakers/BeR9Xb/cloudflare-cache-purge-via-curl-to
Jeśli projekt nie korzysta z Cloudflare, po prostu usuń tę operację z Jenkinsowego Joba. - Jeśli konfiguracja sekwencji operacji w jobie została zakończona, zastosuj i zapisz ustawienia i następnie Uruchom.
- Na kanale #jenkins-builds na Slacku powinieneś widzieć status.
Krok 3: ustaw webhook w repozytorium projektu
Aby jenkinsowy job mógł zostać automatycznie wyzwalany, musimy skonfigurować webhook w ustawieniach repozytorum. W tym celu przejdź do Settings -> Webhooks, dodaj webhook i ustaw nazwę (np. Auto pull @ production) i adres URL: http://138.68.166.65:8080/bitbucket-hook/. Dzięki temu, Bitbucket będzie wysyłał request do Jenkinsa i bazując na adresie URL repozytorium, z którego Bitbucket wysyła żądanie, dopasowuje adres URL repozytorium ustawiony w danym jobie i uruchomi go, jeśli zmiany zaszły na tym branchu, który również został ustawiony w tym jobie.
Od teraz jakakolwiek zmiana na tym branchu spowoduje automatyczne deploy.