Jaka jest Twoja preferowana strategia wdrażania PHP? [Zamknięte]

Rozpoczynam nowy projekt w PHP i chciałbym uzyskać opinie od innych programistów na temat ich preferowanej strategii wdrażania PHP. Chciałbym trochę zautomatyzować pewne rzeczy, aby po wprowadzeniu zmian można je było szybko przenieść na serwer deweloperski lub produkcyjny.

Mam doświadczenie z wdrożeniami przy użyciu Capistrano z Ruby, a także z podstawowymi skryptami powłoki.

Zanim zacznę samodzielnie nurkować, byłoby wspaniale usłyszeć, jak inni podeszli do tego w swoich projektach.

Dalsza informacja

Obecnie programiści pracują nad lokalnymi instalacjami serwisu i zatwierdzają zmiany w repozytorium subversion. Wstępne wdrożenia są wykonywane przez wyeksportowanie oznaczonego wydania ze svn i przesłanie go na serwer.

Dodatkowe zmiany są zwykle wprowadzane fragmentarycznie, ręcznie przesyłając zmienione pliki.

W przypadku PHP najlepszym rozwiązaniem jest SVN ze skryptami kompilacji Phing . Phing jest podobny do ANT, ale jest napisany w PHP, co znacznie ułatwia programistom PHP modyfikowanie ich zgodnie z ich potrzebami.

Nasza procedura wdrażania wygląda następująco:

• Każdy programista tworzy w pracy na tym samym serwerze lokalnym, każdy programista ma również kasę na swoim komputerze w domu.
• Zatwierdzenia wyzwalają punkt zaczepienia po zatwierdzeniu, który aktualizuje serwer pomostowy.
• Testy są uruchamiane na serwerze pomostowym, jeśli zakończą się pomyślnie - kontynuuj.
• Uruchomiono skrypt kompilacji phing:
• Wyłącza serwer produkcyjny, przełączając domenę na stronę „W budowie”
• Uruchamia aktualizację SVN przy kasie produkcji
• Uruchamia skrypt delt schematu
• Przeprowadza testy
• Jeśli testy zakończą się niepowodzeniem - uruchom skrypt wycofywania
• Jeśli testy zakończą się pomyślnie, serwer kieruje z powrotem do realizacji zamówienia

Istnieje również phpUnderControl , który jest serwerem ciągłej integracji. Szczerze mówiąc, nie uważałem tego za przydatne w projektach internetowych.

Obecnie wdrażam PHP przy użyciu Git . Prosta produkcja git push to wszystko, czego potrzeba, aby zaktualizować mój serwer produkcyjny o najnowszą kopię z Git. Jest to łatwe i szybkie, ponieważ Git jest wystarczająco inteligentny, aby wysyłać tylko różnice, a nie cały projekt od nowa. Pomaga również w utrzymaniu nadmiarowej kopii repozytorium na serwerze WWW w przypadku awarii sprzętu po mojej stronie (choć dla bezpieczeństwa również wysyłam do GitHub).

Używamy Webistrano , frontendu internetowego dla Capistrano i jesteśmy z niego bardzo zadowoleni.

Webistrano umożliwia wieloetapowe, wielośrodowiskowe wdrożenia z SVN, GIT i innych. Ma wbudowaną obsługę wycofywania, obsługę oddzielnych ról serwera, takich jak WWW, baza danych, aplikacja itp., I wdraża się równolegle. Umożliwia zastąpienie parametrów konfiguracyjnych na wielu poziomach, na przykład na etapie, i rejestruje wyniki każdego wdrożenia, opcjonalnie wysyłając je pocztą.

Mimo że Capistrano i Webistrano są aplikacjami Ruby, składnia „recept” wdrożeniowych jest łatwa i wystarczająco rozbudowana, aby każdy programista PHP mógł je zrozumieć. Pierwotnie Capistrano został zbudowany dla projektów Ruby on Rails, ale z łatwością obsługuje projekty PHP.

Po skonfigurowaniu jest nawet wystarczająco łatwy do wykorzystania przez osoby nie będące programistami, na przykład testerzy wdrażający wersję przejściową.

Aby zapewnić najszybsze możliwe wdrożenie, zainstalowaliśmy metodę fast_remote_cache , która aktualizuje pamięć podręczną kopii roboczych svn na zdalnym serwerze, a następnie łączy wynik.

