Prosty deploy przez GITa

Temat wypychania aplikacji na produkcję jest dosyć szeroki. Mamy sporo możliwości, choćby korzystając z takiego oprogramowania jak chyba najpopularniejsze Capistrano, Mina, czy wspomagając się narzędziami typu Ansible. Ale nie zawsze potrzebujemy strzelać z armaty do muchy. Przy mini projektach przesyłanych na naszego VPSa można to zrobić w banalnie prosty sposób przy wykorzystaniu GITa, którego i tak używamy.

Żeby było ciekawiej GITa do deploymentu można użyć na kilka sposobów ale dzisiaj opowiem wam o tym, moim zdaniem, najprostszym z możliwych.

Założenia

Przyjmuję, że mamy na localhoście jakiś mały projekt, który nie potrzebuje żadnych wymyślnych czynności i w zasadzie jego cały deploy sprowadza się do przesłania plików na serwer. Projekt oczywiście jest w gicie – nie wyobrażam sobie, że ktoś jeszcze w obecnych czasach pracuje bez tego. Z drugiej strony mamy swojego VPSa lub hosting z dostępem do SSH i GITa.

I cały proces polega na tym, że na VPS robimy nowe repozytorium GITa, w którym podpinamy pod hooka akcję przenoszącą kod na docelowe miejsce. Z kolei z localhosta wypychamy kod na to repozytorium i tyle. Magia dzieje się w tle 😉 Zobaczmy jakie to jest proste w implementacji.

Konfiguracja na VPS

Tutaj potrzebujemy dwa miejsca: jedno to docelowy katalog odpalany przez serwer. Przyjmijmy, że to jest /home/webmastah/app/public_html. Drugie to miejsce gdzie założymy sobie nasze nowe repozytorum GITA – /home/webmastah/repo.

Przechodzimy do tego katalogu i zakładamy owe repo:

Opcja --bare oznacza, że nie chcemy trzymać w nim bieżącej kopii do pracy – wszak nie będziemy nic tam robić. Polecam dokładniejsze wyjaśnienie na StackOverflow.

Tworzymy hooka

W utworzonym repozytorium GITa znajdziesz katalog hooks. W środku będzie kilka przykładowych plików dla danych akcji. GIT ma ich kilka, m.in. pre-commit, pre-rebase, update, dokładniejsze wyjaśnienie znajdziesz w dokumentacji. Nas interesuje post-receive który jak sama nazwa wskazuje jest odpalany w momencie jak zawartość PUSHa w komplecie dotarła do repozytorium.

Ok, wejdźmy do tego katalogu i stwórzmy naszego hooka.

Użyj swojego ulubionego edytora lub jeżeli nie wiesz jak to robić użyj powyższego cat > post-receive. Po klepnięciu entera będziesz mógł wpisać zawartość do tego pliku, a całość zakończyć poprzez skrót control-d.

Do pliku wstaw:

Gdzie --work-tree wskazuje na nasz katalog gdzie odpalana jest aplikacja, a --git-dir na nasze utworzone przed chwilą repo.

Po wyjściu nie zapomnij nadać odpowiednich praw do tego pliku chmod +x post-receive

Tym sposobem za każdym razem jak to repozytorium otrzyma kod automatycznie przeniesie go na docelowe miejsce z naszą aplikacją.

Konfiguracja na localhoście

Przechodzimy do katalogu z naszym projektem i dodajemy do GITa nasze zewnętrzne repozytorium:

live tutaj jest dowolną nazwą, równie dobrze może to być dev czy prod. Zresztą w ten sam sposób możesz skonfigurować sobie środowisko testowe i później w zależności od potrzeb pchać zmiany w odpowiednie miejsce.

I robimy deploya

Działamy standardowo z naszym projektem. W momencie jak będziemy chcieli nasze zmiany wypchnąć na produkcję robimy po prostu git push live i gotowe. Prawda, że proste?

Wersja Video

Wkrótce video tutorial z całego tego procesu krok po kroku. Chcesz zobaczyć? SUBSKRYBUJ!

