DiscoverPlaces Raport #5 – Travis CI
Czas na kolejny raport odnośnie tworzenia projektu DiscoverPlaces w ramach konkursu Daj się poznać 2017. W tym wpisie opisane zostanie przygotowanie środowiska do ciągłej integracji (ang. Continuous Integration) aplikacji backendowej.
Jak pisałem w poprzednim poście, API zostało ukończone, więc pora przejść do tworzenia aplikacji moblinej. Jednak wcześniej pasowałby umieścić backend na serwerze, w tym celu postanowiłem skonfigurować narzędzie Travis CI, które po każdej wrzuconej zmianie do repozytorium na githubie odpali wszystkie testy oraz w razie powodzenia prześle kod na serwer, gdzie zostanie zbudowana aplikacja. Trochę na wyrost, bo w zasadzie obecnie ta aplikacja jest bardzo mała i chwila moment można ją odpalić, ale chciałem po prostu spróbować skonfigurowania takiego zautomatyzowanego środowiska pracy, które przy większych oraz rozrastających się projektach będzie bardzo wygodne.
Konfiguracja Travis CI
language: php services: - mysql php: - 7.1 before_script: - cp app/config/parameters.yml.travis app/config/parameters.yml - composer install - php bin/console doctrine:database:create --env=test - php bin/console doctrine:schema:create --env=test - php bin/console doctrine:fixtures:load -n --env=test after_success: - eval "$(ssh-agent -s)" - chmod 600 deploy-key - ssh-add deploy-key - git remote add deploy $DEPLOY_REPO_URI - git push deploy master before_install: - echo -e "Host $HOST\n\tStrictHostKeyChecking no\n" >> ~/.ssh/config - openssl aes-256-cbc -K $encrypted_1f94ce712141_key -iv $encrypted_1f94ce712141_iv -in deploy-key.enc -out deploy-key -d
Powyżej zaprezentowany został config .travis.yml, pierwsze trzy sekcje są jasne: używamy php w wersji 7.1 oraz mysql. Następnie sekcja before-script zawiera polecenia, które zostaną wykonane przed odpaleniem testów. Są to odpowiednio:
- zmiana nazwy pliku z parametrami, tak aby symfony je wczytało
- instalacja zależności za pomocą composera
- stworzenie bazy danych
- utworzenie schematu bazy danych
- załadowanie fixtures niezbędnych do wykonania testów
Kolejno mamy sekcję after_success, polecenia w niej zawarte wykonywane są po poprawnym przejściu testów, czyli jeśli testy nie przejdą to aplikacja nie zostanie wgrana na serwer. Aby przesłać pliki za pomocą gita poprzez ssh potrzebujemy klucz, jednak nierozsądne byłoby wrzucanie go bezpośrednio do repozytorium. Z pomocą przychodzi tutaj travis cli, dzięki któremu w poniższy sposób możemy zaszyfrować pliku z kluczem i wrzucić wynik do repozytorium.
travis encrypt-file deploy_key --add
Travis dodaje automatycznie zmienne środowiskowe przypisując je do naszego repozytorium, co pozwala na odszyfrowanie pliku podczas deployowania aplikacji. Config Travisa po użyciu powyższej komendy zostaje zaktualizowany o kilka linijek w stylu:
before_install: - openssl aes-256-cbc -K $encrypted_1f94ce712141_key -iv $encrypted_1f94ce712141_iv -in deploy-key.enc -out deploy-key -d
$encrypted_1f94ce712141_key oraz $encrypted_1f94ce712141_iv to po prostu zmienne środowiskowe wstawiane przez Travisa podczas wykonywania polecenia. Jednak w configu, który wcześniej przedstawiłem w sekcji before_install znajduje się również linijka:
echo -e "Host $HOST\n\tStrictHostKeyChecking no\n" >> ~/.ssh/config
Ma ona na celu zapobieganie wyświetlaniu pytania Are you sure you want to continue connecting (yes/no)? podczas nawiązywania połączenia z serwerem. Jest to o tyle ważne, że bez tego, gdy wyskoczy to pytanie Travis będzie oczekiwał na potwierdzenie czego się nie doczeka i deploy zakończy się niepowodzeniem.
Za pomocą Travisa możemy również dodać do readme w repozytorium na githubie ikonę ( jak poniżej) oznaczającą, że nasz kod przeszedł wszystkie testy poprawnie, co pokazuje użytkownikom zainteresowanym użyciem naszego kodu, że mogą w spokoju z niego korzystać, bo jest on w pełni przetestowany (oczywiście to też zależy od jakości testów).
Konfiguracja serwera
Na serwerze natomiast utworzone zostało repozytorium git --bare init
. Jest to repozytorium nie zawierające katalogu roboczego, dlatego iż żadnych zmian tworzonych w tym miejscu nie będzie. Ważną rzeczą jest tutaj zawartość folderu hooks, w którym to mamy skrypty odpalane przez gita przy różnych zdarzeniach. W tym wypadku interesuje nas post-receive, wywoływane przy odebraniu danych. Zawarłem w nim poniższe polecenia:
#!/bin/sh git --work-tree=/var/www/discoverplaces-backend --git-dir=/home/user/repo/discover-places-backend.git checkout -f cd /var/www/discoverplaces-backend composer install --no-dev --optimize-autoloader php bin/console doctrine:schema:update --env=prod -f php bin/console cache:clear --env=prod --no-debug
Jak to wszystko działa?
Dzięki powyższym ustawieniom, po wrzuceniu zmian do repozytorium na githubie, automatycznie zostaje odpalony travis, który wykonuje wszystkie testy. Po poprawnym ich wykonaniu przesyła pliki do repozytorium na serwerze, przerzucane one są do odpowiedniego katalogu. Następnie na serwerze instalowane są odpowiednie zależności, aktualizowany jest schemat bazy danych oraz czyszczony jest cache.
Oczywiście nie jest to idealnie zorganizowane, ale jak na potrzeby tego projektu to jest aż na wyrost zrobione, więc wszystko ok. Ważne jest aby dopasować narzędzie do projektu, a nie strzelać z armaty do muchy.
Problemem z jakim się tutaj spotkałem było to, że composer install zwracał od razu Killed, a to przez to, że używam najmniejszego pakietu na DigitalOcean czyli 512 MB RAM, którego niestety zabrakło, przez co proces composera cały czas był zabijany. Rozwiązałem to w ten sposób, że wrzuciłem do repozytorium composer.lock, co pozwala zaoszczędzić trochę RAMu.
W kolejnych dniach przechodzę do pisania aplikacji w React Native, także do następnego! 😀
Subscribe and master unit testing with my FREE eBook (+60 pages)! 🚀
In these times, the benefits of writing unit tests are huge. I think that most of the recently started projects contain unit tests. In enterprise applications with a lot of business logic, unit tests are the most important tests, because they are fast and can us instantly assure that our implementation is correct. However, I often see a problem with good tests in projects, though these tests’ benefits are only huge when you have good unit tests. So in this ebook, I share many tips on what to do to write good unit tests.
Dodaj komentarz