Wielu developerów boryka się z deployem swojej aplikacji na serwery produkcyjne.

Jedni wgrywają wszystkie pliki przez FTP, inni po SSH, a Ci bardziej zaawansowani robią git pull.

Do tego zazwyczaj dochodzi uruchomienie różnych procesów począwszy od instalacji pakietów Composer, aż po minifikację plików CSS i JS.

Problem rodzi się gdy nasza strona przestaje działać, odwiedzający się denerwują a my w pocie czoła i pośpiechu próbujemy dojść co się zepsuło.

Jeśli więc Deploy jest Twoim koszmarem lub chciałbyś aby to było jak najprostsze to czytaj dalej...

Deployer - co to?

Deployer to skrypt napisany w PHP który upraszcza deploy do wykonania jednej komendy np: dep deploy production. Prawda że banalne?

Jak to działa?

Najważniejszym elementem Deployer'a jest plik z zapisanymi instrukcjami do wykonania:

<?php

server('prod_1', 'domain.com')
    ->user('user')
    ->password('pass')
    ->env('deploy_path', '/home/www')
    ->stage('production');

set('repository', 'https://github.com/user/app.git');

task('reload:php-fpm', function () {
    run('sudo /usr/sbin/service php5-fpm reload');
});

after('deploy', 'reload:php-fpm');
after('rollback', 'reload:php-fpm');

Objaśnienie:

server('prod_1', 'domain.com')
    ->user('user')
    ->password('pass')
    ->env('deploy_path', '/home/www')
    ->stage('production');

To jest definicja serwera z którym połączy się Deployer. To tylko przykładowy wpis. Można też m.in. zdefiniować połączenie za pomocą Kluczy SSH.

set('repository', 'https://github.com/user/app.git');

Ustawienie adresu repozytorium z którego będą pobierane pliki

task('reload:php-fpm', function () {
    run('sudo /usr/sbin/service php5-fpm reload');
});

Przykładowe zadanie zdefiniowane. Po prostu przeładowuje PHP-FPM. Ten Task jest zalecany ponieważ serwer musi pobrać nową ścieżkę dla serwera. Bez tego nie zobaczymy zmian.

after('deploy', 'reload:php-fpm');
after('rollback', 'reload:php-fpm');

Wykonanie Task po pomyślnym wykonaniu Deploy lub po pomyślnym Rollback.

Pełna dokumentacja jest dostępna tutaj: http://deployer.org/docs

Jak działa Deploy

Po zdefiniowaniu naszego pliku z Taskami oraz uruchomieniu deploy zaczyna się zabawa.

Skrypt łączy się z serwerem, a następnie zakłada potrzebną strukturę katalogów:

/your/project/path
|--releases
|  |--20150513120631
|--shared
|  |--...
|--current -> /your/project/path/releases/20150513120631

W katalogu releases tworzony jest katalog z obecna datą i tam właśnie jest pobierany nasz projekt. Uruchamiane są wszystkie zadania zdefiniowane.

Kolejnym krokiem jest zmiana symlink current na najnowszy release (Jeśli wykonał się całkowicie bez błedu).

Wtedy jest właśnie potrzebny reload PHP-Fpm ponieważ bez tego serwer będzie miał w pamięci odnośnik do poprzedniego release. I to już koniec, wchodzimy na naszą stronę i sprawdzamy czy zmiany weszły poprawnie, a jeśli jednak coś się popsuło i serwis nie nadaje się do oglądania to...

Rollback

To jest właśnie cała moc Deployer. Po wykonaniu jednej prostej komendy dep rollback production wracamy do poprzedniej działającej wersji.

Skrypt po prostu zmienia z powrotem symlink na poprzednią wersję, reload PHP-FPM i gotowe.

Shared folders & files

Deployer ma jeszcze jeden ciekawy feature - Shared Folders. Są to po prostu wydzielone katalogi które są wspólne dla wszystkich releasów. Można tam trzymać m.in. cache, pliki konfiguracyjne, pliki które się nie zmieniają lub są nie wersjonowane. Tak samo działają Shared Files ale dla plików.

Recipes

Aby jeszcze dodać pikanterii Deployer ma zdefiniowane tzw Recipes. Są to przygotowane konfiguracje które są specyficzne do robienia deploy różnych frameworków. Jeden z Recipes jest do Laravela który wygląda np. tak:

// Laravel shared dirs
set('shared_dirs', [
    'storage/app',
    'storage/framework/cache',
    'storage/framework/sessions',
    'storage/framework/views',
    'storage/logs',
]);

// Laravel 5 shared file
set('shared_files', ['.env']);

// Laravel writable dirs
set('writable_dirs', ['storage', 'vendor']);

Podsumowanie

Deployer to bardzo duże ułatwienie przy robieniu Deploy na serwery produkcyjne. Z racji zapisanego pliku konfiguracyjnego ryzyko pomyłki maleje do minimum. Jak wiemy ilość operacji może powodować zapomnienie wykonania czegoś albo w nieodpowiedniej kolejności.

Jest to też świetna dokumentacja dla Administratorów jak przebiega proces Deploy.

Rollback minimalizuje ryzyko stresu w przypadku niepowodzenia lub błędu w deployu.

Obecnie Blog LekkieBlogowanie używa tego rozwiązania i powiem że spisuje się bardzo dobrze.

Projekt jest dostępny tutaj: deployer.org