Przede wszystkim admin, potem webdeveloper choć kiedyś było odwrotnie. Obecnie Full Stack Engineer, CTO i System Architect. Po godzinach fan dobrych seriali, których nigdy nie ma czasu obejrzeć. Kawożłop. Koneser prawdziwego piwa. W czasie pomiędzy kontuzjami biega.

  • Jakub Skałecki

    Dobry, prosty sposób 🙂 Czy gdybyśmy mieli nieco bardziej skomplikowany deploy, i chcielibyśmy otrzymać info po zrobieniu pusha czy wszystko jest ok, to da się to zrobić? Tzn „wysłać” z post-receive wiadomość do naszego terminala?

    Dodatkowo jeszcze słyszałem (nie używałem) że fajnym i dość prostym rozwiązaniem jest Dokku (http://dokku.viewdocs.io/dokku/)

    • nrm

      O, ciekawe pytanie zadałeś. Nigdy nie szukałem bo samo popchnięcie mi wystarcza, nie za bardzo ma się tam coś wywalić. Nie znalazłem w dokumentacji jak zrobić żeby push na remote zwrócił wynik swojego działania z remote konsoli.

      • Piotr

        Napisałem kiedyś taki skrypcik.
        Jeżeli push jest do mastera, wszystko idzie live. W innym wypadku idzie na instancję testową, trzymaną obok 🙂

        Można do oczywiście ulepszyć i tworzyć osobne instancje testowe per-branch, ale w tym projekcie to było zbędne.

        Dodatkowo cały output wraca, mam więc info czy poprawnie wygenerował assety i wyczyścił cache

        PS. Da się tutaj formatować kod? 😀


        #!/bin/bash

        while read oldrev newrev refname
        do
        branch=$(git rev-parse --symbolic --abbrev-ref $refname)
        if [ "master" == "$branch" ]; then
        PREFIX="/home/user/web"
        else
        PREFIX="/home/user/test"
        fi

        echo "Updating files"
        git --work-tree=$PREFIX --git-dir=/home/user/git checkout $branch -f

        cd $PREFIX

        echo "Generating assets"
        "$PREFIX/node_modules/.bin/gulp"

        echo "Clearing cache"
        redis-cli flushall
        done

        • Jakub Skałecki

          „Dodatkowo cały output wraca, mam więc info czy poprawnie wygenerował assety i wyczyścił cache”

          Dzięki, właśnie o to mi chodziło!

        • nrm

          Super!

          ps. tagi html pre/post, poprawiłem Ci komentarz. DZIEKI!!!

  • Jakub Stephan

    Dobry artykuł 🙂

    Mam tylko pytanie czy update triggeruje się przy każdym pushu na brancha live, i czy live jest to nastwa brancha ?

    Czy budowanie wykonuje się z default czyli pewnie z mastera ?

    • nrm

      Tak, przy każdym bo na zdalnym to jest hook który działa automatycznie jak coś dostanie. No i jest to prosty hook który w zasadzie nic więcej nie robi, nie sprawdza, nie ma żadnej dodatkowej logiki. Tylko przerzuca do katalogu wykonywalnego.

      Tak, z mastera bo to jest skrót od git push live master i tym samym możesz zrobić sobie z innych branchy czy też zrobić kilka środowisk. Ogólnie to jest taki prosty sposób na mini projekty więc zakładam, że raczej nikt poza takie proste użīcie nie wyjdzie ale może się mylę.

      • Jakub Stephan

        Ten trigger wywołuje się również przy mergowaniu przez GitLaba na przykład z brancha development do mastera ?

        • Paweł Podolski

          Hooki można „oszukać” na wiele prostych sposobów, bo robią tylko i aż to, pod co są „zahaczone”. Możesz zrobić merge(lub rebase), a potem reset indeksu do wcześniejszego mastera, commit i git push live. Dla znających gerrita to żadna nowość. Tutaj jest hook na post receive. Można dodać na post-merge, ale ja bym się bał, bo czasem się zdarza, że po merge i tak trzeba posprzątać i zrobić drugiego pusha;) uff

      • Jakub Stephan

        Mam pytanie odnośnie tego sposobu: jak zrobić push’a na zdalne repozytorium o nazwie test z brancha test2 (wychodzi z mastera) ?

        Jest to poprawnie? = git push test test2
        Pliki zostają przesłane:
        [html]
        Counting objects: 3, done.
        Delta compression using up to 4 threads.
        Compressing objects: 100% (2/2), done.
        Writing objects: 100% (3/3), 306 bytes | 0 bytes/s, done.
        Total 3 (delta 0), reused 0 (delta 0)
        To ssh://….
        8d5d4c5..3bb4274 test2 -> test2
        [/html]

        Jednak jeśli chodzi o pliki to nie następuje podmiana.

  • Proste. Korzystam z tego przy prostych projektach.

  • Sergiusz Gieszczyk

    Nie lepiej zainstalować git ftp?

Send this to a friend

webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL