Ciągła integracja

Wstęp

Normalnie żaden projekt informatyczny nie jest budowany przez wydelegowaną osobę, nie miało by to większego sensu, ale chętnie na taki etat bym aplikował. No ale niestety dzisiejsze system ciągłej integracji zabierają naprawdę fajną pracę.

Tak czy inaczej dziś przedstawiam jak uruchomić Jenkins’a, jako że opensource ma się dobrze to wybieram tę wersję. Oczywiście nie narzucam wybieranie tego konkretnego rozwiązania.  Równie dobrze możesz wybrać Travis’a, TeamCity, Hudson’a czy którykolwiek z systemów jaki uważasz. Ja wybieram Jenkins’a ponieważ każda firma z którą pracowałem miała go na pokładzie.

Zatem zacznijmy od początku, czyli Java:

  1. Java

    Pierwszym krokiem będzie dodanie repozytorium do naszego Ubuntu i pobranie z niego zawartości:

    add-apt-repository ppa:webupd8team/java
    apt-get update

    Teraz spokojnie możemy instalujemy:

    apt-get install oracle-java8-installer

    Po całym procesie nasza java powinna wskazywać poprawną wartość, czytaj 1.8.x. Zatem zapytajmy się jaką wersje właśnie zainstalowaliśmy:

    java -version

    i/lub kompilator:

    javac -version

    Dla pewności, możemy upewnić się że nie będzie zgrzytów na etapie zależności. Więc sprawdzamy alternatywy:

    update-alternatives --config java

    Wybieramy naszą instalację i wszystko teraz będzie działać. W kolejnym kroku dodamy naszą instalację do zmiennych środowiskowych:

    vim /etc/environment

    Dodaj na początku klucz=wartość na początku pliku:

    JAVA_HOME="/usr/lib/jvm/java-8-oracle"

    I aktualizujemy zmiany poprzez komendę source:

    source /etc/environment 
    

    Teraz już jest definitywny koniec działań z javą. Sprawdzamy czy działa zmienna środowiskowa:

    echo $JAVA_HOME

    Działa, więc zainstalujmy robotników od czarnej roboty:

  2. Maven

    Maven, solidny framework oparty na pluginach, buduje aplikacje dla banków, ubezpieczeń, portale i inne bardzo ważne rzeczy.
    Zatem pobieramy i rozpakowujemy:

    Notatka: Tę akcję wykonuje w katalogu „/tmp”, ale nie ma takie obowiązku. Pamiętaj że jesteś na prawach „root”, więc to zobowiązuje do czegoś.

    wget http://ftp.man.poznan.pl/apache/maven/maven-3/3.5.3/binaries/apache-maven-3.5.3-bin.tar.gz
    
    tar zxvf apache-maven-3.5.3-bin.tar.gz

    Teraz przenieśmy do katalogu /opt/:

    mv apache-maven-3.5.3/ /opt/

    I dodajemy zmienne środowiskowe, podobnie jak miało to miejsce dla pkt.1.
    Otwieramy plik środowisko:

     vim /etc/environment

    i dodajemy naszą zmienną:

     M2_HOME="/opt/apache-maven-3.5.3"

    Teraz jeszcze na końcu zmiennej PATH należy dodać odwołanie do katalogu bin:

    :$M2_HOME/bin

    Teraz aktualizujemy ponownie środowisko:

    source /etc/environment

    i sprawdzamy co się wydarzyło:

    # mvn -v 
    Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00) 
    Maven home: /opt/apache-maven-3.5.3 
    Java version: 1.8.0_161, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-oracle/jre 
    Default locale: en_US, platform encoding: UTF-8 
    OS name: "linux", version: "4.4.0-92-generic", arch: "amd64", family: "unix"
  3. Gradle

    Kolejnym specjalistom do spraw budowy jest Gradle, projekt bardzo szybko się rozwija i niesie ze sobą duży potencjał. Pierwsza różnica jaka jest widoczna w stosunku do Mavena, to plik ustawień bazuje na formacie skryptów Groove, gdy poprzednika opisywaliśmy w XMLach.

    A zatem do dzieła. Pobieramy i rozpakowujemy:

    wget https://services.gradle.org/distributions/gradle-4.6-bin.zip
    unzip gradle-4.6-bin.zip

    Teraz przeniesiemy do katalogu /opt/, tak jak poprzednika:

    mv gradle-4.6/ /opt/

    I zmienne środowiskowe:

    vim /etc/environment

    Dodajemy wpis:

    GRADLE_HOME="/opt/gradle-4.6"

    i do zmiennej PATH, dodajemy odwołanie do katalogu bin:

    $GRADLE_HOME/bin

    Teraz aktualizacja środowiska:

    source /etc/environment

    i sprawdzamy efekt:

    # gradle -v 
    ------------------------------------------------------------ 
    Gradle 4.6 
    ------------------------------------------------------------ 
    Build time: 2018-02-28 13:36:36 UTC 
    Revision: 8fa6ce7945b640e6168488e4417f9bb96e4ab46c 
    Groovy: 2.4.12 
    Ant: Apache Ant(TM) version 1.9.9 compiled on February 2 2017 
    JVM: 1.8.0_161 (Oracle Corporation 25.161-b12) 
    OS: Linux 4.4.0-92-generic amd64
  4. Jenkins

    Całkiem spoko, jak do tej pory. Teraz czas na gwiazdę odcinka!

    Dodajemy repozytorium do nasze list w Ubuntu i aktualizujemy jak w przypadku Java’y:

    echo "deb https://pkg.jenkins.io/debian binary/" >> /etc/apt/sources.list
    apt-get update

    Teraz pora na główne zaklęcie:

    apt-get install jenkins

    Notatka: Instalator zapyta nas czy zainstalować aplikację oraz o to czy ma instalować bez sprawdzania poprawności. Ja należę do tych, którzy wierzą w oficjalną wersję zamieszczoną na oficjalnych stronach. W sumie ktoś by zauważył, gdyby coś niezdrowego się działo.

    Po instalacji może sprawdzić czy nasz serwis działa. Wykonaj komendę:

    service jenkins status

    Teraz czas na konfigurację:

    Przejdźmy na stronę:

    jenkins.e-strix.com:8080
    

    Widzimy że aplikacja działa. Super!
    Teraz mamy do wpisania klucz, o który prosi nas pierwszy formularz. Pobierzmy go zgodnie z instrukcją:

    cat /var/lib/jenkins/secrets/initialAdminPassword

    Teraz wybierzmy sobie opcje, które pluginy mają być dodane przy instalacji. Ja wybieram wersję domyślną. Do naszej pracy wystarczy ta opcja, ale o tym będzie dalej.

    Teraz sobie chwilę poczekajmy aż instalacja przejdzie do końca i pojawi się formularz w którym będziemy poproszeni o utworzenie pierwszego administratora.

    W sumie działa, zatem możemy na tym zakończyć… Ale kole mnie po oczach ten port w pasku przeglądarki. Zatem zróbmy sobie ProxyPass. O tym w kolejnej części o serwerze Apache.

     

  5. Apache

    W zasadzie możemy pominąć kilka pierwszysch kroków instalacji ponieważ poruszałem ten temat już w dwóch wpisach, na temat Subversion/SVN oraz o Git’cie. Ale przypomnę w dość szybki sposób.

    A zatem instalujemy:

    apt-get install apache2

    Włączamy potrzebne moduły:

    a2enmod rewrite
    a2enmod proxy
    a2enmod proxy_http
    a2enmod headers
    a2enmod proxy_html
    a2enmod xml2enc

    i restartujemy serwer Apache:

    service apache2 restart

    Ok, teraz przejdźmy do katalogu dostępnych stron:

    cd /etc/apache2/sites-available/

    Tworzymy katalog naszej strony:

    mkdir -p /var/www/jenkins.e-strix.com/public_html/

    i dalej konfiguracja naszej strony:

    vim jenkins.e-strix.com.conf

    i jej zawartość

    <VirtualHost *:80>
    
     ServerAdmin k.mucik@e-strix.pl
     DocumentRoot /var/www/jenkins.e-strx.com/public_html
    
     <Directory "/var/www/jenkins.e-strx.com/public_html/" >
      Options Indexes FollowSymLinks MultiViews
      AllowOverride All
      allow from all
      Require all granted
    
      DirectoryIndex index.html
     </Directory>
    
     ServerName jenkins.e-strix.com
    
     ProxyRequests Off
     AllowEncodedSlashes NoDecode
    
     ProxyPass / http://127.0.0.1:8080/ nocanon
     ProxyPassReverse / http://127.0.0.1:8080/
     ProxyPassReverse / http://jenkins.e-strix.com/
    
     ErrorLog /var/www/jenkins.e-strix.com/error.log
     CustomLog /var/www/jenkins.e-strix.com/access.log combined
    
    </VirtualHost>

    I gra gitara… Teraz dodajemy naszą stronę i przeładowywujemy ostawienia:

    a2ensite jenkins.e-strix.com
    service apache2 reload

    Podsumowanie

    Teraz mamy już prawie wszystko aby móc automatycznie budować i publikować projekty.

    Prawie? Czyli co jeszcze?