Używam Apache Ant do wdrażania na różne cele (dev, QA i live). Ant jest przeznaczony do wdrażania w Javie, ale zapewnia całkiem przydatne rozwiązanie do wdrażania dowolnych plików.

Składnia pliku build.xml jest dość łatwa do nauczenia - definiujesz różne cele i ich zależności, które są uruchamiane, gdy wywołujesz program Ant w wierszu poleceń.

Na przykład, mam cele dla dev, QA i live, z których każdy zależy od celu cvsbuild, który pobiera najnowszą wersję head z naszego serwera CVS, kopiuje odpowiednie pliki do katalogu kompilacji (używając znacznika zestawu plików), a następnie rsynchronizuje katalog kompilacji z odpowiednim serwerem. Jest kilka dziwactw do nauczenia się, a krzywa uczenia się nie jest całkowicie płaska, ale robię to w ten sposób od lat bez żadnych problemów, więc polecam to w twojej sytuacji, chociaż jestem ciekawy, jakie inne odpowiedzi. Zobaczę w tym wątku.

Robię rzeczy ręcznie za pomocą Gita. Jedno repozytorium do programowania, które jest git push --mirrorprzenoszone do repozytorium publicznego, a serwer na żywo jest trzecim repozytorium, które jest z niego pobierane. Przypuszczam, że ta część jest taka sama jak twoja własna konfiguracja.

Duża różnica polega na tym, że używam gałęzi do prawie każdej zmiany, nad którą pracuję (mam teraz około 5) i mam tendencję do przewracania się między nimi. Gałąź główna nie jest zmieniana bezpośrednio, z wyjątkiem scalania innych gałęzi.

Uruchamiam serwer na żywo bezpośrednio z gałęzi głównej, a kiedy skończę z inną gałęzią i jestem gotowy do jej scalenia, przełączam serwer na tę gałąź na chwilę. Jeśli się zepsuje, przywrócenie go do stanu głównego zajmie kilka sekund. Jeśli zadziała, zostanie scalony z głównym, a kod na żywo zostanie zaktualizowany. Przypuszczam, że analogią do tego w SVN byłoby posiadanie dwóch kopii roboczych i wskazywanie kopii aktywnej za pośrednictwem łącza symbolicznego.

Wiem, że Phing był już wspominany kilka razy, ale miałem z tym wielkie szczęście phpUnderControl . Dla nas my

1. Sprawdź poszczególne kopie oddziałów na lokalne maszyny
2. Gałęzie są testowane, a następnie łączone w Trunk
3. Zatwierdzenia do Trunk są automatycznie budowane przez phpUnderControl, uruchamia testy i buduje całą dokumentację, stosuje delty bazy danych
4. Trunk przechodzi testy jakości, a następnie zostaje włączony do naszej gałęzi Stable
5. Ponownie phpUnderControl automatycznie buduje stabilną, uruchamia testy, generuje dokumentację i aktualizuje bazę danych
6. Kiedy jesteśmy gotowi do przejścia do produkcji, uruchamiamy skrypt rsync, który tworzy kopię zapasową produkcji, aktualizuje bazę danych, a następnie wypycha pliki w górę. Polecenie rsync jest wywoływane ręcznie, aby mieć pewność, że ktoś obserwuje promocję.

Alternatywą dla samodzielnie wykonanych skryptów wdrożeniowych jest wdrożenie na platformie jako usłudze, która odciąża wiele pracy za Ciebie. PaaS zazwyczaj oferuje własne narzędzie do wdrażania kodu, a także skalowanie, odporność na awarie (np. Brak awarii w przypadku awarii sprzętu) i zwykle świetny zestaw narzędzi do monitorowania, sprawdzania dzienników itp. Zaletą wdrożenia w znana dobra konfiguracja, która będzie aktualizowana w miarę upływu czasu (o jeden ból głowy mniej).

PaaS, który poleciłbym, to dotCloud , oprócz PHP ( zobacz krótki przewodnik po PHP ), może on również wdrożyć MySQL, MongoDB i całą gamę dodatkowych usług. Ma również fajne dodatki, takie jak wdrażanie zerowych przestojów, natychmiastowe wycofywanie, pełne wsparcie dla SSL i Websocket itp. Jest też bezpłatna warstwa, która zawsze jest fajna :)

Oczywiście jestem nieco stronniczy, ponieważ tam pracuję! Inne opcje, które warto sprawdzić oprócz dotCloud, to Pagodabox i Orchestra (obecnie część Engine Yard).

