PHP 5. Narzędzia dla ekspertów

Transkrypt

1

2 Idź do Spis treści Przykładowy rozdział Katalog książek Katalog online Zamów drukowany katalog Twój koszyk Dodaj do koszyka Cennik i informacje Zamów informacje o nowościach Zamów cennik Czytelnia Fragmenty książek online Kontakt Helion SA ul. Kościuszki 1c Gliwice tel helion@helion.pl Helion PHP 5. Narzędzia dla ekspertów Autor: Dirk Merkel Tłumaczenie: Jarosław Dobrzański ISBN: Tytuł oryginału: Expert PHP 5 Tools Format: , stron: 450 Osiągnij wyższy poziom zaawansowania w PHP! Jak tworzyć efektywny, łatwy w utrzymaniu kod PHP? Jak automatycznie tworzyć dokumentację techniczną? Jak debugować aplikację z Xdebug? Język PHP to ulubione środowisko wielu programistów tworzących aplikacje i strony internetowe. Jego wykorzystanie pozwala na błyskawiczne osiągnięcie efektów, a nauka nie przysparza trudności. Trudno wskazać moment, w którym PHP zdobył tak ogromną popularność. Chwilami można odnieść wrażenie, jakby w sieci był obecny od zawsze. Piąta wersja tego języka zawiera wszystko to, co powinien posiadać nowoczesny język programowania możliwość programowania obiektowego, wsparcie dla formatu XML oraz rozbudowane mechanizmy wejścia-wyjścia. PHP 5 może z powodzeniem konkurować z dużymi rozwiązaniami, dostępnymi od lat na rynku aplikacji internetowych. Niniejsza książka to pozycja przeznaczona dla programistów, którzy znają już podstawy tego języka. To unikalny podręcznik, dzięki któremu nauczysz się tworzyć efektywny, profesjonalny i łatwy w utrzymaniu kod. W trakcie lektury zdobędziesz wiedzę na temat systemów kontroli wersji, testów jednostkowych, szkieletów aplikacji oraz narzędzi wspomagających proces debugowania. Ponadto dowiesz się, w jaki sposób tworzyć dokumentację z wykorzystaniem phpdocumentor, jak wybrać najlepszy szkielet aplikacji oraz wdrożyć aplikację w środowisku produkcyjnym. Dzięki tej książce osiągniesz wyższy poziom zaawansowania w programowaniu w języku PHP! Standardy pisania kodu PHP Opracowywanie własnych standardów Przygotowanie profesjonalnego środowiska programistycznego Dokumentowanie kodu za pomocą phpdocumentor Zarządzanie kodem źródłowym i jego wersjami Debugowanie aplikacji Szkielety aplikacji PHP Testy jednostkowe tworzenie niezawodnego kodu Wdrażanie aplikacji Projektowanie aplikacji z wykorzystaniem UML Proces ciągłej integracji Ta książka pomoże Ci stać się lepszym programistą!

3 Spis tre ci O autorze 9 O recenzentach 11 Przedmowa 13 O czym jest ta ksi ka? 13 Co jest potrzebne, aby skorzysta z ksi ki? 14 Dla kogo jest ta ksi ka? 14 Konwencje 15 Uwagi Czytelników 15 Przyk adowy kod 16 Rozdzia 1. Standardy i styl pisania kodu 17 Co uwzgl dni przy tworzeniu standardów? 17 Zalety 18 Wady 19 Standard pisania kodu PHP 19 Formatowanie 20 Konwencje nazewnicze 25 Metodologia 29 Weryfikacja zgodno ci ze standardami pisania kodu 35 Automatyczna kontrola zgodno ci za pomoc narz dzia PHP_CodeSniffer 35 Podsumowanie 46 Rozdzia 2. Dokumentowanie za pomoc narz dzia phpdocumentor 49 Dokumentacja w tre ci kodu 50 Poziomy szczegó owo ci 51 Wprowadzenie do programu phpdocumentor 52 Instalacja programu phpdocumentor 52 Bloki DocBlock 54 Szablony DocBlock 55

4 Spis tre ci Samouczki 56 Dokumentowanie projektu 59 Opcje programu phpdocumentor 74 Katalog tagów 78 Tagi stosowane w PHP4 94 Tagi u ytkownika 94 Podsumowanie 95 Rozdzia 3. Eclipse zintegrowane rodowisko programistyczne 97 Dlaczego Eclipse? 98 Wprowadzenie do PDT 100 Instalacja Eclipse 100 Wymagania 100 Wybór pakietu 102 Dodawanie pluginu PDT 102 Podstawowe poj cia zwi zane z Eclipse 104 Przestrze robocza (Workspace) 104 Widoki (Views) 105 Perspektywy 107 Przyk adowy projekt PDT 108 Mo liwo ci funkcjonalne pluginu PDT 111 Edytor 111 Inspekcja 115 Debugowanie 117 Preferencje PDT 120 Inne mo liwo ci funkcjonalne 127 Pluginy Eclipse 128 Zend Studio dla Eclipse 129 Wsparcie 131 Refaktoring 131 Generowanie kodu 131 Testowanie za pomoc PHPUnit 131 Obs uga programu phpdocumentor 132 Integracja ze szkieletem Zend Framework 133 Integracja z serwerem Zend 133 Podsumowanie 133 Rozdzia 4. Zarz dzanie kodem ród owym i wersjami 135 Typowe przypadki u ycia 135 Krótka historia kontroli kodu ród owego 136 CVS 139 Wprowadzenie do Subversion 141 Instalacja klienta 141 Konfiguracja serwera 142 Poj cia zwi zane z Subversion 143 Lista polece Subversion 147 Tworzenie projektu Subversion 157 4

5 Spis tre ci Sposób pracy z systemem kontroli wersji 164 Bli sze spojrzenie na repozytorium 169 Odga zienia i scalanie 171 Aplikacje klienckie 177 Konwencje i najlepsze praktyki przy pracy z Subversion 183 Przystosowywanie Subversion do w asnych potrzeb 184 Powiadamianie programistów o zatwierdzonych plikach za pomoc skryptu post-commit 187 Podsumowanie 187 Rozdzia 5. Debugowanie 189 Pierwsza linia obrony kontrola sk adni 189 Dzienniki 191 Opcje konfiguracyjne 192 Dostosowywanie opcji konfiguracyjnych i panowanie nad nimi PhpIni 194 Wy wietlanie informacji diagnostycznych 201 Funkcje 201 Magiczne sta e 205 Tworzenie w asnej klasy diagnostycznej 205 Wprowadzenie do Xdebug 221 Instalacja Xdebug 221 Konfiguracja Xdebug 224 Natychmiastowe korzy ci 225 Zdalne debugowanie 228 Podsumowanie 235 Rozdzia 6. Szkielety aplikacji PHP 237 Pisanie w asnego szkieletu 237 Ocena i wybór szkieletów 238 Spo eczno i akceptacja 239 Mo liwo ci funkcjonalne 239 Dokumentacja 240 Jako kodu 240 Stosowanie i zgodno ze standardami pisania kodu 241 Dopasowanie do projektu 241 atwo w nauce i adaptacji 242 Dost pno kodu ród owego 242 Znajomo szkieletu 243 Ich zasady 243 Popularne szkielety aplikacji PHP 243 Zend 244 CakePHP 244 CodeIgniter 245 Symfony 245 Yii 246 5