Odpowiedź jest dość prosta, brakuje nam projektów oraz miejsca gdzie będzie publikacja. O tych elementach będą kolejne wpisy. Projekty oczywiście będą korzystały z naszej dokonanej pracy.

svn + WebSVN

Wstęp

Każdy etap prowadzenia projektu wiąże się nierozerwalnie z posiadaniem kodu oraz dokumentacji do projektu. Każdy programista wie jak ważny jest czas poświęcony na tworzenie algorytmów i ich implementacja. Jeśli jesteś osobą, która nie doświadczyła jeszcze utraty kodu poprzez błąd systemu lub dysku, spokojnie możesz zignorować poniższy tutorial, w innym przypadku zapraszam do zapoznania się z instrukcją jak postawić własny serwer kontroli wersji za złotówkę miesięcznie.

Oczywiście zapytasz czy słyszałem o dobrodziejstwie takim jak GitHub czy inny serwer. Tak, coś mi się obiło przypadkiem o uszy… Problem jest taki że darmowe konta są publiczne a prywatne kosztuje dziś 7 dolarów amerykańskich. Za tę kwotę można spokojnie wykupić sobie  serwer prywatny (trochę więcej niż wersję podstawową) i samodzielnie postawić odpowiednie narzędzia. Nie będę opisywał jak korzystać z Subversion, jest tego pełno w internecie…

