Jaka jest Twoja preferowana strategia wdrażania php? [zamknięte]

Obecnie wdrażam PHP używając Git . Prosta produkcja git push to wszystko, co jest potrzebne, 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 diffy, a nie cały projekt od nowa. Pomaga również utrzymać redundantną kopię repozytorium na serwerze WWW w przypadku awarii sprzętu po mojej stronie (choć również naciskam na GitHub, aby być bezpiecznym).

Używamy webistrano, nakładki internetowej dla Capistrano i jesteśmy z niej bardzo zadowoleni.

Webistrano pozwala na wielostopniowe, wielośrodowiskowe wdrożenia z SVN, GIT i innych. Posiada wbudowaną obsługę rollback, wsparcie dla oddzielnych ról serwera, takich jak web, db, app, itp. i równolegle. Pozwala to na nadpisanie parametrów konfiguracyjnych na wielu poziomach, takich jak na stage, i rejestruje wyniki każdego wdrożenia, opcjonalnie wysyłając je.

Mimo że Capistrano i Webistrano to Aplikacje Ruby, składnia "receptur" wdrożenia jest łatwa i wystarczająco potężna, aby zrozumieć każdy programista PHP. Pierwotnie Capistrano został zbudowany dla projektów Ruby on Rails, ale łatwo mieści projekty PHP.

Po skonfigurowaniu jest nawet wystarczająco łatwy do użycia przez nie-programistów, takich jak testerzy wdrażający wersję testową.

Aby zapewnić jak najszybsze wdrożenie zainstalowaliśmy metodę fast_remote_cache, która aktualizuje svn praca-kopiowanie pamięci podręcznej na zdalnym serwerze, a następnie hardlinks wynik.

Używam Apache Ant do wdrażania do różnych celów(dev, QA i live). Ant jest przeznaczony do pracy dla wdrażania Javy, ale zapewnia całkiem przydatne ogólne rozwiązanie dla wdrażania dowolnych plików.

Składnia kompilacji.plik xml jest dość łatwy do nauczenia się-definiujesz różne cele i ich zależności, które uruchamiasz podczas wywoływania programu ant z linii poleceń.

Na przykład, mam cele dla dev, QA i live, z których każdy zależy od cvsbuild target, który sprawdza najnowszą wersję head z naszego serwera CVS, kopiuje odpowiednie pliki do katalogu kompilacji( używając tagu zestawu plików), a następnie rsyncs katalogu kompilacji do odpowiedniego serwera. 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 problemów, więc polecam to dla twojej sytuacji, choć jestem ciekaw, jakie inne odpowiedzi zobaczę w tym wątku.

Robię rzeczy ręcznie używając Gita. Jedno repozytorium dla deweloperów, które dostaje git push --mirror'ed do publicznego repo, a serwer na żywo jest trzecim repo pobranym z tego. Ta część, jak sądzę, 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 obracania się między nimi. Gałąź master nie jest zmieniana bezpośrednio z wyjątkiem scalania innych gałęzi.

Uruchamiam serwer live bezpośrednio z gałęzi master, a kiedy skończę z inną gałęzią i będę gotowy do scalenia, Przerzuć serwer do tej gałęzi na chwilę. Jeśli się zepsuje, oddanie go z powrotem do mistrza zajmuje kilka sekund. Jeśli to zadziała, zostanie scalony w master, a aktywny Kod zostanie zaktualizowany. Przypuszczam, że analogią tego w SVN byłoby posiadanie dwóch kopii roboczych i wskazywanie na live przez dowiązanie symboliczne.

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

1. Sprawdź pojedyncze kopie oddziałów do lokalnych maszyn
2. gałęzie są testowane, a następnie łączone w pień
3. commity do Trunka są automatycznie budowane przez phpUnderControl, uruchamiają testy i budują całą dokumentację, stosują delty baz danych
[7]}Trunk przechodzi testy jakości, a następnie łączy się z naszą stajnią branch
4. ponownie phpUnderControl automatycznie buduje stabilne, uruchamia testy i generuje dokumentację i aktualizuje bazę danych
5. Kiedy jesteśmy gotowi do uruchomienia produkcji uruchamiamy skrypt rsync, który tworzy kopie zapasowe produkcji, aktualizuje bazę danych, a następnie wypycha pliki w górę. Polecenie rsync jest wywoływane ręcznie, dzięki czemu upewniamy się, że ktoś obserwuje promocję.