6 Spis tre ci Aplikacja w szkielecie Zend Framework 247 Lista cech i funkcji 247 Kr gos up aplikacji 248 Usprawnienia 253 Podsumowanie 272 Rozdzia 7. Testowanie 273 Metody testowania 273 Czarna skrzynka 274 Bia a skrzynka 274 Szara skrzynka 275 Typy testowania 276 Testowanie jednostkowe 276 Testowanie integracyjne 277 Testowanie regresyjne 277 Testowanie systemowe 278 Testy akceptacji u ytkowników 278 Wprowadzenie do PHPUnit 279 Instalacja PHPUnit 279 Przeszukiwanie ci gu tekstowego (przyk adowy projekt) 281 Analiza pokrycia kodu 306 Podklasy klasy TestCase 307 Podsumowanie 308 Rozdzia 8. Wdra anie aplikacji 309 Cele i wymagania 309 Wdra anie aplikacji 311 Wymeldowywanie plików i wysy anie ich na serwer 312 Wy wietlanie informacji o niedost pno ci serwisu 313 Aktualizacja i instalacja plików 313 Aktualizacja schematu i zawarto ci bazy danych 314 Rotacja plików dziennika i aktualizacja dowi za symbolicznych 314 Weryfikacja wdro onej aplikacji 315 Automatyzacja procesu wdro enia 315 Phing 315 Podstawowa sk adnia i struktura pliku 317 Typy 321 Wdra anie serwisu 322 Podsumowanie 339 Rozdzia 9. Projektowanie aplikacji za pomoc j zyka UML 341 Metamodel i notacja a nasze podej cie do UML 342 Poziom szczegó owo ci i przeznaczenie 343 Narz dzia jedno- i dwukierunkowe 344 Podstawowe typy diagramów UML 345 Diagramy 346 6

7 Spis tre ci Diagramy klas 347 Diagramy sekwencji 359 Przypadki u ycia 364 Podsumowanie 368 Rozdzia 10. Ci g a integracja 369 Systemy satelitarne 371 Kontrola wersji Subversion 371 Testowanie PHPUnit 372 Automatyzacja Phing 373 Styl pisania kodu PHP_CodeSniffer 374 Dokumentowanie PhpDocumentor 375 Analiza pokrycia kodu Xdebug 375 Przygotowanie rodowiska 376 Czy potrzebuj dedykowanego serwera CI? 376 Czy potrzebuj narz dzia CI? 376 Narz dzia CI 377 XINC 377 phpundercontrol 377 Ci g a integracja z phpundercontrol 378 Instalacja 378 Konfiguracja CruiseControl 382 Przegl d procesu i komponentów ci g ej integracji 382 Podsumowanie 404 Skorowidz 405 7

8 8 Wdra anie aplikacji Po zako czeniu pisania aplikacji i zadbaniu o to, by inwestorzy zatwierdzili jej odbiór, przychodzi czas na jej wdro enie. W zasadzie w tym momencie powinni my ju mie za sob kilkukrotne jej wdro enie i ca y proces powinien by w mniejszym lub wi kszym stopniu zautomatyzowany. Wi kszo projektów, w które by em ostatnio zaanga owany, skorzysta o na tym, e aplikacja by a wielokrotnie wdra ana w ró nych rodowiskach, takich jak programistyczne, testowe i docelowe. Automatyzacja tego procesu umo liwia szybkie uruchamianie kolejnych egzemplarzy aplikacji. Jest to nie tylko dobry sposób na wyeliminowanie wszelkich potencjalnych problemów przy wdro eniu, ale tak e du y krok w kierunku poprawienia produktywno ci nowych programistów. Je eli proces wdro enia zosta zoptymalizowany i dobrze udokumentowany, nowi cz onkowie zespo u programistycznego nie b d musieli po wi ca wiele czasu na utworzenie w asnego rodowiska programistycznego. Zamiast tego mog wykona kilka prostych kroków, aby uzyska aplikacj dzia aj c i gotow do dalszego rozwoju. Cele i wymagania Zastanówmy si, jakie powinny by nasze cele podczas wdra ania lub aktualizowania aplikacji. Innymi s owy, co jest miar sukcesu w tym procesie? Mo e nam przyj do g owy twierdzenie, e to, jak dobrze dzia a aplikacja, jest konsekwencj tego, jak dobrze przeprowadzone zosta o wdro enie. To jednak by oby myl ce. Na tym etapie nie interesuje nas ju projekt funkcjonalny, programowanie ani testowanie. Dzia amy przy za o eniu, e dysponujemy w pe ni funkcjonuj c aplikacj, która musi zosta wdro ona. To, czy aplikacja b dzie dzia a zgodnie z oczekiwaniami, mo e, ale nie musi by naszym problemem i nie ma nic wspólnego z samym jej wdra aniem.

9 PHP 5. Narz dzia dla ekspertów Powstaje wi c pytanie, na jakiej podstawie ustali, czy wdro enie przebieg o pomy lnie? Do czego powinni my d y, tworz c plan wdro enia? Jak mo na si spodziewa, mam kilka przemy le na ten temat. Po pierwsze, wdro enie powinno odby si szybko. Wszyscy ci, którzy wdra aj aplikacje r cznie, b d zaskoczeni, ile z tego, co robi, mo na zautomatyzowa przy odpowiednim planowaniu. Kiedy wdra amy aplikacj po raz pierwszy, zwykle nie musimy si spieszy i mo- emy upewni si, e wszystko dzia a, jak trzeba, zanim powiadomimy klienta o tym, i sta a si dost pna. Oczywi cie szybkie wdro enie staje si o wiele wa niejsze, kiedy aktualizujemy aplikacj, b d c ju w sta ym u yciu. W takiej sytuacji naszym celem powinno by zminimalizowanie lub najlepiej unikni cie wszelkich niedogodno ci lub przerw w dostawie us ug wiadczonych przez aplikacj. W a nie wówczas szybko staje si istotna. Drugim celem wdro enia jest jego pe na odwracalno. Najlepiej zacz traktowa aktualizacje aplikacji jako transakcj znan z systemów bazodanowych. Je eli co si nie powiedzie w trakcie wdro enia, powinni my by w stanie cofn wszystkie wykonane dotychczas kroki i przywróci aplikacj dok adnie do stanu sprzed rozpocz cia wdro enia. O ile wydaje si to sensowne i logiczne, czasami nie atwo osi gn to w praktyce. We my na przyk ad sytuacj, kiedy musimy zmodyfikowa istniej c tabel bazy danych. Mo e to wymaga uruchomienia kilku zapyta, aby zmieni struktur tabeli i pomanipulowa danymi. Je eli pope nimy b d lub pojawi si jaki nieprzewidziany problem, to jak cofniemy zmiany? Je eli mamy plan, b dziemy mogli przywróci baz z kopii zapasowej, któr zrobili my przed rozpocz ciem wdra ania. Jednak w zale no ci od rozmiaru bazy adowanie wszystkich danych do wszystkich tabel mo e potrwa dobre kilka minut. Mo emy wi c przywróci z kopii zapasowej tylko naruszon tabel, ale do tego potrzebujemy specjalnego narz dzia. Je eli zrobili my kopi zapasow w formie monolitycznego pliku zrzutu, znalezienie jednej tabeli i przywrócenie jej mo e by trudne. Inn opcj jest uruchamianie specjalnie przygotowanych zapyta cofaj cych zmiany, które doprowadzi y do problemu. W tym przypadku zapytania te trzeba b dzie przygotowa wcze niej i nie b dziemy mie na to czasu w sytuacji kryzysowej przy du ych naciskach na szybkie rozwi zanie problemu. Jak wida, jest wiele sposobów na to, by uczyni aktualizacje odwracalnymi. Konieczne jest dok adne planowanie, aby proces by odwracalny na ka dym etapie. Podsumujmy nasze wymagania dotycz ce wdro enia lub aktualizacji: 1. Szybko i automatyzacja w celu minimalizacji niedogodno ci dla u ytkowników i b dów ludzkich. 2. Pe na odwracalno wszystkich czynno ci. Powtórzy em to w punktach, poniewa dalsze rozwa ania po wi cone planom wdro enia, poszczególnym czynno ciom i pisaniu kodu, który pozwoli to zrealizowa, b d osnute wokó konsekwencji tych wymogów. To na ich podstawie b dziemy ocenia, na ile uda o si osi gn cel. 310

