Was ist Ihre bevorzugte PHP-Bereitstellungsstrategie? [geschlossen]

Ich beginne ein neues Projekt in PHP und würde gerne Feedback von anderen Entwicklern zu ihrer bevorzugten Strategie für die PHP-Bereitstellung erhalten. Ich würde die Dinge gerne ein wenig automatisieren, damit Änderungen, sobald sie festgeschrieben sind, schnell auf einen Entwicklungs- oder Produktionsserver migriert werden können.

Ich habe Erfahrung mit Bereitstellungen mit Capistrano mit Ruby sowie einigen grundlegenden Shell-Skripten.

Bevor ich alleine mit dem Kopf voran tauche, wäre es großartig zu hören, wie andere dies in ihren Projekten angegangen sind.

Weitere Informationen

Derzeit arbeiten Entwickler an lokalen Installationen der Site und übernehmen Änderungen an einem Subversion-Repository. Erste Bereitstellungen werden durchgeführt, indem eine getaggte Version aus svn exportiert und auf den Server hochgeladen wird.

Zusätzliche Änderungen werden normalerweise stückweise vorgenommen, indem geänderte Dateien manuell hochgeladen werden.

Für PHP sind SVN mit Phing- Build-Skripten der richtige Weg. Phing ähnelt ANT , ist jedoch in PHP geschrieben, was es PHP-Entwicklern erheblich erleichtert, Änderungen an ihren Anforderungen vorzunehmen.

Unsere Bereitstellungsroutine lautet wie folgt:

• Jeder entwickelt bei der Arbeit auf demselben lokalen Server, jeder Entwickler hat auch zu Hause eine Kasse auf seinem Computer.
• Commits lösen einen Post-Commit-Hook aus, der einen Staging-Server aktualisiert.
• Tests werden auf dem Staging-Server ausgeführt, wenn sie bestanden wurden - fahren Sie fort.
• Das Phing-Build-Skript wird ausgeführt:
• Schaltet den Produktionsserver aus und wechselt die Domäne auf eine Seite "Im Aufbau"
• Führt die SVN-Aktualisierung an der Produktionskasse aus
• Führt das Schema-Deltas-Skript aus
• Führt Tests durch
• Wenn Tests fehlschlagen, führen Sie ein Rollback-Skript aus
• Wenn die Tests erfolgreich sind, wird der Server zur Produktionskasse zurückgeleitet

Es gibt auch phpUnderControl , einen Continuous Integration Server. Ich fand es für Webprojekte nicht sehr nützlich, um ehrlich zu sein.

Ich stelle derzeit PHP mit Git bereit . Eine einfache Git-Push-Produktion ist alles, was benötigt wird, um meinen Produktionsserver mit der neuesten Kopie von Git zu aktualisieren. Es ist einfach und schnell, weil Git klug genug ist, nur die Unterschiede und nicht das gesamte Projekt erneut zu senden. Es hilft auch, eine redundante Kopie des Repositorys auf dem Webserver zu behalten, falls ein Hardwarefehler auf meiner Seite auftritt (obwohl ich aus Sicherheitsgründen auch auf GitHub drücke).

Wir verwenden Webistrano , ein Web-Frontend für Capistrano, und sind sehr zufrieden damit.

Webistrano ermöglicht mehrstufige Bereitstellungen in mehreren Umgebungen von SVN, GIT und anderen. Es verfügt über eine integrierte Rollback-Unterstützung, Unterstützung für separate Serverrollen wie Web, Datenbank, App usw. und wird parallel bereitgestellt. Sie können Konfigurationsparameter auf mehreren Ebenen überschreiben, z. B. pro Stufe, und die Ergebnisse jeder Bereitstellung protokollieren, optional per E-Mail.

Obwohl Capistrano und Webistrano Ruby-Anwendungen sind, ist die Syntax der Bereitstellungsrezepte für jeden PHP-Programmierer einfach und leistungsfähig genug, um sie zu verstehen. Ursprünglich wurde Capistrano für Ruby on Rails-Projekte entwickelt, kann aber problemlos PHP-Projekte aufnehmen.

Einmal konfiguriert, ist es sogar einfach genug, von Nicht-Programmierern verwendet zu werden, z. B. von Testern, die eine Staging-Version bereitstellen.

Um eine möglichst schnelle Bereitstellung zu gewährleisten, haben wir die Methode fast_remote_cache installiert , die einen SVN-Cache für Arbeitskopien auf dem Remoteserver aktualisiert und das Ergebnis dann fest verknüpft.

Ich verwende Apache Ant für die Bereitstellung auf verschiedenen Zielen (Entwickler, Qualitätssicherung und Live). Ant wurde für die Java-Bereitstellung entwickelt, bietet jedoch eine recht nützliche allgemeine Lösung für die Bereitstellung beliebiger Dateien.