Alternatywą dla domowych skryptów wdrożeniowych jest wdrożenie do platformy jako usługi, która usuwa wiele z tej pracy dla Ciebie. PaaS zazwyczaj oferuje własne narzędzie do wdrażania kodu, a także skalowanie, tolerancję błędów(np. nie schodzi, gdy sprzęt zawiedzie), a zazwyczaj świetny zestaw narzędzi do monitorowania, sprawdzania dziennika itp. Jest również korzyść z wdrożenia do znanej dobrej konfiguracji, która będzie aktualizowana w czasie (jeden ból głowy mniej dla Ciebie).

PaaS Polecam jest dotCloud , oprócz PHP (Zobacz ich PHP quickstart) może również wdrożyć MySQL, MongoDB i całą masę dodatkowych usług. Ma również fajne gadżety, takie jak wdrażanie bez przestojów, natychmiastowe wycofywanie, pełne wsparcie dla SSL i websocket itp. I jest darmowy poziom, który jest zawsze miły:)

Oczywiście, że jestem trochę stronniczy, odkąd tam pracuję! Inne opcje warte sprawdzenia oprócz dotCloud to Pagodabox i Orchestra (obecnie część Maszynownia).

Mam nadzieję, że to pomoże!

Salomon

To, że automatycznie i ślepo przyjmujesz zmiany z repozytorium na serwery produkcyjne, brzmi niebezpiecznie. Co zrobić, jeśli twój zatwierdzony kod zawiera błąd regresji, więc Twoja aplikacja produkcyjna staje się glitchy?

Ale, jeśli chcesz System ciągłej integracji dla PHP, myślę, że Phing jest najlepszym wyborem dla PHP. Nie testowałem tego osobiście, ponieważ robię rzeczy w sposób manualny np. scp.

Jestem spóźniona na imprezę, ale pomyślałam, że podzielę się naszymi metodami. Używamy Phing z Phingistrano, który zapewnia Phingowi funkcjonalność podobną do Capistrano za pomocą wstępnie zbudowanych plików. Jest to bardzo fajne, ale działa tylko wtedy, gdy używasz Gita w tej chwili.

Mam roboczą kopię gałęzi wydania SVN na serwerze. Aktualizacja witryny (gdy nie ma zmian w schemacie) jest tak prosta, jak wydanie polecenia aktualizacji SVN. Nie muszę nawet wyłączać strony.

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

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. So far, to właśnie zrobiłem.

Http://controltier.org/wiki/Main_Page

Będziemy go używać do wdrażania i konserwacji wielu serwerów.

Rok spóźniony, ale... W moim przypadku rozmieszczenie nie jest automatyczne. Uważam za niebezpieczne wdrażanie kodu i automatyczne uruchamianie skryptów migracji bazy danych.

Zamiast tego Hooki subversion są używane do wdrażania tylko do serwera testing/staging. Kod jest wdrażany do produkcji pod koniec iteracji, po uruchomieniu 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. Plik Makefile może również uruchomić migrację Skrypty na serwerze zdalnym, wstrzymywanie / wznawianie serwerów WWW i baz danych.

W mojej pracy ja i mój zespół opracowaliśmy zamiennik Phing zorientowany na wdrożenie capistrano, a także wprowadziliśmy niektóre z gadżetów dostępnych w phing, takich jak PHPUnit testing, phpcs i PHPDocumentor. Zrobiliśmy z niego repo git, które można dodać do projektu jako podmoduł w git i działa bardzo dobrze. Dodałem go do kilku projektów i jest na tyle modułowy, że łatwo jest go uruchomić z dowolnym projektem w dowolnym z naszych kilku środowisk (staging, testing, produkcji itp...).

Ze skryptami Phing build można je uruchamiać ręcznie z linii poleceń, a ja również odniosłem sukces automatyzując procedury build/deploy za pomocą Hudsona, a teraz Jenkinsa ci.

Nie mogę teraz publikować żadnych linków, ponieważ repo nie jest jeszcze publiczne, ale powiedziano mi, że wkrótce go otworzymy, więc proszę, skontaktuj się ze mną, jeśli jesteś zainteresowany lub jeśli masz jakieś pytania dotyczące automatyzacji wdrożenia za pomocą phing i git.

Domyślam się, że SVN deploy way nie jest zbyt dobry. Ponieważ:

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

Mają wiele .svn w produkcji serwerów WWW

Myślę, że Phing do produkcji gałęzi + połączyć wszystkie JS / css + zastąp stage config + SSH upload na wszystkie serwery www jest lepszy sposób.

SSH do 10 serwer www i svn up to też problem.