10 Rozdzia 8. Wdra anie aplikacji Wdra anie aplikacji W poprzednim punkcie wspominali my o mo liwo ci odwracania poszczególnych kroków w trakcie wdra ania, ale co w a ciwie kryje si pod poj ciem kroku? Przyjrzyjmy si kilku czynno ciom, które s typowe podczas wdra ania lub aktualizowania aplikacji. W dalszej cz ci rozdzia u przejdziemy do implementacji tych zada i próby ich maksymalnego zautomatyzowania. Poni szy diagram ilustruje kroki w procesie wdra ania aplikacji lub serwisu internetowego. Oczywi cie w zale no ci od aplikacji mo emy jakie kroki doda, a jakie zignorowa, ale kroki tu pokazane stanowi dobr podstaw w przypadku wi kszo ci wdro e. 311

11 PHP 5. Narz dzia dla ekspertów Zanim omówi szczegó owo ka dy z powy szych kroków, zastanówmy si nad ogólnym przebiegiem procesu ukazanego na diagramie. Zaczynamy od wymeldowania ca ego projektu z systemu kontroli wersji. W celu dostosowania si do rodowiska, w którym aplikacja b dzie wdra ana, niektóre pliki, a w szczególno ci pliki konfiguracyjne b d musia y zosta zmodyfikowane. Nast pnie w istniej cym serwisie internetowym publikujemy komunikat informuj cy u ytkowników o trwaj cych pracach konserwacyjnych. Po zainstalowaniu plików, dokonaniu odpowiednich zmian w bazie danych i rotacji plików dziennika usuwamy komunikat o przerwie w funkcjonowaniu serwisu, restartujemy serwer i ponownie udost pniamy stron u ytkownikom. Na koniec dokonujemy inspekcji serwisu, aby sprawdzi, czy aplikacja dzia a poprawnie. Wymeldowywanie plików i wysy anie ich na serwer Zak adaj c, e nasz projekt rezyduje w jakim systemie kontroli wersji, b dziemy musieli najpierw wydoby go stamt d w takiej postaci, która b dzie nadawa si do wdro enia na docelowy serwer. Je eli jako systemu kontroli wersji u ywamy narz dzia Subversion, omówionego w innym rozdziale tej ksi ki, musimy wykona polecenie export, aby uzyska kopi pozbawion wszystkich metadanych, jakie Subversion przechowuje zwykle w plikach ukrytych w ka dym z katalogów projektu. W innych systemach kontroli wersji mo e obowi zywa inna terminologia i inne polecenia, ale idea pozostaje taka sama. Konieczne jest utworzenie kopii projektu pozbawionej metadanych i wszelkich innych plików, które nie s przeznaczone do wdro enia na serwer. Czasem jednak b dzie nam zale e na takim wdro eniu, w ramach którego wdro ony kod ród owy pozostaje powi zany z repozytorium. Pos uguj c si terminologi Subversion, mo emy wymeldowa kod do lokalnej lub zdalnej kopii roboczej. Korzy ci z takiego podej cia s dwojakie. Po pierwsze mo emy u ywa informacji z repozytorium do przyspieszenia przysz ych procesów aktualizacji. Mo emy na przyk ad zaktualizowa wymeldowan wersj do bie cej wersji z repozytorium jednym poleceniem. Po drugie, je eli nasz proces wdro eniowy obs uguje wymeldowania z repozytorium, mo na dzi ki niemu szybko tworzy rodowiska programowania i w ten sposób poprawia produktywno nowych cz onków zespo u. Z tego wzgl du proces, który opracujemy w tym rozdziale, b dzie umo liwia zarówno wdro enie docelowe, jak i programistyczne. Prawdopodobnie b dziemy musieli równie zmieni jeden z kilku plików konfiguracyjnych, wprowadzaj c takie ustawienia, które odpowiadaj rodowisku docelowemu aplikacji. Bywa, e trzeba ustawi w ten sposób katalog g ówny projektu, parametry uwierzytelniaj ce dla bazy danych, bazowy adres URL itp. Warto w tym momencie powróci na chwil do rozdzia u po wi conego szkieletom aplikacji, poniewa stworzona tam przyk adowa aplikacja zosta a specjalnie zaprojektowana tak, by dzia a w ró nych rodowiskach z u yciem stosownych sekcji w pliku konfiguracyjnym. Takie rozwi zanie przewiduje istnienie zautomatyzowanego procesu wdro eniowego, obs uguj cego ró ne rodowiska. 312

12 Rozdzia 8. Wdra anie aplikacji Dysponuj c wdra an wersj projektu, mo emy przes a go na serwer. Zwykle nast puje to za po rednictwem protoko ów FTP, SFTP lub SCP (SSH). Zalecam korzystanie z którego z bezpiecznych wariantów, aby nie eksponowa danych uwierzytelniaj cych. Je eli pracujemy na instalacji rezyduj cej na serwerze docelowym, mo emy po czy dwa kroki, czyli eksportowanie i wysy anie plików na serwer, wykorzystuj c fakt, e wszystkie nowoczesne systemy kontroli wersji obs uguj operacje zdalne. Wystarczy wymeldowa projekt z repozytorium wprost na docelowy komputer. Wy wietlanie informacji o niedost pno ci serwisu Zanim naci niemy metaforyczny guzik wy czaj cy serwis, powinni my powiadomi u ytkowników, e prowadzimy prace konserwacyjne na serwerze. Ja sam zwykle kieruj u ytkowników do standardowej strony HTML informuj cej o trwaj cych pracach i sugeruj cej ponown prób po czenia za kilka minut. Je eli dobrze zaplanujemy i zautomatyzujemy aktualizacje, przerwa w dost pno ci us ugi dla u ytkowników powinna by minimalna lub wr cz adna. W tym momencie mo e pa pytanie, po co wobec tego w ogóle wstawiamy informacj o niedost pno ci serwisu. Otó informacja ta nagle mo e sta si bardzo istotna w sytuacji, gdy co przeszkodzi nam w p ynnej realizacji dobrze zaplanowanego wdro enia. W takiej chwili b dziemy desperacko próbowa ustali ród o problemu i jak najszybciej go wyeliminowa. Du ulg b dzie wówczas to, e nie musimy przejmowa si informowaniem u ytkowników i zamiast tego mo emy skupi si na tym, co naprawd wymaga naszej uwagi, czyli na rozwi zywaniu problemu. Po zako czeniu aktualizacji strona informuj ca o przerwie musi zosta usuni ta. To równie nale y zautomatyzowa, poniewa jest to co, o czym naprawd nie chcieliby my zapomnie. Aktualizacja i instalacja plików Kiedy pliki s ju na serwerze, musimy udost pni je dla u ytkowników. Zast powanie istniej cych plików nowymi nie jest zgodne z nasz zasad odwracalno ci. Mo na by zmieni nazwy plików i przenie je do katalogu ze starymi plikami, po czym zast pi orygina y nowymi wersjami, ale istnieje szybsza metoda. W systemach, które dopuszczaj stosowanie dowi za symbolicznych (zwanych te aliasami lub skrótami), dobra praktyka polega na utworzeniu dowi zania symbolicznego wskazuj cego katalog zawieraj cy pliki aplikacji. Gdy przychodzi czas aktualizacji, wystarczy przekierowa dowi zanie na inny katalog, a nowe pliki stan si z miejsca dost pne. 313

