Informacje o stagingu
Staging w naszej firmie jest dostępny pod adresami domeny bigpic.dev. Każdy projekt ma swoje odzwierciedlenie na stagingu, np.: http://swiftpak-cms.bigpic.dev, https://ans-global.bigpic.dev, https://unicorn.bigpic.dev itd.
Staging jest uruchomiony na DigitalOcean, wraz z panelem administratora całego serwera o nazwie Runcloud.
Domena bigpic.dev jest zintegrowana z Cloudflare.
Standardowy projekt, oparty o nasz firmowy Alfred CMS, posiada przynajmniej 2 instancje:
- instancja front-endowa (serwująca tylko pliki front-endowe), np. https://haiken.bigpic.dev
- instancja back-endowa (serwująca finalną stronę/web aplikację z podpiętym CMSem), np. https://haiken-cms.bigpic.dev
Aby połączyć się do stagingu w celu np. przełączenia brancha albo uruchomienia migracji, należy połączyć się przez panel Runcloud (dane w firmowym managerze haseł jako RunCloud – Staging Server Control Panel). Możesz też połączyć się do serwera przez SSH – musisz najpierw poprosić Team Leadera o dostęp, przekazując mu Twój klucz SSH.
Jak zmienić branch w projekcie na stagingu?
Często się zdarza, że podczas developmentu projektu, powstaje kilka funkcjonalności w tym samym czasie przez różnych developerów i na pewnym etapie należy daną funkcjonalność uwidocznić na stagingu w celu przekazania projektu do testów.
Poniższe kroki dotyczą zmiany brancha na stagingu.
- Połącz się do panelu Runcloud. Dane do logowania znajdziesz w firmowym managerze haseł (wyszukaj RunCloud – Staging Server Control Panel)
- Wybierz serwer (jest tylko jeden :-))
- Przejdź do zakładki Web Application, wybierz projekt o odpowiedniej nazwie
- Wejdź w zakładkę Git i zmień nazwę brancha
Oczywiście możesz też połączyć się do serwera przez SSH. Preferowanym sposobem przełączania brancha na stagingu jest dokonanie tej operacji przez panel RunCloud.
Dostęp do stagingu przez SSH
Szczegóły, jak się połaczyć do serwera, znajdziesz w notatce w naszym firmowym managerze haseł o nazwie BP Staging non-root user. Wszystkie projekty znajdują się w obrębie katalogu /home/runcloud/webapps. Po prostu wejdź w odpowiedni katalog i działaj, co potrzebujesz. Tylko ostrożnie 🙂
Jak stworzyć instancję projektu na stagingu?
Praktycznie każdy projekt w naszej agencji posiada dwie instancje: front-endową i back-endową (finalną, z zintegrowanym CMSem itd.). Jeżeli stoisz przed zadaniem stworzenia jednej (lub obu) z nich, poniższe instrukcje mogą okazać się pomocne. Front-endowa instancja to taka, która serwuje tylko pliki front-endowe z obrębu odpowiedniego folderu (o tym poniżej), a wersja back-endowa to taka, która wskazuje na folder, w którym znajduje się backend, połączony z frontendem.
Od czego zacząć?
Połącz się do panelu Runcloud. Dane do logowania znajdziesz na LastPassie (wyszukaj RunCloud – Staging Server Control Panel).
Zacznij od stworzenia sub-domeny *.bigpic.dev
W panelu Runcloud, znajdź zakładkę DNS Manager i przejdź do niej. Wybierz klucz, a następnie kliknij na dostępną domenę bigpic.dev.
W sekcji Add DNS Record ustaw Hostname odpowiadający sub-domenie, jaką chcesz utworzyć (np. haiken.bigpic.dev; haiken-cms.bigpic.dev; project-name-cms.bigpic.dev itp.). Jeżeli nazwa projektu to np. Coca Cola, nazwa projektu na stagingu powinna być coca-cola w przypadku instancji front-endowej. Jeżeli tworzysz instancję back-endową, dodaj -cms sufix do tej nazwy, czyli np. coca-cola-cms. Używaj tylko małych liter i myślników, jeśli są potrzebne. W polu Content wybierz dostępny serwer a w ustawieniu Proxy Status wybierz Proxied (dzięki czemu strona będzie proxy’owana przez Cloudflare – jest to super ważne!).
Dodaj rekord i gotowe. Teraz możesz utworzyć aplikację i połączyć ją z właśnie stworzoną domeną (sub-domeną).
Stwórz aplikację
- Przejdź do widoku Servers i następnie wybierz dostępny serwer.
- Przejdź do zakładki Web Application i kliknij Deploy New Web App.
- Wybierz Git Repository, Bitbucket.
- Nadaj instancji odpowiednią nazwę, odpowiadającą nazwie projektu. Jeżeli nazwa projektu to np. Coca Cola, nazwa projektu na stagingu powinna być coca-cola w przypadku instancji front-endowej. Jeżeli tworzysz instancję back-endową, dodaj -cms sufix do tej nazwy, czyli np. coca-cola-cms. Używaj tylko małych liter i myślników, jeśli są potrzebne.
- Domain name – wybierz Use my own domain / subdomain i ustaw ją tak samo, jak nazwa projektu np. coca-cola.bigpic.dev, coca-cola-cms.bigpic.dev itp. W ustawieniu DNS Integration – wybierz Cloudflare, następnie dostępny Cloudflare API key i zaznacz checkbox na dole.
- W sekcji Git podaj nazwę repozytorium (np. snowflakers/<nazwa repo>) i branch, z którego aplikacja powinna zostać utworzona.
- Wszystkie pozostałe ustawienia pozostaw takie, jakie są, za wyjątkiem Public Path, które powinno wskazywać na odpowiedni folder, np. /home/runcloud/webapps/coca-cola/frontend/dist w przypadku standardowego front-endowego projektu (opartego na naszym standardowym boilerplate’cie) lub /home/runcloud/webapps/coca-cola-cms/cms-backend/public dla instancji zorientowanej na backend, opartego o nasz Alfred CMS.
- Wersja PHP zależy od projektu. Jeśli tworzysz instancję front-endową – wybierz po prostu maksymalnie najnowszą wersję (nie ma to de facto znaczenia), natomiast w instancji backendowych wybierz wersję odpowiadającą projektowi.
- Web Application Stack – wybierz po prostu Native NGINX (bez customowej konfiguracji).
- To tyle. Zatwierdź i powinno działać.
- Jeżeli instancja, którą tworzysz wymaga bazy danych – znajdź zakładkę Database, stwórz użytkownika, bazę i cokolwiek, co potrzebujesz.
Runcloud jako panel administracyjny posiada wiele innych, ciekawych rozwiązań – zachęcam do zapoznania się z nimi. Niektóre z nich bardzo ułatwiają życie.
Ważne: Webhooks
Na stagingowych projektach, w większości przypadków, nie posiadamy żadnej automatyzacji względem wdrażania zmian poprzez narzędzia CI/CD. Zazwyczaj korzystamy z prostego pobierania zmian z repo, za pośrednictwem webhooków.
Pamiętaj, aby zarówno w przypadku front-endowej jak i back-endowej instancji takowy webhook zawsze założyć. Wystarczy z poziomu Runcloud’a, z odpowiedniego projektu, w zakładce Git znaleźć Webhook URL i wdrożyć go w ustawienia repozytorium, gdzie znajduje się konfiguracja webhooków. Dzięki temu, każde pushowanie zmian na dany branch, który aktualnie jest przełączony na stagingowej instancji, spowoduje automatycznie pobranie zmian na stagingowym serwerze.
Oczywiście w przypadku projektów backendowych, gdzie niejednokrotnie podczas wdrażania jakiejś funkcjonalności na staging potrzebne jest np. uruchomienie migracji, zaleca się połączenie do serwera poprzez SSH i manualne uruchomienie odpowiednich komend w obrębie danego projektu.
Jeżeli jakiś projekt wymaga wprowadzenia automatyzacji względem wdrażania zmian (np. w formie job’a na Jenkinsie) – nie ma najmniejszego problemu, jest to osiągalne do wykonania – zaloguj się do Jenkinsa i stwórz job’a.