Wdrażanie na żywo i przemieszczanie za pomocą Deploybot

Jeśli od jakiegoś czasu zajmujesz się tworzeniem stron internetowych, prawdopodobnie zepsułeś transfer plików, gdy próbujesz zaktualizować witrynę. W najlepszym przypadku dodajesz do katalogu kilka łatwych do zidentyfikowania plików i usuwasz je, aby naprawić błąd. Tak, to kosztuje czas i jest denerwujące, ale nic złego się nie stało.

W najgorszym przypadku niewłaściwie przeniesiesz kilka plików motywów. Następnie musisz dowiedzieć się, które z nich zostały nadpisane, a które w ogóle nie pasują i jak u licha odzyskasz właściwy stan działania motywu.

Dzisiaj zajmiemy się rozwiązaniem tego problemu za pomocą Git i Deploybot, aby zautomatyzować proces wdrażania.

Co to jest automatyczne wdrażanie?

Podstawowe automatyczne wdrożenie składa się z czterech elementów, jak pokazano na tym diagramie.

Większość programistów zaczyna od samego kodu i serwera. Wprowadzają zmiany w swojej kopii roboczej witryny, a następnie przesyłają te zmiany bezpośrednio na serwer za pośrednictwem FTP. Narzędzia takie jak Coda lub Dreamweaver mają bezpośrednią integrację z FTP, dzięki czemu można to zrobić z wnętrza środowiska kodowania.

Następnym krokiem, który podejmuje wielu programistów, jest dodanie witryny testowej, aby nie modyfikowali bezpośrednio działającego serwera. Możesz to zrobić za pomocą czegoś takiego jak VVV lub MAMP. Często oznacza to również, że używasz systemu kontroli wersji, takiego jak Git, do zarządzania zmianami wprowadzanymi w lokalnej witrynie roboczej.

Dodając witrynę testową, dodajesz również złożoność. W jaki sposób można przenieść zmiany kodu z lokalnej witryny roboczej do witryny tymczasowej, w której klient może zobaczyć zmiany? Tak, jak już powiedziałem, możesz użyć podstawowego klienta FTP, takiego jak FileZilla, Transmit lub Forklift, aby przenosić pliki podczas wprowadzania zmian, ale jest to podatne na błędy i tutaj zautomatyzowanie procesu wdrażania pozwoli Ci zaoszczędzić tyle czasu.

Zamiast pobierać zmienione pliki i przesyłać je na serwer pomostowy, używasz innego systemu, aby automatycznie wykryć zmiany w repozytorium Git i przesłać tylko te zmiany do witryny pomostowej, której klient może użyć do sprawdzenia pracy.

To nadal pozostawia twoją działającą witrynę jako ręczne wdrażanie, co jest znacznie bardziej przerażające, ponieważ może oznaczać utratę prawdziwych pieniędzy, jeśli usuniesz działającą witrynę. Zamiast tego załóżmy, że zamierzasz skonfigurować system wdrażania do automatycznego wdrażania do przemieszczania, a następnie system zostanie wdrożony za pomocą jednego kliknięcia do środowiska na żywo, gdy będziesz gotowy do pracy.

Więc teraz masz system, który wygląda tak.

Zanurzmy się, aby pokazać, jak skonfigurowałem ten proces wdrażania dla każdego klienta, z którym pracuję. Oto kroki, które podejmuję, gdy tylko zaczynam nowy projekt. Zawsze upewniam się, że mój proces wdrażania jest skonfigurowany i działa, zanim zacznę wykonywać inne prace nad projektem klienta.

Jak zorganizować swoje repozytorium Git

Twoim pierwszym wyborem jest, w którym katalogu skonfigurujesz automatyczne wdrożenie? O ile mój klient wyraźnie nie zażąda pełnej kontroli źródła dla swojej instalacji WordPressa, używam katalogu wp-content do skonfigurowania mojego automatycznego systemu wdrażania. To zaczyna się w terminalu, wydając to polecenie, które inicjuje repozytorium git.

git init

Teraz nadszedł czas, aby zignorować pliki, których nie chcesz cały czas wdrażać. Są to pliki, takie jak pliki kopii zapasowych, obrazy i dowolne niestandardowe pliki projektu, które wiele edytorów kodu dodaje do katalogu. Możesz zobaczyć mój zwykły plik .gitignore poniżej.

config/app_config.yml

config/database.yml

config/*.sphinx.conf

config/s3_credentials.yml

*~

*.Pamięć podręczna

*.dziennik

*.pid

tmp/**/*