Die Syntax der Datei build.xml ist recht einfach zu erlernen. Sie definieren verschiedene Ziele und deren Abhängigkeiten, die ausgeführt werden, wenn Sie das Programm ant in der Befehlszeile aufrufen.

Zum Beispiel habe ich Ziele für dev, QA und live, die jeweils vom cvsbuild-Ziel abhängen, das die neueste Head-Revision von unserem CVS-Server auscheckt, die entsprechenden Dateien in das Build-Verzeichnis kopiert (mithilfe des Dateigruppen-Tags) und dann Synchronisiert das Build-Verzeichnis mit dem entsprechenden Server. Es gibt ein paar Macken zu lernen, und die Lernkurve ist nicht ganz flach, aber ich mache es seit Jahren ohne Probleme so, also würde ich es für Ihre Situation empfehlen, obwohl ich neugierig bin, welche anderen Antworten ich habe werde auf diesem Thread sehen.

Ich mache Sachen manuell mit Git. Ein Repository für die Entwicklung, das git push --mirrorin ein öffentliches Repo umgewandelt wird, und der Live-Server ist ein drittes Repo, das daraus gezogen wird. Dieser Teil ist vermutlich der gleiche wie Ihr eigenes Setup.

Der große Unterschied besteht darin, dass ich für fast jede Änderung, an der ich arbeite, Zweige verwende (ich habe gerade ungefähr 5) und dazu neige, zwischen ihnen hin und her zu wechseln. Der Hauptzweig wird nicht direkt geändert, außer wenn andere Zweige zusammengeführt werden.

Ich führe den Live-Server direkt vom Hauptzweig aus aus. Wenn ich mit einem anderen Zweig fertig bin und bereit bin, ihn zusammenzuführen, schalte den Server für eine Weile auf diesen Zweig um. Wenn es kaputt geht, dauert es Sekunden, bis es wieder auf dem Master ist. Wenn es funktioniert, wird es mit dem Master zusammengeführt und der Live-Code wird aktualisiert. Ich nehme an, eine Analogie dazu in SVN wäre, zwei Arbeitskopien zu haben und über einen Symlink auf die Live-Kopie zu verweisen.

Ich weiß, dass Phing jetzt schon einige Male erwähnt wurde, aber ich hatte großes Glück mit phpUnderControl . Für uns wir

1. Überprüfen Sie einzelne Kopien von Zweigen auf lokalen Computern
2. Zweige werden getestet und dann in Trunk zusammengeführt
3. Commits to Trunk werden automatisch von phpUnderControl erstellt, führen Tests durch und erstellen die gesamte Dokumentation, wenden Datenbank-Deltas an
4. Trunk wird einer Qualitätsprüfung unterzogen und dann in unsere Stable-Niederlassung integriert
5. Auch hier erstellt phpUnderControl automatisch Stable, führt Tests durch und generiert eine Dokumentations- und Aktualisierungsdatenbank
6. Wenn wir bereit sind, in die Produktion zu wechseln, führen wir ein rsync-Skript aus, das die Produktion sichert, die Datenbank aktualisiert und dann die Dateien hochschiebt. Der Befehl rsync wird von Hand aufgerufen, damit wir sicherstellen, dass jemand die Promotion beobachtet.

Eine Alternative zu selbst erstellten Bereitstellungsskripten ist die Bereitstellung auf einer Plattform als Service, die einen Großteil dieser Arbeit für Sie abstrahiert. Ein PaaS bietet in der Regel ein eigenes Code-Bereitstellungstool sowie Skalierung, Fehlertoleranz (z. B. nicht ausfallen, wenn die Hardware ausfällt) und in der Regel ein hervorragendes Toolkit für Überwachung, Protokollprüfung usw. Es bietet auch den Vorteil der Bereitstellung auf einem bekanntermaßen gute Konfiguration, die im Laufe der Zeit auf dem neuesten Stand gehalten wird (ein Kopf weniger Kopfschmerzen für Sie).

Das PaaS, das ich empfehlen würde, ist dotCloud . Zusätzlich zu PHP ( siehe PHP-Schnellstart ) kann es auch MySQL, MongoDB und eine ganze Reihe zusätzlicher Dienste bereitstellen. Es hat auch nette Extras wie eine Bereitstellung ohne Ausfallzeiten, sofortiges Rollback, volle Unterstützung für SSL und Websocket usw. Und es gibt eine kostenlose Stufe, die immer schön ist :)