W tym artykule poruszę konfigurację Subversion, opowiem o tym jak zainstalować go na serwerze z systemem Ubuntu, skonfigurować odpowiednie pliki oraz ścieżki. W dalszej części pokażę jak zainstalować klienta webowego WebSVN do przyjemnego podglądania zmian w repozytorium. Jeśli jesteś fanem gita, zachęcam do zobaczenia artykułu o instalacji gita wraz z klientem webowym GitList tutaj.

 

L.P. Czego potrzebujemy
1 VPS
2 System Operacyjny ja wybrałem Ubuntu 16.04
3 Dostęp po SSH z prawami root
4 http://websvn.tigris.org/files/documents/1380/49057/websvn-2.3.3.zip
5 Skonfigurowana domena na serwer VPS

Instalujemy PHP

Serwer który ja wybrałem oferuje instancję Ubuntu 16.04, która posiada w sobie zainstalowaną wersję PHP 7.0, jest ona wystarczalna dla naszych potrzeb. Jeśli zdecydujesz się na instalację wyższej wersji lub niższej, też jest ok. Wykorzystywane narzędzia wymagają PHP 5, zatem bez wahania decyduj.

apt-get install php7.0 php7.0-fpm -y

Instalujemy Apache

Kolejny krok to instalcja serwera apache, może również wykorzystać nginx. Ja korzystam z Apache chyba przez zasiedzenie. Jest on dość prymitywny ale działa i jest łatwy do konfigurowania. Apache spokojnie może obsługiwać do 250 użytkowników jednocześnie więc dla niewielkich stron można śmiało przy nim zostać, jeśli przewidujemy ruch do 1000 użytkowników jednocześnie zainteresujmy się serwerem nginx lub stworzeniem farmy serwerów.