.DS_Store

baza danych/cstore/**

db/sfinks/**

dokument/api

dokument/aplikacja

dokument/wtyczki

dokument/*.kropka

zasięg/*

db/*.sqlite3

*.tmproj

*.południowy zachód?

*.esproj

_notatki*

dwsync.xml

podcast.xml

*.kpf

*przesyłane/*

*.swp

*.pomysł

*.wysublimowany-projekt

*.sublime-workspace

*/moduły_węzłów/*

tagi

*.bak

Pamięć podręczna/*

zarządzajwp/*

mu-wtyczki/*

dp.php

prąd wstępny/*

Języki/*

db.php

wtyczki/wp-rocket/cache.json

Możesz dodać lub usunąć to w razie potrzeby. Prawie każdy projekt, nad którym pracuję, wymaga jakiegoś niestandardowego wpisu, aby zignorować jakiś plik, który jest specyficzny dla mojej lokalnej witryny roboczej, dla której witryny pomostowe i działające będą miały swój własny niestandardowy plik, którego nie chcę nadpisywać.

Od tego momentu nadszedł czas na skonfigurowanie oddziałów potrzebnych do uruchomienia systemu wdrożeniowego. Używam dwóch głównych gałęzi. Pierwsza to gałąź master, która odpowiada mojemu zakładowi produkcyjnemu na żywo. Po drugie, jest to gałąź, którą określam jako pomost i odpowiada witrynie pomostowej, której chcę, aby mój klient używał jako sposobu sprawdzania wprowadzanych przez nas zmian.

Kiedy zainicjowałeś repozytorium Git, masz już swoją główną gałąź, więc użyj tego polecenia, aby dodać gałąź pomostową i sprawdzić ją.

git checkout -b staging

To polecenie tworzy i wypisuje nową gałąź. Jeśli jesteś nowy w git, możesz znaleźć więcej informacji na temat dostępnych poleceń w dokumentacji Git.

Teraz musisz wepchnąć swój projekt do systemu kontroli źródła. Github i Bitbucket to dwie popularne opcje, które współpracują ze zautomatyzowanym systemem wdrażania, którego będziemy używać, o nazwie Deploybot. Kiedy tworzysz nowe repozytorium w dowolnej witrynie, otrzymasz dalsze wskazówki, jak dodać lokalne repozytorium do wersji online w Github lub Bitbucket.

• Dokumentacja konfiguracji repozytorium Bitbucket
• Dokumentacja konfiguracji repozytorium Github

Konfigurowanie Deploybota

Kiedy po raz pierwszy zająłem się bardziej złożoną pracą jako programista, mój przyjaciel Duane wciąż polecał mi Deploybot, gdy narzekałem online na zepsucie ręcznego wdrażania FTP. Potrzebowałem wielu zaleceń, zanim w końcu zrobiłem to, co mi kazano, ale teraz jestem szczęśliwym klientem Deploybot od lat.

Chociaż istnieją inne sposoby wdrażania witryn, wiele z nich wiąże się z łączeniem się z elementami Webhook usługi Git lub niektórymi plikami konfiguracji automatycznego wdrażania za pośrednictwem edytora kodu. W tych innych narzędziach jest dużo mocy, ale jeśli dopiero zaczynasz z automatycznym wdrażaniem, warto zacząć od czegoś prostego, takiego jak Deploybot.

Aby rozpocząć, załóż konto Deploybot i połącz Github lub Bitbucket ze swoim kontem. Dzisiaj użyję mojego istniejącego konta Bitbucket. Zacznij od dodania nowego repozytorium do swojego konta Deploybot.

Po znalezieniu repozytorium, które chcesz skonfigurować do automatycznego wdrażania, kliknij przycisk oznaczony połącz na dole strony. Spowoduje to odesłanie Cię z powrotem do strony repozytorium, podczas gdy Deploybot zakończy inicjowanie repozytorium. Zwykle odbywa się to za minutę lub dwie, więc napełnij kawę i wróć, aby dokończyć konfigurację procesu wdrażania.

Po skonfigurowaniu repozytorium kliknij je, aby przejść do jego strony głównej. Ponieważ nie mamy jeszcze skonfigurowanych informacji sFTP, będzie na nim duże pole z informacją, że należy skonfigurować serwer. Kliknij przycisk, aby utworzyć środowisko i serwer.

Zacznijmy od wdrożenia do naszego środowiska pomostowego. Więc oznacz swój serwer jako pomostowy. Wybierz automatyczne wdrożenie i upewnij się, że ustawiłeś gałąź na przemieszczanie.

Po zakończeniu kliknij przycisk Zapisz na dole strony, aby przejść do konfiguracji serwera.

Na następnej stronie oznacz go ponownie jako Serwer pomostowy i umieść informacje sFTP ze swojej witryny. Jeśli nie wiesz, gdzie je znaleźć, przeczytaj ten pomocny przewodnik.

Po wprowadzeniu informacji sFTP możesz przewinąć w dół i zapisać je. Następnie Deploybot przetestuje Twoje połączenie, aby upewnić się, że podane przez Ciebie informacje działają. Teraz nadszedł czas na wstępne wdrożenie witryny, aby upewnić się, że wszystko działa. Często dodaję plik test.txt do wdrożenia, aby w łatwy sposób sprawdzić, czy wdrożenie działało prawidłowo.

Aby rozpocząć wdrażanie w historii środowiska, kliknij opcję Wdróż.

Teraz zobaczysz stronę z ostatnim komunikatem git commit jako notatkę, którą zobaczysz wewnątrz Deploybot obok tego wdrożenia. W przypadku dużych zmian zmienię to, ale jeśli tylko zmieniam CSS lub coś pomniejszego, komunikat o zatwierdzeniu może pozostać. Ponieważ jest to etapowanie, każdy zatwierdzenie w naszej gałęzi pomostowej zostanie wdrożone automatycznie, co oznacza, że ​​pojawią się komunikaty o zatwierdzeniu. To tylko początkowe zatwierdzenie, które musimy wykonać ręcznie na naszej stronie tymczasowej.

Teraz sprawdź, czy Twoje pliki zostały opublikowane w witrynie testowej, a my możemy skonfigurować wdrożenie na żywo.

W przypadku wdrożenia na żywo upewnij się, że nie wybierasz automatycznego wdrożenia i upewnij się, że jako źródło wdrożenia wybrałeś gałąź główną. Chcemy, aby było to wdrożenie ręczne, gdy jesteśmy gotowi do wypychania zmian do naszej działającej witryny.

Aby to zrobić, musisz sprawdzić swoją gałąź master, a następnie scalić zmiany z gałęzi pomostowej do gałęzi master.

Możesz to zrobić za pomocą tych poleceń.

Mistrz kasy git

git scalania inscenizacji

Mistrz pochodzenia git push

Teraz, gdy przejdziesz do swojego konta Deploybot, będziesz mógł ręcznie wdrożyć swoje zmiany, tak jak zrobiliśmy to w przypadku naszego początkowego wdrożenia w naszym środowisku przejściowym. W przypadku aktywnego środowiska upewnij się, że zmieniłeś komunikat o wdrożeniu, aby pasował do zmian, które są wypychane do działającej witryny. Powinieneś także utworzyć kopię zapasową swojej witryny. Możesz to zrobić, otwierając nawigację kopii zapasowych w witrynie, a następnie tworząc ręczną kopię zapasową.

To wszystko, masz konfigurację zautomatyzowanego systemu wdrażania zarówno dla środowisk pomostowych, jak i na żywo.

Inne uwagi dotyczące wdrażania

Chociaż ten system jest dużym krokiem naprzód dla większości programistów, nie jest pozbawiony problemów. Największą z nich jest to, że jeśli masz wiele zmian, nadal czekasz, aż FTP zakończy przesyłanie zmienionych plików. Może to oznaczać, że ktoś odwiedza Twoją witrynę, a nie wszystkie pliki potrzebne do uruchomienia witryny.

Dla wielu klientów nie będzie to problemem, ale jeśli jest to dla Twojej witryny, musisz przyjrzeć się skonfigurowaniu systemu wdrażania Atomic. Ten typ systemu wdrażania przenosi wszystkie pliki, sprawdza, czy działają poprawnie, a następnie zmienia ustawienia plików na serwerze, tak aby nowy katalog był teraz tym, w którym działa witryna.

Proces łączenia się z nowym folderem trwa tak krótko, że tylko komputer by to zauważył. Oznacza to również, że jeśli później znajdziesz problem, możesz zmienić link systemowy z powrotem do starej wersji witryny, aby przywrócić działającą wersję. To znowu zajmuje bardzo mało czasu i skraca przestoje.

Bez względu na to, co zdecydujesz się zrobić, już dziś przestań używać klienta FTP do wdrażania plików klienta. Niewielki miesięczny koszt Deploybota jest odzyskiwany za każdym razem, gdy nie popełnisz błędu podczas wdrażania plików.