Natürlich bin ich etwas voreingenommen, da ich dort arbeite! Weitere Optionen, die neben dotCloud einen Besuch wert sind, sind Pagodabox und Orchestra (jetzt Teil von Engine Yard).

Hoffe das hilft!

Solomon

Dass Sie automatisch und blind Änderungen von einem Repository zu Produktionsservern vornehmen, klingt gefährlich. Was ist, wenn Ihr festgeschriebener Code einen Regressionsfehler enthält, sodass Ihre Produktionsanwendung fehlerhaft wird?

Wenn Sie jedoch ein Continuous Integration-System für PHP wünschen, ist Phing wahrscheinlich die beste Wahl für PHP. Ich habe es jedoch nicht selbst getestet, da ich die manuelle Art von zB scp stopfe.

Ich bin viel zu spät zur Party, aber ich dachte, ich würde unsere Methoden teilen. Wir verwenden Phing mit Phingistrano , das Phing Capistrano-ähnliche Funktionen über vorgefertigte Build-Dateien bietet. Es ist sehr cool, funktioniert aber nur, wenn Sie momentan Git verwenden.

Ich habe eine Arbeitskopie eines SVN-Release-Zweigs auf dem Server. Das Aktualisieren der Site (wenn keine Schemaänderungen vorliegen) ist so einfach wie das Ausgeben eines SVN-Aktualisierungsbefehls. Ich muss die Seite nicht einmal offline schalten.

Phing ist wahrscheinlich die beste Wahl, wenn Sie den Schmerz von XML-Konfigurationsdateien ertragen können. Das Symfony-Framework verfügt über einen eigenen Rake-Port (Pake), der recht gut funktioniert, aber ziemlich eng mit dem Rest von Symfony verbunden ist (obwohl Sie sie wahrscheinlich trennen könnten).

Eine andere Möglichkeit ist die Verwendung von Capistrano. Offensichtlich lässt es sich nicht so gut in PHP integrieren wie in Ruby, aber Sie können es trotzdem für viele Dinge verwenden.

Schließlich können Sie immer Shell-Skripte schreiben. Bisher habe ich das getan.

http://controltier.org/wiki/Main_Page

Wir werden es für die Bereitstellung und Wartung mehrerer Server verwenden.

Ein Jahr zu spät, aber ... In meinem Fall erfolgt die Bereitstellung nicht automatisch. Ich finde es gefährlich, Code bereitzustellen und Datenbankmigrationsskripte automatisch auszuführen.

Stattdessen werden Subversion-Hooks nur zur Bereitstellung auf einem Test- / Staging-Server verwendet. Code wird am Ende einer Iteration für die Produktion bereitgestellt, nachdem Tests ausgeführt und sichergestellt wurden, dass alles funktioniert. Für die Bereitstellung selbst verwende ich ein benutzerdefiniertes Makefile, das rsync zum Übertragen von Dateien verwendet. Das Makefile kann auch die Migrationsskripte auf dem Remote-Server ausführen, Web- und Datenbankserver anhalten / fortsetzen.

Bei meiner Arbeit haben ich und mein Team einen Phing-orientierten Ersatz für die Bereitstellung von Capistrano entwickelt. Außerdem haben wir einige der in Phing verfügbaren Extras wie PHPUnit-Tests, PHPCs und PHPDocumentor integriert. Wir haben es zu einem Git-Repo gemacht, das einem Projekt als Submodul in Git hinzugefügt werden kann und sehr gut funktioniert. Ich habe es an eine Handvoll Projekte angehängt und es ist modular genug, damit es problemlos mit jedem Projekt in einer unserer verschiedenen Umgebungen (Staging, Test, Produktion usw.) funktioniert.

Mit den Phing-Build-Skripten können Sie sie manuell über die Befehlszeile ausführen, und ich hatte auch Erfolg bei der Automatisierung der Build- / Bereitstellungsroutinen mit Hudson und jetzt Jenkins ci.

Ich kann jetzt keine Links posten, da das Repo noch nicht öffentlich ist, aber mir wurde gesagt, dass wir es manchmal bald als Open Source veröffentlichen werden. Bitte zögern Sie nicht, mich zu kontaktieren, wenn Sie interessiert sind oder haben Fragen zur Automatisierung Ihrer Bereitstellung mit Phing und Git.

Ich denke, der SVN-Bereitstellungsweg ist nicht sehr gut. Weil:

Sie müssen den SVN-Zugang für die ganze Welt öffnen

habe viele .svn in den Produktionswebservern

Ich denke, Phing, um einen Zweig zu produzieren + alle js / css zu kombinieren + Stage-Konfiguration zu ersetzen + SSH-Upload auf alle WWW-Server ist besser.

ssh bis 10 www server und svn up ist auch problem.