Dlaczego warto mieć kilka środowisk dla jednej strony WordPress?
Jeśli myślisz, że jedna instalacja WordPressa na produkcji wystarczy – ten wpis może Cię zaskoczyć. W świecie profesjonalnego web developmentu korzystanie z kilku środowisk (lokalne, staging, preprodukcja) to nie fanaberia, a konieczność. Dzięki nim możesz testować zmiany, aktualizacje i nowe funkcje bez ryzyka awarii „żywej” strony.
Zapraszam do wysłuchania kolejnego odcinka podcastu. Tam opowiadam, jak działają te środowiska, czym się różnią i jak wprowadzić je do swojego procesu pracy – nawet jeśli dopiero zaczynasz przygodę z WordPressem. Dowiesz się także, jak automatyzować deploye i dlaczego staging może uratować Twój projekt.
Gotowy na bezpieczniejszy i bardziej profesjonalny workflow? Do usłyszenia.
🎁 Partner odcinka: CyberFolks
Z kodem podcast otrzymasz 20% zniżki na hosting WordPress.
Podcast dostępny m.in w: Spotify, Apple Podcasts, Google Podcasts
TRANSKRYPCJA AUTOMATYCZNA:
Cześć, witam Cię w kolejnym odcinku mojego podcastu. Dzisiaj zajmiemy się tematem różnych środowisk dla tej samej strony internetowej. Teraz chwila dla mojego partnera, czyli marki CyberFolks, która dostarcza domeny i hosting pod Twojego WordPressa. Jeśli potrzebujesz takiego hostingu, to z kodem podcast masz 20 % rabatu na zakup hostingu WordPress.
Przejdźmy teraz do tematu środowisk. Po co w ogóle nam kilka środowisk dla jednej strony na WordPressie? Po co sobie komplikować życie jak możemy sobie po prostu zainstalować tego WordPressa na hostingu, podpiąć jakąś domenę i tam wszystko
No fakt faktem możemy tak zrobić i bardzo często tak robimy. Każdy kiedyś tak zrobił i miał tylko tą jedną wersję tej strony. O tym czy dla każdej strony powinniśmy mieć takie różne środowiska to jeszcze potem powiem parę słów.
Natomiast teraz skupmy się na tym co to są w ogóle te różne środowiska dla WordPressa.
No dobrze, zacznijmy więc może od tego, po co w ogóle rozróżniać te środowiska, po co stawiać sobie kilka kopii jednej strony internetowej. No bo przecież na naszą stronę internetową ludzie, którzy wchodzą, wchodzą na jeden konkretny adres, Załóżmy, w moim przypadku jest to maciejkuchnik.pl i jest to po prostu strona zainstalowana pod tą domeną. No po co ja mam stawiać jakieś dodatkowe środowiska, dodatkowe kopie tej strony?
I tutaj wszystko będzie zależało tak naprawdę od tego w jaki sposób pracujemy przy tej stronie. Bo sytuacja będzie trochę inna jeśli to jest strona zbudowana na jakimś gotowym motywie z kilkoma pluginami, z repozytorium czy ewentualnie płatnymi. Natomiast nie ma tam zbyt dużo jakichś customowych rzeczy. Wszystko jest stworzone na bazie gotowych rozwiązań.
A zupełnie inaczej sytuacja będzie wyglądała jeśli np. mamy jakiś skomplikowany system zaprogramowany na bazie WordPressa np. w formie wtyczki czy np. mamy customowy motyw, który jest rozwijany na przestrzeni czasu i pracy tej strony. I tutaj te potrzeby mogą być bardzo różne. Przejdziemy sobie przez takie typowe środowiska, którymi możecie się spotkać podczas pracy z WordPressem w taki trochę bardziej profesjonalny sposób.
I też ten dzisiejszy odcinek głównie jest kierowany do osób raczej mniej zaawansowanych, ale też np. do klientów, którzy przechodzą do developera, a developer im mówi, że no to ja muszę sobie postawić jeszcze jakieś dodatkowe środowiska, byśmy mogli pracować. No i tutaj w głowie klienta może się zapalić taka czerwona lampka, ale po co on chce stawiać w ogóle jakieś dodatkowe kopie, przecież jest strona, jest hosting, tam to wszystko działa, więc po co kombinować.
I tak naprawdę głównym takim powodem tego, że stawiamy sobie różne środowiska dla naszej strony, która działa pod jakąś określoną domeną jest to, żeby ta strona właśnie tam bezproblemowo działała przez 100 % czasu.
Bo tak naprawdę gdy wprowadzamy jakieś zmiany, czy to zmiany dotyczące choćby aktualizacji wtyczek, Wordpresa, czy motywów no to potencjalnie narażamy się na jakieś problemy, które…
Nie do końca możemy przewidzieć na etapie, gdy klikamy przycisk. I w momencie, którym wysypie nam się cała strona internetowa, to może być duży problem, bo mamy wtedy dosyć ograniczony czas i zależy nam na tym, aby jak najszybciej to przywrócić do życia, żeby nasza strona zaczęła działać prawidłowo. Jeśli to jest jeszcze jakaś tam strona, taka wizytówka, to jest to mniejszy problem, ale już w przypadku…
na przykład sklepu internetowego czy jakiejś strony, na którą wchodzi bardzo dużo osób i jest ona w jakiś sposób krytyczna dla funkcjonowania całego to tu już sytuacja wygląda zupełnie inaczej, bo to może generować po prostu realne straty. i zaczniemy może troszkę od końca, czyli od tzw. produkcji, środowiska
Jest to tak naprawdę najważniejsze środowisko dla naszej strony i w zasadzie możemy powiedzieć, że wszyscy mają produkcję, no bo te strony są dostępne, ludzie na nie wchodzą i z nich korzystają. Jest to po prostu ta strona, która jest zainstalowana pod główną domeną, z której korzystają internauci, twoi klienci, czy ludzie, którzy wchodzą na tą stronę.
Ważne, żeby ta strona działała przez 100 % czasu, żeby przerwy były zaplanowane albo wręcz żeby się nie wydarzały. No i oczywiście to jest wszystko co potrzebujemy aby strona funkcjonowała, tylko tak jak powiedziałem wcześniej w przypadku jakiegoś problemu, no tuż sytuacja się trochę komplikuje, bo ta nasza strona przestaje działać. Więc jakie jeszcze inne środowiska możemy sobie postawić? Żeby się zabezpieczyć przed jakimiś konsekwencjami właśnie naszych działań.
Jednym z takich środowisk, szczególnie lubianym przez programistów, którzy muszą rozwijać takie strony jest oczywiście środowisko. I tutaj to środowisko może być postawione w oparciu o różne narzędzia. Jednym z takich bardzo popularnych i bardzo prostych w użyciu jest narzędzie lokal.
Jest to po prostu taki, można powiedzieć, cały pakiet, gdzie instalujemy to narzędzie na swoim… komputerze i uruchamiamy tam sobie tego wordpressa dosłownie za pomocą trzech kliknięć nie musimy się martwić o serwer bazy danych, jakieś tam dodatkowe lokala, instalujemy sobie wordpressa czy na przykład przenosimy sobie to ze środowiska produkcyjnego na nasz lokalny komputer i uruchamiamy za pomocą tego lokala no i mamy w tym momencie taką stronę dostępną na naszym komputerze możemy sobie tam ją rozwijać, programować i tak dalej i tutaj jest to dosyć wygodne rozwiązanie. Oczywiście jesteśmy w 100 % odseparowani od wersji produkcyjnej, więc nawet jeśli coś zepsujemy, pojawią się jakieś błędy w kodzie, no to nie ma to zupełnie wpływu na to co się dzieje na stronie, z której korzystają użytkownicy, klienci itd. Natomiast mogą się tutaj pojawić też takie
Jak np. różnice w konfiguracji, choćby w wersjach PHP. Załóżmy na serwerze produkcyjnym możemy mieć wersję PHP 8.3, a u nas lokalnie możemy mieć wersję np. 8.1 czy 8.2. Przez co pewne rzeczy mogą się tak naprawdę wysypać po przeniesieniu na produkcję, więc zawsze warto zadbać o to, aby te środowiska były maksymalnie zbliżone do tego co mamy na środowisku produkcyjnym.
Tutaj też mamy pewne ograniczenia choćby tym żeby inni mogli mieć dostęp do tej strony czyli jeśli chcemy pokazać klientowi taką stronę która jest na naszym komputerze no to albo musimy już kombinować z jakimiś tunelami i funkcjami choćby dostępnymi w lokalu za pomocą których możemy wystawić tą naszą stronę na świat ale to oczywiście też się wiąże z tym że jeśli wysyłamy komuś link do takiej strony, ten nasz komputer musi być cały czas podłączony do internetu, włączony i ta funkcja musi po prostu działać. Więc jeśli chcemy komuś na szybko pokazać koledze z teamu żeby zajrzał i zobaczył jak to wygląda, no to ok, ale już do jakichś większych operacji może być to bardzo problematyczne.
Kolejnym takim środowiskiem jest tak zwany staging, czyli to już jest taka kopia środowiska produkcyjnego postawiona gdzieś na serwerze, którego mają dostęp wszyscy na deweloperzy pracujący, czy ma na przykład klient, testerzy i tak dalej, czyli to już jest taka można powiedzieć pełnoprawna strona dostępna normalnie z internetu, już nie musimy robić żadnych fikołków, żeby ktoś mógł na nią i takie strony bardzo często są wykorzystywane.
Jeśli programiści pracują w zespole nad daną stroną, robią jakieś zmiany w kodzie, wrzucają po kolei zmiany do repozytorium, to ten staging jest środowiskiem, które zbiera to wszystko i pozwala przetestować to, jak to funkcjonuje razem. Bądź na przykład tester może tam wejść, przetestować jakieś zmiany, które były…
Możemy również pokazać na tym środowisku coś klientowi, czy wręcz dać mu dostęp do panelu, powiedzieć, tu masz kliencie taką swoją piaskownicę, możesz się bawić do woli, możesz zmieniać, testować, usuwać, robić jakieś takie rzeczy, które na środowisku produkcyjnym byłyby niemożliwe, bo wiązałyby się z tym, że strona będzie inaczej wyglądała albo będzie inaczej działała.
To właśnie środowisko zapewnia nam taką przestrzeń na takie testy, na różne operacje, które nie są możliwe na środowisku produkcyjnym z tych względów, które wymieniłem właśnie przez chwilę. Tutaj częstymi problemami, którymi się spotykamy w takiej codziennej pracy jest choćby to, że te wersje mogą się różnić dosyć znacznie od środowiska produkcyjnego choćby pod kątem zawartości. Mówię tu już o samej treści, która jest zgromadzona w CMS-ie, bo o ile mamy dokładnie ten sam kod, ten sam zestaw wtyczek na przykład, to już możemy mieć inną konfigurację tego WordPressa czy np. WooCommercea.
Możemy mieć różną bazę produktów. Co za tym idzie, warto pamiętać o tym, żeby jak najbardziej zbliżyć środowisko. Na jakiś czas wykonać import danych z serwisu produkcyjnego na ten staging. Znowu dochodzi nam dużo innych problemów, choćby kwestie danych czy danych osobowych, które są przechowywane w środowisku produkcyjnym, a niekoniecznie powinniśmy je kopiować gdzieś tam na jakieś inne środowiska, których dostęp mają różni ludzie.
A taki podział na trzy środowiska czyli lokalne środowisko, staging i produkcję to już jest całkiem fajna konfiguracja bo tak naprawdę możemy spokojnie pracować samodzielnie czy to w jedną osobę czy cały zespół deweloperski. Każdy deweloper może mieć swoje środowisko, może na nim pracować. Potem te wszystkie zmiany łączymy ze sobą i one są dostępne do przejrzenia na środowisku stagingowym.
Przed przeniesieniem tego na produkcję możemy sobie to spokojnie przetestować czy właśnie samodzielnie, możemy to pokazać klientowi, czy ewentualnie tester może tam przejść, wykonać swoje testy i dać nam feedback czy jest wszystko ok, czy może znalazł jakieś i taki flow pracy to już jest naprawdę bardzo dużo i bardzo fajnie się pracuje już w takim, takich bardzo skomplikowanych wdrożeniach, bardzo skomplikowanych projektach. Czasem jeszcze korzystamy z czegoś takiego jak środowisko UAD. Tutaj to nazewnictwo jest dosyć płynne i dosyć mocno umowne. Nie ma tu jakichś sztywnych granic. Co nazwiemy stagingiem, preprodem itd. jest używany często w takim kontekście gdzie mamy już naprawdę bardzo bardzo zbliżone to wszystko do środowiska produkcyjnego. I mam tu na myśli sytuację w której na na stagingu mamy kod 1 do 1 z tym co wrzucamy potem na preprod na te kolejne środowiska w trakcie rozwoju tego oprogramowania ale może się to różnić na przykład infrastrukturą załóżmy że na stagingu u żywamy jakiegoś tam zwykłego hostingu na który wrzucamy te wszystkie zmiany i tam to jest wszystko dostępne ale już środowisko produkcyjne funkcjonuje w jakiejś takiej bardziej skomplikowanej infrastrukturze czy to w jakiejś chmurze czy na przykład są zastosowane jeszcze jakieś dodatkowe narzędzia, choćby takie jak Cloudflare, którym mówiłem w ostatnim odcinku. Więc tutaj ten prepro powinien maksymalnie odpowiadać temu, co zostaniemy na środowisku produkcyjnym nie tylko właśnie pod względem danych zawaltych w WordPressie, ustawień, integracji i tak dalej, ale też całej infrastruktury, której pracuje dana strona. Czyli jeśli mamy to hostowane gdzieś tam w chmurze na przykład, ruch jest spuszczany przez Cloudflara.
To te wszystkie aspekty powinny być odwzorowane na tym środowisku przedprodukcyjnym, na tym preprodzie żebyśmy mieli taką samą konfigurację załóżmy Cloudflera, samą konfigurację serwerów które to obsługują No i wreszcie taką samą konfigurację i zawartość WordPressa jaką mamy na produkcji. I tutaj ponownie jednym z takich częstych problemów jest to jak zachować spójność tych danych między serwisem produkcyjnym a takim preprodem szczególnie we wdrożeniach, które są dosyć duże, które mają bardzo duże bazy danych No bo to bywa dosyć problematyczne, bo tutaj też musimy zwrócić uwagę na taki aspekt, że cały serwis może się zupełnie inaczej zachowywać, jeśli na przykład na stagingu załóżmy 200-300 postów, ale w produkcyjnym serwisie mamy już np. 200 tysięcy takich postów. No to już będzie to diametralnie różne i tutaj warto też zwrócić uwagę właśnie na takie szczegóły, gdzie w założeniu ten preprod ma jak najwierniej oddawać to, co spotkamy na środowisku produkcyjnym.
Zarówno pod kątem infrastruktury, konfiguracji, zawartości i ilości danych, bo ta ilość danych też jest bardzo często kluczowa, choćby dla wydajności bazy danych sobie teraz jeszcze tak krótko jak może wyglądać Flow programisty, który pracuje nad rozwojem jakiejś strony. Oczywiście ten programista ma to środowisko lokalne, uruchomione na swoim komputerze. Tam sobie może do woli klikać, testować itd. Może mieć tam dodatkowe narzędzia do debugowania.
W wykonaniu jakiejś części pracy te zmiany są przenoszone na staging. Tam testowane jest to ze zmianami od innych deweloperów. Do tego już mają dostęp na przykład testerzy czy klient. I następnie po pozytywnych testach na środowisku stagingowym możemy mieć jeszcze takie środowisko przedprodukcyjne. Tam ponownie testujemy. Również mogą być tutaj wpięte jakieś automatyczne testy. I na samym końcu, gdy już mamy to przetestowane na dziesiątą stronę, to możemy ze spokojem puścić takie zmiany na produkcję i mamy wtedy pewność bądź prawie pewność, że nic nam się nie wysypie po drodze i wtedy bezpiecznie możemy wprowadzić update już na środowisko produkcyjne. Nigdy nie miałeś do czynienia właśnie z kilkoma środowiskam dla jednej strony, to po wysłuchaniu tego podcastu, odcinka do tego momentu możesz myśleć, kurczę, ale jak zaplanować nad tym wszystkim? Przecież to są jakieś osobne WordPressy, ten kod się różni na tych wszystkich instancjach, nie wiadomo tak naprawdę co, gdzie jest.
A tutaj jeszcze mówisz o tym, że każdy w zespole ma swoje środowisko lokalne i na nim pracuje. No tak, i to oczywiście nie jest proste, żeby zapanować nad tym wszystkim, natomiast tutaj z pomocą przychodzi nam oczywiście wersjonowanie kodu i Git, a wraz z nim coś, co możemy nazwać automatycznymi deployami, czyli taki mechanizm w GitLabie, Bitbackecie, który odpowiada za to, żeby te wszystkie zmiany były wysyłane automatycznie na różne środowiska, które mamy skonfigurowane w danym. W praktyce wygląda to tak, że mamy kilka osobnych gałęzi w repozytorium, gdzie po prostu każda ta gałąź odpowiada za środowisko, które te zmiany są wrzucane. I załóżmy, że dla tego scenariusza, który opisywałem tutaj w tym odcinku, no to będziemy mieli na przykład gałąź staging, gałąź preprod i gałąź produkcyjną i po zmarżowaniu jakichś zmian…od dowolnego dewelopera w zasadzie do którejś gałęzi załóżmy że wrzucam jakieś zmiany do kodu i przez merge request to wszystko leci do jakiejś konkretnej gałęzi załóżmy np. do tej gałęzie staging i tam potem automat uruchamia automatyczny deploy na środowisko stagingowe więc tutaj tak naprawdę już automat robi wszystko za nas jeśli tylko te zmiany zostaną zaakceptowane, zmerżowane. No to wchodzą one po prostu na tą gałąź i potem automat już dba o to aby to wszystko zostało wrzucone na to środowisko stagingowe, to środowisko przedprodukcyjne czy ewentualnie już potem na samym końcu na produkcję. I dzięki temu, mamy te procesy CI-CD zautomatyzowane, no to tak naprawdę Git i cała otoczka wokół Gita, czyli na przykład GitLab czy Bitbucket i te wszystkie automaty, które tam pracują mogą tą robotę robić za nas w taki powtarzalny, zautomatyzowany sposób, co również eliminuje dużo błędów, które człowiek mógłby popełnić po drodze.
Dodatkowo w całym tym procesie CI-CD możemy jeszcze włączyć takie rzeczy jak choćby testy czy narzędzia do statycznej analizy kodu gdzie możemy pilnować pewnych standardów czyli jeśli deweloper na przykład nie zastosował się do jakiejś konwencji na zewnątrz czy czegoś takiego no to tutaj automatycznie repozytorium nie przepuści nam takiego commit’a, takiego match request’a i deweloper będzie musiał to poprawić. też jest świetny sposób na to, aby trzymać odpowiednie standardy, jeśli chodzi o sam kod i jego tworzenie.
I tak jak już tutaj wspomniałem to, że to wszystko jest zautomatyzowane, zaprogramowane w pewien sposób, eliminuje nam też takie proste głupie błędy, które mogą wynikać po prostu z tego, że dewelopor gdzieś kliknął, nie tam gdzie trzeba, gdzieś się pomylił, coś zrobił nie tak jak zawsze, tym bardziej że… To są bardzo powtarzalne procesy i one się wydarzają dosyć często. Bo wiadomo, że jeśli projekt jest gdzieś tam w fazie albo intensywnego rozwoju albo takiego utrzymania, które wiąże się z rozwojem, to te zmiany zachodzą dosyć często. A dzięki tym wszystkim mechanizmom możemy sobie to automatyzować.
Podobnie jest jeśli chodzi o dbanie o to aby te środowiska były możliwie spójne. Tutaj akurat ja posiłkuję się jakimiś skryptami opartymi o skrypty bashowe plus wykorzystywanie WPCLI. Dzięki czemu mogę sobie zaimportować bazę z produkcji, usunąć niepotrzebne dane. Czy tam pozmieniać jakieś dane konfiguracyjne, choćby takie dotyczące systemu płatności, czy jakiegoś systemu do fakturowania, bo to są też takie rzeczy, gdzie na przykład na stagingu, czy na tym środowisku preprod mamy podpięty załóżmy testowy system płatności, czy jakąś testową integrację z systemem fakturowym, kurierskim i tak dalej.
No bo też warto dbać o to, aby nie mieszać tych środowisk również w zakresie tych integracji. No bo jeśli mamy np. integrację z systemem do fakturowania, testujemy sobie takie zamówienie, no to raczej nie chcemy, aby takie testowe zamówienia trafiło do produkcyjnego systemu fakturowego i żeby wystawiła się tam faktura, która zostanie potem zaklęgowana w danej firmie, no bo będzie to zupełnie niezgodne z rzeczywistością. Więc o takich rzeczach musimy pamiętać.
Również o wszelkich automatycznych procesach, które zachodzą na naszych stronach. Mam tu na myśli takie rzeczy jak wysyłka jakichś powiadomień mailowych, bo jeśli skopiujemy sobie bazę danych z środowiska produkcyjnego i postawimy ją w środowisku stagingowym i mamy np. serwis, który wysyła jakieś maile z przypomnieniami. Ja akurat mam takie wdrożenie, którym się opiekuje, gdzie dzieje się bardzo dużo automatycznych rzeczy takich jak powiadomienia, interakcje z systemami zewnętrznymi no to w momencie w którym mam drugie, trzecie środowisko z tą samą bazą danych no to użytkownicy mogliby dostawać właśnie te powiadomienia razy dwa, razy trzy i tutaj warto zadbać o to żeby nie trzymać tych danych jeśli nie potrzebujemy ich koniecznie czyli na przykład po imporcie takiej bazy danych z produkcji wyczyścić konta klientów bądź je zanonimizować. Ewentualnie zastosować mechanizmy, które pozwolą na przekierowanie adresów e-mail na jakiś jeden konkretny. Ja akurat stosuję taką strategię, adres klienta jest z innej puli niż taka wide lista adresów mailowych, które używamy do testowania tego, to jeśli to jest środowisko inne niż produkcyjno, taki mail nie jest po prostu wysyłany i jest to zrobione bardzo prostą metodą za pomocą hooka WordPressowego, który po prostu ubija taką wysyłkę maila. Więc tutaj warto też się zabezpieczyć przed wszystkimi takimi dodatkowymi nieprzewidzianymi konsekwencjami. Warto pomyśleć właśnie jakie mamy integrację, na co ten nasz system, ta nasza strona wpływa. I odpowiednio to wszystko przygotować i znowu bardzo prosto można to za pomocą WPCL i zabrać do jednego skryptu żeby po importie tej bazy danych z produkcji, żeby trzymać tą aktualność możliwie jak największą żeby nie robić tego ręcznie tylko żeby automat zrobił to za nas.
Tutaj tak już zmierzając do końca warto wspomnieć o jednej bardzo ważnej rzeczy bo czasem się też zdarza tak, że jeśli mamy te środowiska już właśnie w taki uporządkowany sposób zorganizowane gdzie mamy te automatyczne deploye to wszystko no to nie możemy zrobić czegoś takiego że logujemy się na serwer produkcyjny dopisujemy sobie jakąś tam linijkę w kodzie i tak dalej bo coś potrzebujemy szybko zmodyfikować
No bo oczywiście przy pierwszym deployu coś takiego zostanie nadpisane i ta linijka nam zniknie. To jest sytuacja analogiczna do sytuacji, której dopisywali byśmy coś na przykład do pliku motywu z repozytorium bądź do jakiegoś pluginu z repozytorium i potem po po aktualizacji ten nasz kod, który zmodyfikowaliśmy wcześniej byłby nadpisany tym co przyszło z repozytorium. No i dokładnie ta sama sytuacja jest w przypadku gdy mamy jakiś customowy motyw, customowy plugin, trzymamy to wszystko w repozytorium, no to to wszystko musi przejść tą być może w tym momencie pojawiło się Ciebie w głowie coś takiego dobra, ja mam prostą stronę, jakiś tam customowy motyw i jedna wtyczka malutka, która ma tam 60 linii, która coś tam robi, to bez sensu stawiać jakieś dodatkowe środowiska i tak dalej. Tutaj naprawdę gorąco Cię zachęcam do tego, żebyś postawił sobie przynajmniej jedno takie dodatkowe środowisko. Może być to na staging, bądź nawet to środowisko lokalne, które też będzie wystarczające jeśli pracujesz sam na przykład nad stroną, no to niekoniecznie ten staging Ci się przyda, ale minimum to jedno dodatkowe środowisko, w którym będziesz mógł testować psuć w cudzysłowie oczywiście, natomiast…
To jest zawsze na wagę złota, że możesz wykonywać te operacje bez względu na to co się dzieje na produkcji. Te wszystkie operacje zupełnie nie mają wpływu na tą produkcyjną. Co więcej, tutaj też jeszcze jedna taka zaleta, że w każdym momencie możesz wstać od komputera i odejść, nawet jeśli jesteś w trakcie pisania jakiejś klasy, metody, czegokolwiek, co powoduje, że na ten moment, w tej sekundzie strona nie działa, jest rozsypana, coś się zupełnie wysypuje. No bo wiadomo, w procesie dewelopmentu, jeśli mamy coś tam niedokończonego, no to… To nie możemy oczekiwać, że cała strona będzie działała prawidłowo, tu mamy tę zaletę, że możemy odejść od komputera w każdym momencie, bo to nie jest środowisko produkcyjne, więc ono może leżeć niedziałające. To jest też bardzo ważny aspekt, jeśli pracujemy nad projektem, który jest już produkcyjnie uruchomiony, a chcemy wprowadzić jakieś nowe funkcje.
A jeśli pracujecie ze swoimi stronami w taki sposób, że ograniczacie się tylko właśnie do tych gotowych rzeczy, do pluginów, do motywów to zachęcam do postawiania choćby tego stagingu, na którym będziecie mogli spokojnie przetestować na przykład aktualizację, czy to WordPressa, czy pluginów, czy będziecie mieli pewność, że jeśli aktualizujecie to potem na środowisku produkcyjnym, no to bez problemu wszystko. Taki staging to jest też doskonałe miejsce na przykład jeśli potrzebujecie sobie zrobić jakąś nową funkcję na stronie, szukacie jakieś wtyczki, testujecie sobie te wtyczki to to jest też bardzo dobre miejsce do tego aby sobie zainstalować kilka wtyczek, przetestować, wybrać tą najlepszą i już tą jedną wybraną zainstalować na środowisku produkcyjnym. Tutaj też z tego co wiem to niektóre hostingi mają w swoich panelach dosyć prostą, automatyczną funkcję, która tworzy wam taką stagingową wersję waszej strony. Dosłownie można to wykonać za pomocą trzech kliknięć i taki staging jest uruchamiany automatycznie. Jest to też na pewno bardzo przydatna opcja, szczególnie dla tych mniej zaawansowanych dla osób, są klientami i może dziwi ich to, że developer chce stawiać jakieś tam dodatkowe. To działa tylko na plus i również na Waszą korzyść, ze względu na to, że to po prostu podnosi jakość tego wszystkiego, co jest stworzone w developmentu i dostarczania takiej strony, szczególnie jeśli to jest bardziej wymagające programistycznie wdrożenie.
W dzisiejszym odcinku to wszystko. Jeśli chcecie posłuchać w przyszłych odcinkach o takich zagadnieniach jak automatyczny deploy, automatyzacja środowisk produkcyjnych, preprodukcyjnych, stagingowych i tak dalej tych o których mówiłem dzisiaj w odcinku dajcie znać gdzieś w komentarzu, na Instagramie. Bo jeśli będziecie zainteresowani czymś takim to bardzo chętnie przygotuję odcinek w tym temacie tym bardziej, że trochę ostatnio siedzę właśnie w tych tematach około DevOpsowych można powiedzieć troszkę jeśli chodzi właśnie o automatyczne deploye, budowanie projektów i tak dalej.
Na dzisiaj to wszystko, dzięki wielkie za wysłuchanie i słyszymy się w kolejnym odcinku.