Wykonajmy polecenie:

apt-get install subversion apache2 libapache2-svn libapache2-mod-php php-xml-parser

Ok, teraz mamy zainstalowany serwer i czas na konfigurację. Przejdźmy do katalogu dostępnych stron w serwerze i stwórzy nasz plik konfiguracyjny:

cd /etc/apache2/sites-available/
vim svn.e-strix.com.conf

Ja używam Vim’a do edycji, ale użyj dowolnie. Początki z edytorami textowymi są trudne ale warte nauki.

Plik wypełnij zawartością wg nw. listingu:

<VirtualHost *:80> 
ServerAdmin kontakt@e-strix.pl 
ServerName svn.e-strix.com 

DocumentRoot /var/www/svn.e-strix.com/public_html/ 

<Directory "/var/www/svn.e-strix.com/public_html/"> 
DirectoryIndex index.php index.html 
Options FollowSymLinks 
AllowOverride All 
</Directory> 

<Location /repo> 
DAV svn 
SVNParentPath /home/svnuser/repo 
SVNListParentPath On 
</Location> 

ErrorLog /var/www/svn.e-strix.com/error.log 
CustomLog /var/www/svn.e-strix.com/access.log combined 
</VirtualHost>

Stwórz katalog w którym będą nasze aplikacje:

mkdir -p /var/www/svn.e-strix.com/

ustaw stronę jako aktywną i przeładuj ustawienia Apache:

a2ensite svn.e-strix.com
service apache2 reload

Tworzymy repozytorium

Repozytorium subversion podobnie jak git’a może być gdziekolwiek na dysku. Dla zachowania przejrzystości, utworzymy konto użytkownika svn a w nim katalog z naszymi projektami.

Zatem dodajemy użytkownika i uzupełniamy dane o które poprosi system:

adduser svnuser
usermod -a -G svnuser www-data

Dalej tworzy nasz katalog repozytorium:

mkdir -p /home/svnuser/repo/

Gdy poprawnie zainstalujemy pakiet subversion, dostępne będzie dla nas narzędzie svnadmin do zarządzania projektami. Korzystamy z niego dodając nowe repozytorium:

svnadmin create /home/svnuser/repo/project1

Przejdźmy teraz do innego katalogu, ja wybrałem katalog /tmp i pobierzmy kopię repozytorium. W tym przypadku posłużę się kopiowaniem z pliku, komenda co jest skrótem od checkout. A zatem:

cd /tmp/
svn co file:///home/svnuser/repo/project1

Subversion pobrał na projekt, wejdźmy do środka i stwórzmy dowolny plik. Ja wybrałem .svnignore, może być dowolny:

cd project1/
touch .svnignore

Teraz dodajmy go używając komendy add oraz wypchnijmy zmiany do naszego repozytorium ci -m „comment”, bardzo ważne jest używanie przełącznika -m:

svn add .svnignore
svn ci -m "init commit"

Dodajemy klienta webowego

Jest wiele dostępnych na rynku klientów webowych, każdy z nich działa. Nie będę się rozdrabniał na to, który jest mikrosekundę szybszy czy ma lepiej napisany kod. To jest dla nas nie istotne bo i tak w większości będziemy pracować na lokalnych maszynach w wybranym IDE lub konsoli. WebSVN u mnie wygrał ze względu na intuicyjność i funkcjonalność. Ma też przyjemny interfejs, który mnie nie denerwuje więc dobrze mi się z nim pracuje.