13 PHP 5. Narz dzia dla ekspertów Aktualizacja schematu i zawarto ci bazy danych Wi kszo wspó czesnych aplikacji korzysta z jakiej formy bazy danych, w ród których prym wiedzie MySQL z uwagi na swoj popularno. Podczas pierwszego wdro enia aplikacji zwykle jeste my tak e odpowiedzialni za prawid owe utworzenie i udost pnienie bazy danych. W przypadku aktualizacji istniej cej instalacji musimy znale jaki sposób modyfikacji schematu i zawarto ci bazy. Najcz ciej polega to na utrzymywaniu pliku tekstowego, do którego programi ci dodaj zapytania wprowadzaj ce w bazie zmiany wymagane przez zaktualizowany kod. W trakcie wdra ania administrator bazy lub programista jest wówczas odpowiedzialny za wykonanie tych zapyta w tym czasie, gdy wykonywane s wszystkie inne zadania zwi zane z wdro eniem. Mimo e takie podej cie mo e si sprawdza w przypadku aktualizacji lub tworzenia baz, nie spe nia ono postawionych wcze niej wymogów. Otó nie umo liwia atwej odwracalno ci, chyba e z góry to zaplanujemy. Poza tym wdra aj c kolejne aktualizacje, napotykamy kolejne zmiany w bazie danych i wówczas przywrócenie poprzednich stanów staje si coraz bardziej skomplikowane. Jedno z rozwi za mo e stanowi narz dzie umo liwiaj ce definiowanie, zarz dzanie i wykonywanie krokowych zmian w bazie danych. Owe krokowe zmiany zwane s migracjami, a narz dzie, za którego pomoc b dziemy zarz dza migracjami, to DbDeploy. Poniewa ka demu krokowi aktualizuj cemu baz odpowiada krok wstecz, powracaj cy do poprzedniej wersji, mo liwe jest przeskakiwanie od stanu do stanu bazy w dowolnym kierunku. Co wi cej, zmiany mo na aplikowa w sposób zautomatyzowany, co zaspakaja obydwa nasze wymogi dotycz ce udanego wdro enia. W szczegó y programu DbDeploy zag bimy si w dalszej cz ci rozdzia u, przy okazji definiowania migracji bazy danych na potrzeby naszego przyk adu. Rotacja plików dziennika i aktualizacja dowi za symbolicznych W zale no ci od tego, gdzie i w jaki sposób nasza aplikacja przechowuje informacje, konieczna albo przynajmniej zalecana mo e by rotacja plików dziennika. Przede wszystkim trzeba si upewni, czy serwer mo e zapisywa do plików dziennika, co nie jest pewne w przypadku, gdy pliki dziennika znajduj si w podkatalogu naszej aplikacji i uaktywnili my je na serwerze docelowym, edytuj c dowi zanie symboliczne. Bywa, e do wie o wdro onej aplikacji trzeba skopiowa inne biblioteki lub aplikacje wspomagaj ce. Ja na przyk ad utrzymuj interfejs WWW do czytania poczty, który jest dost pny z poziomu katalogu g ównego dokumentów serwera mojej strony WWW. Nie jest on jednak cz - ci projektu w repozytorium Subversion i trzeba go skopiowa lub przekierowa dowi zanie symboliczne po ka dym wdro eniu nowej wersji strony. 314

14 Rozdzia 8. Wdra anie aplikacji Weryfikacja wdro onej aplikacji Krok ten mo e si wydawa oczywisty, ale jednocze nie jest to co, o czym nie wypada zapomnie. Powinni my sprawdzi, czy wszystko, co zosta o wdro one, dzia a tak, jak oczekujemy. W tym jednym kroku musimy dopu ci pewne odst pstwo od za o onych wymogów. Co prawda mo emy i chcemy pewne testy zautomatyzowa, np. testowanie nag ówków odpowiedzi HTTP, ale niektóre rzeczy po prostu trzeba sprawdzi r cznie. Czasami najprostszym sposobem na sprawdzenie, czy wszystko dzia a, jest otwarcie przegl darki i skorzystanie z aplikacji tak, jak b d korzysta z niej u ytkownicy. Dzi ki temu z miejsca mo emy wykry wiele powa nych problemów. Automatyzacja procesu wdro enia Skoro wiemy ju, co chcemy osi gn, przejd my do omawiania narz dzi, za których pomoc dokonamy implementacji i automatyzacji naszego planu wdro enia. Jest kilka pomniejszych narz dzi, które pomog nam wykona to zadanie, ale g ównym narz dziem pozwalaj cym wszystko zautomatyzowa i wykonuj cym wi kszo zada jest Phing. Phing Phing to system konsolidacji projektów. Nazwa to rekurencyjny akronim, którego pe ne brzmienie w j zyku angielskim to Phing Is ot Gnu Make (Phing to nie GNU Make). Phing umo liwia wykonywanie ró nych zada zwi zanych z konsolidacj oprogramowania. Szczególnie dobry jest w automatyzacji zada, która, jak mo na wnioskowa po dotychczasowej lekturze tego rozdzia u, jest dla nas bardzo wa na. Co prawda twórcy narz dzia Phing aktywnie zaprzeczaj wszelkim zwi zkom pomi dzy tym programem a narz dziem make, ale mo na bezpiecznie stwierdzi, e make le y w jakiej cz ci u podstaw Phing. Phing zosta jednak bardziej oparty na narz dziu Ant, które jest najcz ciej stosowanym systemem konsolidacyjnym w j zyku Java. W naszym przypadku przewaga Phing nad narz dziem Ant polega na tym, e obs uguje on ró ne zadania specyficzne dla programowania w PHP. Poza tym Phing jest napisany w PHP, co u atwia programistom tego j zyka rozszerzanie funkcjonalno ci systemu. Phing jest sterowany tzw. celami (targets) zdefiniowanymi w pliku XML. Cele s w gruncie rzeczy dzia aniami wykonywanymi przez Phing. Plik XML definiuj cy owe cele i zale no ci mi dzy nimi zwykle ma nazw build.xml. Cele sk adaj si z kolei z jednego lub kilku zada. Wi cej o celach i zadaniach b dzie w dalszej cz ci rozdzia u. 315

15 PHP 5. Narz dzia dla ekspertów Takie rozwi zanie u atwia odr bne wykonywanie którego ze zdefiniowanych celów z automatyczn obs ug zale no ci. Przyk adowe cele zdefiniowane przez u ytkownika to: create-skeleton tworzy katalogi potrzebne na serwerze. checkout-site wymeldowuje projekt z systemu Subversion. update-db wykonuje wst pnie zdefiniowane zapytania w celu aktualizacji struktury i zawarto ci bazy danych. Powy szych przyk adowych celów u yjemy te mi dzy innymi w naszym projekcie. Instalacja narz dzia Phing Narz dzie Phing mo na zainstalowa na kilka sposobów. Najprostszy i najbardziej bezbolesny sposób polega na wykorzystaniu instalatora Pear. Z repozytoriów i narz dzia Pear korzystali- my ju wiele razy w tej ksi ce. Przyczyna jest prosta to dzia a i sta o si ogólnie przyj te do tego stopnia, e wi kszo narz dzi, które tutaj omawiam, mo na w ten sposób pobra i zainstalowa. Zamiast od razu uruchamia narz dzie pear, chcia bym zwróci uwag, jak wietny przyk ad stanowi ono w niniejszym rozdziale. Chwila zastanowienia i okazuje si, e wpisuj c pear install phing/phing, robimy dok adnie to, czemu po wi cony jest ten rozdzia wdra amy (instalujemy) aplikacj, a konkretnie Phing. Innymi s owy, zale nie od typu aplikacji rozprowadzanie jej za po rednictwem kana u Pear mo e stanowi jeszcze jedno podej cie do wdra ania. Teraz mo emy przej do praktyki i zainstalowa Phing za pomoc Pear. Oto przebieg i rezultat instalacji Phing z wiersza polece : Tak naprawd s tu tylko dwa polecenia. Pierwsze, pear channel-discover pear.phing.info, informuje instalator Pear, e pod adresem pear.phing.info znajduje si repozytorium Pear. Drugie polecenie, pear install phing/phing, instaluje pakiet o nazwie phing (drugie wyst pienie phing ) poprzez kana o nazwie phing (pierwsze wyst pienie phing ). 316

