Miesięczne archiwum: Listopad 2013

Phing, czyli zautomatyzuj swoje zadania #1

Pracując przy projekcie programistycznym, oprócz pisania kodu trzeba też m.in. zarządzać projektem – może to być uruchomienie testów, skonfigurowanie projektu czy wdrożenie projektu etc. Z reguły każde z takich zadań wymaga wykonania jakichś operacji, często wielu i w określonej kolejności – w tym miejscu „zapala się lampka”. Takie operacje można, a nawet trzeba, zautomatyzować! Dzięki temu uniknie się błędów wynikających z rutyny, znudzenia wykonywaniem ciągle tych samych operacji, bo czas można poświęcić na ciekawsze sprawy.

Dla programistów Javy znajomo brzmi nazwa Ant. Dla programistów PHP istnieje podobne narzędzie o nazwie Phing. W obu przypadkach, w skrócie, chodzi o możliwość „oprogramowania” różnych zadań związanych z projektem i późniejsze tylko uruchamianie odpowiednich procedur, które aplikacja zrobi za użytkownika.

Tym wpisem chciałbym rozpocząć cały cykl wpisów na temat narzędzia Phing, a ponieważ to pierwszy wpis zacznijmy od podstaw.

Instalacja

Instalacja narzędzia jest możliwa na kilka sposobów, wszystkie opisane są na tej stronie: http://www.phing.info/trac/wiki/Users/Installation. Poprawność instalacji, można zweryfikować poleceniem w konsoli:

root@cim-k52:~# phing -version
Phing 2.6.1

Użycie

Użycie Phinga do zarządzania projektem opiera się na utworzeniu i wypełnieniu pliku build.xml. Jak wskazuje rozszerzenie jest to plik XML. Dzięki temu nie trzeba się uczyć nowej składni (wystarczy znajomość podstaw XML). Dodatkowo działanie Phinga jest niezależne od systemu operacyjnego (włącznie ze ścieżkami do plików). Oprócz build.xml bardzo przydatne są pliki właściwości (*.properties), które są źródłem danych dla skryptu1.

Na początek kilka „słów kluczowych” odnośnie projektu z perspektywy Phing:

  • project (projekt) – <project> to główny element w pliku build.xml, tzw. root node; definuje projekt, jego nazwę, opis, domyślny cel; dokumentacja
  • target (cel) – <target> definiowane cele, które będzie można później wywoływać, np. konfiguracja projektu, wdrożenie na środowisko, uruchomienie testów; cele składają się z wywołań zadań; dokumentacja
  • properties (właściwość) – <property> pozwala definiować właściwości, które w grunie rzeczy oznaczają zmienne skryptu; dokumentacja
  • task (zadanie) – to konkretne zadania, których wykonanie składa się na osiągnięcie celu, np. skopiowanie/przeniesienie pliku, wgranie na serwer; w dokumentacji można znaleść listę dostępnych zadań

Na koniec pierwszego wpisu testowe uruchomienie, poniżej treść pliku build.xml:

<?xml version="1.0" encoding="UTF-8"?>

<project name="HelloWorld" default="hello">

    <property name="who"  value="World" />

    <target name="hello">
	<echo>Hello ${who}</echo>
    </target>

</project>

Plik build.xml najlepiej umieścić w głównym katalogu projektu. Podstawowym sposobem użycia jest wywołanie w katalogu zawierającym plik skryptu z poziomu konsoli:

cim@cim-k52:~/public_html/Phing$ phing hello
Buildfile: /home/cim/public_html/Phing/build.xml

HelloWorld > hello:

     [echo] Hello World

BUILD FINISHED

Total time: 0.0559 seconds

W powyższym przypadku wywołanie phing i phing hello daje ten sam efekt, ponieważ cel hello jest domyślnym celem projektu.

Komunikaty na konsoli pozwalają śledzić operacje (cele i zadania) wykonywane przez Phing (co jest szczególnie przydatne przy wywoływaniu celów, które zależą od osiągnięcia innych celów). Na koniec pojawia się komunikat o „BUILD FINISHED” informujący o poprawnym zakończeniu pracy, w innym wypadku pojawi się „BUILD FAILED” ze szczegółowym komunikatem błędu.


1 zawartość pliku build.xml będę nazywał skryptem, jeżeli macie/znacie lepsze nazwy piszcie w komentarzach