W pierwszej kolejności musimy nadać prawa do katalogu repozytorium dla użytkownika www-data, który jest wykorzystywany przez serwer www.

Notatka: Nie jest to część poświęcona idealnemu skonfigurowaniu katalogów. Jeśli masz życzenie tworzyć hierarchię grup i użytkowników to śmiało.

Zatem zmieniamy właściciela katalogu:

cd /home/svnuser
chown -R svnuser:www-data repo/

Przejdźmy teraz do naszego katalogu aplikacji i pobierzmy klienta:

Notatka: wymagany jest program wget.

cd /var/www/svn.e-strix.com/
wget http://websvn.tigris.org/files/documents/1380/49057/websvn-2.3.3.zip

Teraz rozpakujmy pobrane archiwum, zmieńmy nazwę wypakowanego katalogu websvn-2.3.3 na public_html, zgodny z plikiem konfiguracyjnym serwera:

Notatka: Wymagany jest program unzip. Może nie być zainstalowany domyślnie.

unzip websvn-2.3.3.zip
mv websvn-2.3.3/ public_html/

Wyczyścimy śmieci i nadamy właściciela plików:

rm websvn-2.3.3.zip

chown -R www-data:www-data public_html/

Konfiguracja klienta

Teraz już z górki. Do pełnego sukcesu potrzebujemy jeszcze skonfigurować naszego klienta z utworzonym repozytorium.

Przechodzimy do katalogu public_html/include i w nim musimy utowrzyć plik konfiguracyjny. Całe szczęście że dostawca załączył przykładowy plik distconfig.php, który możemy wykorzystać… Utworzymy plik w tej lokalizacji o nazwie config.php.

cd public_html/include
vim config.php

Jego zawartość znajduje się na nw. listingu. Więc przekopiuj i zapisz plik:

<?php
$config->parentPath('/home/svnuser/repo');
$config->addTemplatePath($locwebsvnreal.'/templates/calm/','group');
?>

Teraz spokojnie możemy wpisać adres w przeglądarce i naszym oczom pojawi się zawartość naszego jednego repozytorium. Ale co w przypadku gdy bym miał ich więcej? Spokojnie… w przypadku gdy jest tylko jedno repo aplikacja od razu przekierowuje na jej zawartość, jeśli będzie więcej projektów, pierw ukaże się nam ich lista.

Dodajmy na serwerze kolejny projekt:

svnadmin create /home/svnuser/repo/project2
chown -R svnuser:www-data /home/svnuser/repo/project2/
chmod -R 774 /home/svnuser/repo/project2/

I teraz spróbujemy skorzystać z innego komputera, w taki sposób aby ruch odbył się przez sieć. Ja użyłem swojego laptopa.

Przechodzimy na dowolny katalog z prawami zapisu.

Teraz pobieramy nasze repozytorium:

svn co http://svn.e-strix.com/repo/project2/

Dodamy jakiś plik do projektu i wypchniemy zmiany na serwer:

cd project2/
vim index.html
svn add index.html
svn ci -m "init commit"

Zmiany możemy obserwować już na serwerze.

Podsumowanie

Systemy kontroli wersji są podstawą przy pracy programisty czy DevOps’a, szukanie błędów w kodzie czy winnych jest dużo łatwiejsze gdy można śledzić każdą zmianę. Powstaje także odpowiedzialność osoby za swoje „dzieło”. Kolejnym plusem okazuje się możliwość zdalnego budowania poprzez odpowiednie narzędzia CI takie jak Hudsom, Jenkins, Travis czy TeamCity, które można ustawić w taki sposób aby czasowo budowały aplikację czy dla każdego komitu. Tak rozproszony system bardzo przyspiesza pracę nad projektem i pozwala deweloperowi skupić się nad konkretnym zadaniem.

Co wybrać? Czy Subversion czy Git? Ja używam obu w pracy, dla nowych projektów zainteresowałbym się gitem ale i svn też jest bardzo popularny. Pamiętajcie że duże instytucje nie lubią zmian…