16 Rozdzia 8. Wdra anie aplikacji Inn metod instalacji Phing jest bezpo rednie wymeldowanie go z repozytorium CVS projektu. Zalet jest to, e otrzymujemy w ten sposób naj wie sz i najlepsz baz kodu, w tym nieopublikowane jeszcze poprawki i ulepszenia. Z tej w a nie metody musimy skorzysta, je eli chcemy w o y w asn prac w rozwój projektu, poniewa b dziemy wówczas mogli zatwierdza zmiany z powrotem do repozytorium. Oczywi cie zak adaj c, e otrzymamy uprawnienia do dokonywania zmian. Podstawowa sk adnia i struktura pliku Plik konsolidacyjny zawiera kod XML definiuj cy wszystkie dzia ania i cele dost pne dla u ytkownika. Zgodnie z konwencj plik ten otrzymuje nazw build.xml. Je eli jednak korzystamy z opcji buildfile [nazwa_pliku] w wierszu polece, mo emy zmieni t nazw na dowoln inn. W naszym przyk adzie pozostaniemy przy przyj tej konwencji nazewniczej. Przyjrzyjmy si ogólnej strukturze pliku konsolidacyjnego Phing. Poni szy szkielet takiego pliku nie definiuje adnych dzia a. Jego celem jest jedynie zilustrowanie podstawowej struktury takich plików. Wraz z post pem pracy nad naszym przyk adem b dziemy uzupe nia kolejne cz ci tego pliku, zmierzaj c do opracowania w pe ni zautomatyzowanego procesu wdro eniowego. <l?xml version="1.0"?> <project name="nazwaprojektu" description="opcjonalny opis pliku konsolidacyjnego." default="nazwaceludomy lnego"> <property name="jaka W a ciwo Globalna" value="warto " override="true" /> <type> <!-- globalna definicja typu --> </type> <target name="nazwaceludomy lnego" depends="celpomoniczy" description="opis domy lnego zadania."> <property name="w a ciwo Lokalna" value="warto " override="true" /> <type> <!-- lokalna definicja typu --> </type> <task> <!-- definicja zadania --> </task> <!-- nast pne zadania (opcjonalnie) --> </target> <target name="celpomocniczy" description="opis celu pomocnicznego."> <task> <!-- definicja zadania --> </task> 317

17 PHP 5. Narz dzia dla ekspertów <!-- nast pne zadania (opcjonalnie) --> </target> </project> Jako programista zapewne znasz dobrze format XML, dlatego omówi szkielet pliku konsolidacyjnego bardzo krótko. Wydaje mi si te, e najlepiej zacz omawianie hierarchii znaczników od wewn trz. Zadania Sercem pliku konsolidacyjnego s zadania ujmowane w znacznikach <task>. Znaczniki te odpowiadaj wprost dzia aniom. To tutaj wykonywana jest ca a rzeczywista praca. Znaczniki <task> mo na traktowa jako najdrobniejsz jednostk wykonywanych dzia a. Dokumentacja Phing definiuje te podstawowe zadania jako te, które s niezb dne, by skonsolidowa projekt. Dla odró nienia zadania opcjonalne to te, które nie s niezb dne dla skonsolidowania projektu. Moim zdaniem rozró nienie to jest nieco sztuczne, szczególnie w zwi zku z faktem, e PHP to j zyk interpretowany, co oznacza, e proces konsolidacji nie zawiera w sobie fazy kompilacji. Oto przyk adowe zadania: CopyTask kopiuje pliki lub grupy plików albo katalogów z jednego miejsca w systemie plików w inne, z mo liwo ci zmiany nazwy. ForeachTask przechodzi przez list i umo liwia uj cie jednego lub kilku zada w p tli i wykonanie ka dego z nich dla ka dego elementu z listy. InputTask prosi u ytkownika o wprowadzenie danych, z których mo na skorzysta przy wykonywaniu nast pnych zada. A oto przyk ady zada opcjonalnych: SvnExportTask eksportuje projekt z repozytorium Subversion do lokalnego katalogu. ZipTask/UnzipTask dwa uzupe niaj ce si zadania tworz ce archiwum ZIP z grupy plików lub rozpakowuj ce pliki z istniej cego archiwum. PHPUnit2Task uruchamia przypadki testowania lub zestawy testów za po rednictwem systemu testuj cego PHPUnit2. Zadania przypominaj nieco funkcje w tym sensie, e mog przyjmowa argumenty. Gdy tylko zaczniemy tworzy nasz przyk adowy skrypt konsolidacyjny do wdra ania aplikacji, zobaczymy praktyczne przyk ady zada. Zamiast podawa list wszystkich dost pnych zada wraz z mo liwymi opcjami, odsy am Czytelników do bardzo dobrze napisanej dokumentacji online, zawieraj cej naj wie sz i najlepsz list zada wraz z opisami, dost pnej pod adresem 318

18 Rozdzia 8. Wdra anie aplikacji Wreszcie, je eli zestaw zada udost pniany przez Phing nie zaspakaja naszych wymaga, mo- emy bez problemu dodawa w asne zadania. Jako narz dzie open source Phing jest z za o enia rozszerzalny. Fakt, i zosta napisany w PHP, potencjalnie u atwi wi kszo ci Czytelników tej ksi ki dopisywanie kodu w asnych zada. Tak naprawd dodanie w asnego zadania w formie klasy przyjmuj cej argumenty i wykonuj cej po dane operacje jest zaskakuj co proste. Cele Cele (targets) to logicznie powi zane grupy zada. Zadania grupowane s w formie celów, aby osi gn okre lony rezultat. Mo emy na przyk ad mie cel o nazwie backup-db, który grupuje zadanie tworz ce kopi zapasow bazy danych, zadanie kompresuj ce otrzymany plik zrzutu bazy oraz zadanie przesy aj ce kopi poprzez FTP do miejsca, w którym zwykle przechowujemy kopie zapasowe. Zadania zawarte pomi dzy otwieraj cym i zamykaj cym znacznikiem <target> s wykonywane w kolejno ci wyst powania. Cele maj trzy atrybuty s to name (nazwa), description (opis) oraz depends (powi zania). Dzi ki atrybutowi name mo liwe jest wykonanie danego celu z wiersza polece. Oto przyk adowe wywo anie celu upgrade-db w domy lnym pliku konsolidacyjnym build.xml: $ phing upgrade-db Nazwa celu jest opcjonalna w powy szym wywo aniu i je eli nie zostanie podana, wykonywany jest domy lny cel zdefiniowany w znaczniku <project>, który omówiony zostanie za chwil. Atrybut description znacznika <target> zawiera krótkie podsumowanie dzia a wykonywanych w ramach celu. Wreszcie atrybut depends pozwala wskaza inne cele, które musz zosta wykonane przed danym celem. Phing ledzi, które z celów zosta y ju wykonane, i automatycznie wywo uje cele, które s konieczne, aby spe ni ten wymóg. W przedstawionym wcze niej przyk adowym szkielecie pliku build.xml cel o nazwie domy lnanazwacelu jest uzale niony od celu celpomocniczy. Je eli wywo amy cel domy lnanazwacelu, Phing zadba o to, by celpomocniczy zosta wykonany wcze niej. W atrybucie depends mo na poda wi cej ni jeden cel zale ny, oddzielaj c je przecinkami. Podobnie jak zadania, cele s wykonywane w kolejno ci wyst powania. W a ciwo ci i plik w a ciwo ci W terminologii narz dzia Phing w a ciwo ci to odpowiedniki zmiennych. Mo na definiowa je w globalnej przestrzeni nazw lub w lokalnej dla okre lonego celu. Globalne definicje w a- ciwo ci musz nast powa poza obr bem znaczników <target>, a definicje lokalne w obr bie znacznika <target>, którego maj dotyczy. 319

