Nieustające umieszczanie – CD z Travis

„continuous deployment” to nie tylko buzzword.  Dotyczy to każdego, kto tworzy jakiś kod, który da się umieścić (ang. deploy) na zewnątrz.  Jeśli chcę by mój kod klikał ktoś inny – niż ja zapamiętale wodząc przeglądarkę po localhoście – muszę zapewnić jego dostępność pod www.zewnętrznym-urlem.pl.  Aplikację można umieścić ręcznie, ale nie o tym tutaj.  Automatyzacja to twoja siostra, a Travis to twój brat.  O tym jak umieściłem Flask-apkę na Heroku przez Travisa poniżej.  Kod apki jest tutaj na Githubie. A reszta jest milczeniem.

Moja apka

Tworzę na własne potrzeby kilka małych serwisów – nie wiem czy mikro ale duże nie są.  Bardzo prosty front (jakieś api z jednym endpointem) a pod spodem przetwarzanie danych w Pythonie.  W Pythonie bo lekko, w Pythonie bo lubię i nie chce mi się tworzyć klas gdy nie potrzebuję ich tworzyć.  A apka webowa w Flasku to prościzna.  O tym też kiedyś pisałem w takim oto mini-projekcie.

Travis

Travis to narzędzie które buduje.   Jeśli masz konto na Githubie to wystarczy się O-auth-omatycznie zalogować przez Githuba i wybierasz swój projekt.  To wyciąg z konfiguracji:

Twój projekt musi mieć takie coś w głównym katalogu i Travis sobie to przeczyta i zinterpretuje.  W powyższym mamy następujące informacje

  • gdzie kod jest
  • że trzeba go testować
  • gdzie go umieścić

Po każdym twoim puszu do Githuba cały ciąg rur (ang. pipeline) jest uruchamiany, żeby na koniec jeśli testy przeszły umieścić aplikację w środowisku docelowym.  Fajne nie?  Zero uruchamiania manualnie rzeźbionych skryptów *.sh na środowisku przez Putty’ego, zero martwienia się testami.  Po prostu piszesz kod i wypychasz.  To jest życie.  To życie pokazane jest na przykładowym zrzucie ekranu tutaj:

Heroku

Heroku to tylko jedno z wielu serwisów gdzie można za niewielkie koszta (lub nawet za darmo [oczywiście aplikacja jest usypiana i dla klienta się nie nadaje]) umieścić aplikację w technologii dowolnej.  Żeby Heroku odczytał Flask-apkę i ją uruchomił trzeba było wygenerować klucz za pomocą Heroku CLI.
Potem zostaje konfiguracja gunicorn który jest jednym z runnerów internetowej aplikacji Pythonowej.
Umieszczamy ją w pliku Procfile interpretowanym przez Heroku

Taka to aplikacja działa i wystawia swój wesoły łebek na świat przez twojaapka.herokuapp.com.  Ładujesz przez konsolę Heroku zmienne systemowe, monitorujesz logi i inne devopsowe cuda.  Oglądanie logów, ach, oglądanie..

TL;DR

Da się.  Da się zrobić szybko Continuous Deployment z Travis.  Testy i deploy zamknięty tylko w Twoim git push-u.  Chcesz się przekonać? Przeczytaj powyższy post.

Następne kroki

Taki pipeline jest jednak dosyć ubogi, prezentuje pojedynczy poziom testowania.  Idealnie byłoby mieć ich kilka i osobno odpalać testy jednostkowe a potem integrować to z innymi częściami systemu, może na dockerowych kontenerach tworzonych tylko na potrzeby testu.  Ale takie cuda to już na Openshifcie.