Mam nadzieję że to pomoże!

Salomona

To, że automatycznie i ślepo przenosisz zmiany z repozytorium na serwery produkcyjne, brzmi niebezpiecznie. Co się stanie, jeśli popełniony kod zawiera błąd regresji, więc aplikacja produkcyjna staje się wadliwa?

Ale jeśli chcesz mieć system ciągłej integracji dla PHP, myślę, że Phing jest najlepszym wyborem dla PHP. Sam tego jednak nie testowałem, bo robię rzeczy manualnie np. Scp.

Spóźniłem się na imprezę, ale pomyślałem, że podzielę się naszymi metodami. Używamy Phing z Phingistrano , który zapewnia funkcjonalność podobną do Capistrano do Phing poprzez gotowe pliki kompilacji. To jest bardzo fajne, ale działa tylko wtedy, gdy używasz Git w tej chwili.

Mam działającą kopię gałęzi wydania SVN na serwerze. Aktualizacja witryny (gdy nie ma zmian schematu) jest tak prosta, jak wydanie polecenia aktualizacji SVN. Nie muszę nawet przełączać witryny do trybu offline.

Phing jest prawdopodobnie najlepszym rozwiązaniem, jeśli możesz znieść ból związany z plikami konfiguracyjnymi xml. Framework Symfony ma swój własny port rake (pake), który działa całkiem nieźle, ale jest raczej ściśle powiązany z resztą Symfony (chociaż prawdopodobnie można by je oddzielić).

Inną opcją jest użycie Capistrano. Oczywiście nie integruje się tak dobrze z PHP, jak z Rubim, ale nadal możesz go używać do wielu rzeczy.

Wreszcie, zawsze możesz pisać skrypty powłoki. Jak dotąd to właśnie zrobiłem.

http://controltier.org/wiki/Main_Page

będziemy go używać do wdrażania i konserwacji na wielu serwerach.

Rok spóźnienia, ale ... W moim przypadku wdrożenie nie jest automatyczne. Uważam, że automatyczne wdrażanie kodu i uruchamianie skryptów migracji baz danych jest niebezpieczne.

Zamiast tego, punkty zaczepienia subversion są używane do wdrażania tylko na serwerze testowym / pomostowym. Kod jest wdrażany do produkcji pod koniec iteracji, po przeprowadzeniu testów i upewnieniu się, że wszystko będzie działać. Do samego wdrożenia używam niestandardowego pliku Makefile, który używa rsync do przesyłania plików. Makefile może również uruchamiać skrypty migracji na serwerze zdalnym, wstrzymywać / wznawiać serwery WWW i bazy danych.

W mojej pracy ja i mój zespół opracowaliśmy zorientowany na phing zamiennik dla wdrożenia capistrano, a także włączyliśmy niektóre z dodatków dostępnych w phing, takich jak testowanie PHPUnit, phpcs i PHPDocumentor. Zrobiliśmy to repozytorium git, które można dodać do projektu jako moduł podrzędny w git i działa bardzo dobrze. Dołączyłem go do kilku projektów i jest na tyle modułowy, że łatwo jest go uruchomić z dowolnym projektem na dowolnym z naszych kilku środowisk (etapowa, testowa, produkcyjna itp.).

Dzięki skryptom kompilacji phing można uruchamiać je ręcznie z wiersza poleceń. Udało mi się również zautomatyzować procedury budowania / wdrażania za pomocą Hudson, a teraz Jenkins ci.

Nie mogę teraz publikować żadnych linków, ponieważ repozytorium nie jest jeszcze publiczne, ale powiedziano mi, że wkrótce będziemy go otwierać, więc proszę o kontakt, jeśli jesteś zainteresowany lub jeśli masz wszelkie pytania dotyczące automatyzacji wdrażania za pomocą phing i git.

Wydaje mi się, że sposób wdrażania SVN nie jest zbyt dobry. Ponieważ:

Musisz otworzyć dostęp do SVN dla całego świata

mają wiele plików .svn na produkcyjnych serwerach WWW

Myślę, że Phing w celu stworzenia gałęzi + połączenie wszystkich js / css + zastąpienie konfiguracji etapu + przesłanie ssh na wszystkie serwery www jest lepszym sposobem.

ssh do serwera www 10 i svn up to również problem.