19 PHP 5. Narz dzia dla ekspertów Nieco dalej pojawi si kilka globalnych definicji w a ciwo ci i typów. W a ciwo ci to w gruncie rzeczy zmienne, z których wi kszo nie zmienia warto ci w trakcie wykonywania skryptu. S jednak równie w a ciwo ci tworzone dynamicznie i u ywane przez skrypt konsolidacyjny do zachowania stanu w obr bie celu lub pomi dzy wykonaniem poszczególnych celów. W a ciwo ci s definiowane i u ywane w pliku build.xml w nast puj cy sposób: <property name="svn.url" value= " override="true" /> W tym przyk adzie definiujemy w a ciwo o nazwie svn.url. Warto przypisywana tej w a- ciwo ci to adres URL, który z kolei jest konstruowany z kilku ci gów tekstowych i dwóch zdefiniowanych wcze niej w a ciwo ci: svn.server i svn.project. Jak wida, aby pos u y si warto ci przypisan do danej w a ciwo ci, nale y u y sk adni z symbolem dolara, po którym nast puje nazwa w a ciwo ci w nawiasach klamrowych: ${nazwa_w a ciwo ci}. Mo liwe jest (i bardzo wygodne) przechowywanie w a ciwo ci w odr bnych plikach, zawieraj cych wy cznie pary nazwa-warto. Pliki te s zgodne z konwencj nazewnicz, nakazuj c, by nazwa ko czy a si przyrostkiem.properties. Oto przyk ad prostego pliku w a ciwo ci: # Subversion svn.server=waferthin.com svn.proto= # definicje wielu innych w a ciwo ci # ustawienia i parametry uwierzytelniaj ce dla bazy danych db.server=localhost db.user=root db.password=psstdonttell db.name=state_secrets Jak wida, sk adnia jest bardzo prosta. Warto ci s przypisywane nazwom w a ciwo ci za pomoc znaku równo ci i w ka dym wierszu musi wyst powa tylko jedna para nazwa-warto. Importowanie takiego pliku w a ciwo ci jest mo liwe dzi ki atrybutowi file zadania property: <property file="propfile.properties"/> To wystarczy, by ustawi wszystkie w a ciwo ci wymienione w pliku propfile.properties dla przestrzeni nazw, w której wyst puje zadanie property. U ywanie plików w a ciwo ci ma co najmniej dwie zalety. Po pierwsze, dzi ki niemu plik build.xml staje si krótszy i bardziej przejrzysty. Sk adnia XML jest do rozwlek a, wi c utrzymywanie w a ciwo ci w odr bnym pliku poprawia czytelno i u atwia zrozumienie samego pliku konsolidacyjnego. Po drugie, pliki w a ciwo ci wprowadzaj kolejny poziom abstrakcji, podobnie jak centralny plik lub obiekt konfiguracyjny dodaje poziom abstrakcji do aplikacji PHP. Aby wdro y aplikacj gdzie indziej, wystarczy dokona edycji pliku w a ciwo ci bez naruszania pliku build.xml. 320

20 Rozdzia 8. Wdra anie aplikacji Rozwijaj c t ide, mo emy zapewni obs ug ró nych rodowisk. Jak zobaczymy pó niej w naszym przyk adzie, mo emy po prostu wskaza Phing rodowisko, w jakim ma nast pi wdro- enie, a reszta ustawie b dzie realizowana poprzez do czenie pliku w a ciwo ci odpowiadaj cemu danemu rodowisku. Bardzo cz sto spotyka si pliki w a ciwo ci o nazwach w stylu dev.properties, staging.properties lub production.properties, odzwierciedlaj ce rodowisko, dla którego konfigurowany jest proces konsolidacji lub wdro enia. Typy Typy mog reprezentowa dane bardziej z o one ni w a ciwo ci. Na przyk ad typ mo e by odno nikiem do plików w danym katalogu, którego nazwa musi pasowa do podanego wyra- enia regularnego. Oto przyk ad typu fileset, który zawiera odno niki do wszystkich plików.properties w katalogu build projektu, poza plikiem o nazwie deprecated.properties. <fileset dir="${project.home}/build" > <include name="*.properties" /> <exclude name="deprecated.properties" /> </fileset> Oto wbudowane typy Phing: FileList uporz dkowana lista plików w systemie plików. Pliki nie musz istnie w systemie plików. FileSet nieuporz dkowana lista plików, które istniej w systemie plików. Path / ClassPath s u y do reprezentowania zbiorów cie ek do katalogów. Dok adny opis funkcjonalno ci i atrybutów tych typów mo na znale w dokumentacji narz dzia Phing. Filtry Jak sugeruje nazwa, filtry pozwalaj filtrowa i przekszta ca w jaki sposób zawarto pliku. Gdy pisa em t ksi k, by o dost pnych 14 g ównych filtrów, pozwalaj cych wykonywa tak ró norodne dzia ania, jak: rozwijanie w a ciwo ci w pliku, usuwanie znaków przej cia do nast pnego wiersza, komentarzy w wierszu lub komentarzy PHP, usuwanie lub dodawanie wierszy w pliku w zale no ci od ich lokalizacji w danym pliku lub usuwanie zawarto ci wiersza. Filtry musz by zawarte pomi dzy znacznikami otwieraj cym i zamykaj cym filterchain. Nasz plik konsolidacyjny w podsekcji mappers równie zawiera przyk ad zastosowania filtru. W dalszej cz ci rozdzia u zobaczymy jeszcze jeden przyk ad zastosowania filtrów w celu zmiany zawarto ci jednego lub kilku plików. 321

21 PHP 5. Narz dzia dla ekspertów Mapery O ile filtry operuj na zawarto ci pliku, mapery dzia aj podobnie, ale na nazwach plików. Obecnie istnieje w Phing pi podstawowych maperów, które pozwalaj wykonywa na cie kach i nazwach plików nast puj ce operacje: FlattenMapper usuwa katalogi z podanej cie ki, pozostawiaj c jedynie nazwy plików. GlobalMapper przemieszcza pliki, nie zmieniaj c ich nazw. IdentityMapper nie zmienia niczego. MergeMapper zmienia kilka plików tak, by mia y t sam nazw. RegexpMapper zmienia nazw plików, pos uguj c si wyra eniami regularnymi. Oto przyk ad zmiany nazw plików szablonów na nazwy rzeczywistych plików PHP z wykorzystaniem filtru expandproperties oraz zmiany nazw plików za pomoc filtru GlobalMapper: <copy todir="/includes"> <filterchain> <expandproperties /> </filterchain> <mapper type="glob" from="*.php.tpl" to="*.php"/> <fileset dir="templates"> <include name="*.php.tpl" /> </fileset> </copy> Jak zwykle, pe na lista wszystkich filtrów i maperów oraz dok adne opisy ich zastosowania i atrybutów s dost pne w doskona ej dokumentacji online narz dzia Phing. Znacznik project Najbardziej zewn trzny znacznik to znacznik <project>, który zawiera atrybuty definiuj ce nazw projektu, jego opis oraz nazw celu, jaki ma by wykonywany domy lnie. Jak si za chwil przekonamy, zawsze istnieje mo liwo nakazania Phing wykonania celu innego ni zdefiniowany tutaj domy lny. Poza tym Phing korzysta z nazwy projektu, przekazuj c informacje u ytkownikom. Wdra anie serwisu Spróbujmy teraz wykorzysta w a nie zdobyt wiedz na temat zada, celów, w a ciwo ci, typów, filtrów, maperów oraz projektów i utworzy plik konsolidacyjny, który p ynnie wdro y aktualizacj serwisu internetowego. Utworzymy tak e kilka szablonów i danych, które pozwol nam dowolnie aktualizowa i cofa aktualizacje bazy danych. Zamiast eksperymentowa z czyj stron, zdecydowa em si zautomatyzowa wdro enie mojej w asnej strony internetowej waferthin.com. Oto struktura katalogów wdro onego serwisu: 322

22 Rozdzia 8. Wdra anie aplikacji Separowanie zewn trznych zale no ci Sensowne wydaje si odseparowanie zewn trznych zale no ci, które nie rezyduj w naszym systemie kontroli wersji, od reszty projektu. S to zwykle pliki i katalogi, które niekoniecznie musz by aktualizowane za ka dym razem, gdy przeprowadzamy wdro enie. Separuj c te zale no ci, nie b dziemy musieli martwi si o to, e przypadkowo je nadpiszemy lub uszkodzimy. W przypadku mojej strony jest kilka katalogów oraz plików, które zosta y po prostu skopiowane na serwer podczas pierwotnej r cznej instalacji, takich jak Zend Library, Mantis (narz dzie do ledzenia problemów) i RoundCube (przegl darkowy czytnik i). Katalogi te b d musia y zosta albo przeniesione ze starej wersji serwisu do nowej, albo zast pione dowi zaniem symbolicznym. Z tego samego powodu katalog logs b dzie musia by przeniesiony poza katalog projektu. Po uko czeniu naszego skryptu konsolidacyjnego i udanym wdro eniu serwisu przyjrzymy si, jak zmieni a si jego struktura w porównaniu ze stanem sprzed wdro enia. 323

23 PHP 5. Narz dzia dla ekspertów Tworzenie skryptu konsolidacyjnego Zacznijmy od utworzenia prostego skryptu konsolidacyjnego. Na szcz cie cele dziel skrypt na atwiejsze do ogarni cia cz ci. B dziemy tworzy kolejno po jednym celu, do momentu gdy wszystkie elementy tej uk adanki b d gotowe i mo liwe stanie si wdro enie serwisu jednym poleceniem. rodowisko i w a ciwo ci Zwykle pracuj na lokalnej kopii projektu, ale na koniec zdalnie wdra am wersj testow i ostateczn. Tutaj ka dy programista mo e preferowa inny sposób pracy, ale niemal wszyscy spotkamy si z sytuacj, kiedy musimy wdro y t sam aplikacj w wielu ró nych rodowiskach i serwerach. Przyda oby si, aby skrypt Phing by na tyle elastyczny, by uwzgl dnia owe ró ne wymagania w sposób nieanga uj cy u ytkownika. Poniewa wi kszo, je eli nie wszystkie czynno ci, jakie trzeba wykona, jest przy ka dym wdro eniu taka sama, napiszemy skrypt pozwalaj cy wdra a aplikacj w ró nych rodowiskach poprzez prost zmian kilku w a ciwo ci, takich jak nazwa domeny, cie ka do projektu na serwerze, ustawienia bazy danych itp. Typowe rozwi zanie tego problemu polega na utworzeniu plików w a ciwo ci, które odpowiadaj ró nym rodowiskom, które chcemy obs u y. Nast pnie mo emy utworzy cele aduj ce odpowiednie pliki w a ciwo ci lub wr cz pytaj ce u ytkownika, z którego pliku w a- ciwo ci nale y skorzysta. Oto plik dev.properties, zawieraj cy ustawienia dla wdro enia wersji mojej strony w rodowisku programistycznym na moim lokalnym komputerze: # wdro enie site.fqdn=dev.waferthin.com site.fqdn.secure=dev.secure.waferthin.com site.home=/users/dirk/sites/${site.fqdn} site.root=/users/dirk/sites/${site.fqdn}/${site.fqdn} # system Subversion svn.bin=/usr/bin/svn svn.fqdn=svn svn.user=dirk svn.repo=/svn/ svn.proto= svn.project=waferthin.com/trunk svn.password=donttellanybody # ustawienia po czenia z baz i parametry uwierzytelniaj ce db.user=root db.password=itsasecret db.name=waferthin db.fqdn=localhost 324

24 Rozdzia 8. Wdra anie aplikacji db.port=3306 db.bin=/usr/local/mysql/bin/mysql db.backup.dir=${site.home}/backups # lokalizacja pliku dziennika aplikacji log=${site.home}/logs/waferthin.log # modu szablonów Smarty smarty.templates_dir=${site.root}/smarty/templates smarty.compile_dir=${site.root}/smarty/templates_c smarty.configs_dir=${site.root}/smarty/configs smarty.cache_dir=${site.root}/smarty/cache smarty.plugins_dir=${site.root}/smarty/plugins smarty.plugins2_dir=${site.root}/includes/libraries/smarty/plugins smarty.force_compile=true # zewn trzne narz dzia extern.apachectl=/usr/sbin/apachectl extern.sudo=/usr/bin/sudo extern.ln=/bin/ln extern.mysqldump=/usr/local/mysql/bin/mysqldump # biblioteki zend_dir=/usr/local/lib/php/zend Jak wida, plik sk ada si z sze ciu sekcji definiuj cych nast puj cy podzia logiczny: 1. W a ciwo ci z przedrostkiem site. odnosz si do lokalizacji na serwerze, w jakiej ma zosta wdro ony serwis. 2. W a ciwo ci z przedrostkiem svn. odnosz si do dost pu do repozytorium Subversion przechowuj cego kod ród owy. 3. W a ciwo ci z przedrostkiem db. odnosz si do parametrów po czenia i parametrów uwierzytelniaj cych umo liwiaj cych po czenie z baz danych. 4. W a ciwo ci z przedrostkiem smarty. odnosz si do konfiguracji modu u szablonów Smarty. 5. W a ciwo ci z przedrostkiem extern. odnosz si do lokalizacji zewn trznych plików wykonywalnych, wymaganych przez skrypt konsolidacyjny. 6. W a ciwo ci log i zend_dir s u do zachowania jeszcze innych zewn trznych zale no ci poprzez utworzenie dowi za symbolicznych (wi cej na ten temat w dalszej cz ci rozdzia u). Mam te podobne pliki dla rodowiska docelowego (prod.properties) oraz testowego (test.properties). Wszystkie trzy pliki znajduj si w tym samym katalogu co plik build.xml. Po zaimplementowaniu obs ugi plików w a ciwo ci i wielu ró nych rodowisk mo emy dodawa dowoln liczb rodowisk wdro eniowych poprzez utworzenie stosownych plików w a ciwo ci. 325

25 PHP 5. Narz dzia dla ekspertów Zacznijmy teraz od utworzenia pliku build.xml, który na razie inicjalizuje jedynie rodowisko: <?xml version="1.0"?> <project name="waferthin.com" description="realizuje utrzymanie i wdro enie serwisu waferthin.com." default="deploy"> <!-- Inicjalizuje datownik, który b dzie u ywany przy nadawaniu nazw ró nym plikom i katalogom. --> <tstamp/> <target name="deploy" depends="get-env,create-skeleton,svn-export, stamp-config,disp-maint,backup-db,deploy-db,publish-site" description="wdra a serwis na serwer WWW i wykonuje niezb dne zadania konsolidacyjne i aktualizacyjne."> </target> <target name="get-env" description="pobiera rodowisko, do jakiego ma nast pi wdro enie."> <!-- Czy rodowisko zosta o ju ustawione? --> <if> <not> <isset property="environment" /> </not> <then> <!-- Prosi u ytkownika o wybranie rodowiska z listy obs ugiwanych rodowisk. --> <input propertyname="environment" validargs="dev,test,prod" promptchar=":">podaj rodowisko </input> </then> </if> <!-- Sprawdza, czy istnieje plik w a ciwo ci dla danego rodowiska. --> <available file="${environment}.properties" property="env_prop_exists" type="file" /> <if> <equals arg1="${env_prop_exists}" arg2="true" /> <then> <!-- Odczytuje pliki w a ciwo ci. --> <property file="${environment}.properties"/> </then> <else> <!-- Przerywa konsolidacj i ukazuje komunikat dotycz cy b du. --> <fail message="nie znaleziono pliku w a ciwo ci dla wybranego rodowiska (${environment}.properties)" /> </else> </if> </target> 326

26 Rozdzia 8. Wdra anie aplikacji <target name="deploy-dev" description="wdra a serwis w rodowisku programowania."> <property name="environment" value="dev" override="true" /> <phingcall target="deploy" /> </target> <target name="deploy-prod" description="wdra a serwis w rodowisku docelowym."> <property name="environment" value="prod" override="true" /> <phingcall target="deploy" /> </target> <target name="deploy-test" description="wdra a serwis w rodowisku testowym."> <property name="environment" value="test" override="true" /> <phingcall target="deploy" /> </target> </project> Znacznik <project> zawiera opis celów pliku build.xml oraz identyfikuje cel deploy jako domy lny. Jedyn interesuj c rzecz zwi zan z celem deploy jest jego atrybut depends, który w tym przypadku informuje Phing, e wcze niej wykonany musi zosta cel get-env. Przyjrzyjmy si wi c celowi get-env, który jak na razie jest jedynym celem wykonuj cym jakie konkretne zadania. Oto, co si stanie, gdy uruchomimy wst pn wersj pliku build.xml z wiersza polece : W pliku wyst puj równie cele deploy-dev, deploy-test i deploy-prod. Ustawiaj one w a- ciwo definiuj c rodowisko na dev, prod lub test w zale no ci od tego, czy wdra amy aplikacj odpowiednio w rodowisku programowania, docelowym lub testowym, po czym wywo uj cel deploy. Dzi ki temu mo liwe jest wdra anie aplikacji w ka dym z tych rodowisk bez konieczno ci wpisywania jego nazwy r cznie. 327

27 PHP 5. Narz dzia dla ekspertów Szkielet katalogów Sposób, w jaki wdra amy nasz aplikacj, zak ada istnienie okre lonej struktury katalogów. Je eli wdra amy aplikacj po raz pierwszy, musimy utworzy katalogi, które b d potrzebne w nast pnych krokach. Je eli dokonujemy aktualizacji, wci musimy utworzy wszelkie katalogi, których wcze niej brakowa o. Oto cel, który zajmuje si tworzeniem katalogów: <!-- Tworzy katalogi; adne istniej ce katalogi nie zostan nadpisane. --> <target name="create-skeleton" description="tworzy podstawow struktur katalogów dla serwisu."> <mkdir dir="${site.home}" /> <mkdir dir="${site.home}/build" /> <mkdir dir="${site.home}/backups" /> <mkdir dir="${site.home}/logs" /> <mkdir dir="${site.home}/tmp" /> </target>... Zadanie mkdir tworzy katalog okre lony za pomoc atrybutu dir. Eksportowanie i wymeldowywanie z Subversion Teraz przysz a pora na pobranie kodu z systemu kontroli wersji. Jako e w ksi ce tej skupili- my si na Subversion jako przyk adzie takiego systemu, b dziemy tu trzyma si tego przyk adu. Je eli jednak nasz projekt rezyduje w CVS, Git, Perforce lub jakimkolwiek innym systemie, opisane tu kroki b d wygl da bardzo podobnie. Tak si sk ada, e Phing ma pewne wbudowane zadania opcjonalne, pozwalaj ce na interakcj z Subversion. Je eli jednak korzystamy z nieco mniej popularnego typu repozytorium, mo emy utworzy w asne zadanie Phing lub u y zadania ExecTask, które pozwala uruchamia pliki wykonywalne w wierszu polece. Oto fragment pliku build.xml definiuj cy cel svn-export:... <target name="svn-export" description="eksportuje pliki serwisu z Subversion do lokalnego katalogu docelowego."> <!-- Konstruuje poprawne URL dla Subversion --> <property name="svn.url" value="${svn.proto} ${svn.fqdn}${svn.repo}${svn.project}" override="true" /> <!-- Czy has o dost pu do Subversion zosta o podane w pliku w a ciwo ci? --> <if> <not> <isset property="svn.password" /> </not> 328

28 Rozdzia 8. Wdra anie aplikacji <then> <!-- Prosi u ytkownika o podanie has a dost pu do Subversion. --> <input propertyname="svn.password" promptchar=":">podaj has o dla u ytkownika ${svn.user}, aby pobra projekt ${svn.project} z repozytorium Subversion ${svn.fqdn}${svn.repo}</input> </then> </if> <!-- Wymeldowuje projekt do rodowiska programowania. --> <if> <equals arg1="${environment}" arg2="dev" /> <then> <echo>wymeldowywanie z svn zosta o rozpocz te...</echo> <svncheckout svnpath="${svn.bin}" repositoryurl="${svn.url}" todir="${site.root}.${dstamp}${tstamp}" username="${svn.user}" password="${svn.password}" /> </then> <!-- Eksportuje projekt na potrzeby wdro enia. --> <else> <echo>eksport svn zosta rozpocz ty...</echo> <svnexport svnpath="${svn.bin}" repositoryurl="${svn.url}" todir="${site.root}.${dstamp}${tstamp}" username="${svn.user}" password="${svn.password}" /> </else> </if> </target> Na pocz tku za pomoc zadania property konstruowany jest prawid owy ci g URL dla Subversion wskazuj cy nasz projekt, po czym zostaje on zapisany we w a ciwo ci svn.url. Nast pnie sprawdzamy, czy w a ciwo svn.password zosta a ustawiona. Dobra praktyka nakazuje nie wpisywa hase do plików w a ciwo ci, ale przerywa to pe n automatyzacj. Nasze rozwi zanie obs uguje obydwie mo liwo ci je eli nie podano w pliku warto ci svn.password, Phing poprosi u ytkownika za po rednictwem znacznika inputtask o r czne wpisanie has a. Je eli nie chcemy za ka dym razem wpisywa nazwy u ytkownika i has a SSH, zawsze mo emy zainstalowa swój publiczny klucz SHH na serwerze, na którym rezyduje repozytorium Subversion, i zmodyfikowa plik build.xml tak, by nie prosi o podanie parametrów uwierzytelniaj cych. Zastosowany sposób pobrania kodu z repozytorium zale y od tego, co mamy zamiar z nim zrobi. U yli my tutaj instrukcji warunkowej if-then-else, poniewa wymagane kroki s nieco inne w przypadku rodowiska programowania. Je eli pracujemy w rodowisku programowania, 329