Was ist Ihre bevorzugte PHP-Bereitstellungsstrategie? [closed]

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 nach dem Festschreiben schnell auf einen Entwicklungs- oder Produktionsserver migriert werden können.

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

Bevor ich mich alleine kopfüber stürze, wäre es toll zu hören, wie andere dies in ihren Projekten angegangen sind.

Weitere Informationen

Derzeit arbeiten Entwickler an lokalen Installationen der Site und übertragen Änderungen an ein Subversion-Repository. Anfängliche Bereitstellungen werden vorgenommen, indem eine gekennzeichnete Version aus svn exportiert und auf den Server hochgeladen wird.

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

Für PHP, SVN mit Phing Build-Skripte sind der richtige Weg. Phing ist ähnlich wie AMEISE sondern ist in PHP geschrieben, was es für PHP-Entwickler viel einfacher macht, sie an ihre Bedürfnisse anzupassen.

Unsere Bereitstellungsroutine sieht wie folgt aus:

• Jeder entwickelt auf dem gleichen lokalen Server bei der Arbeit, jeder Entwickler hat auch einen Checkout auf seinem Rechner zu Hause.
• Commits lösen einen Post-Commit-Hook aus, der einen Staging-Server aktualisiert.
• Tests werden auf dem Staging-Server ausgeführt, wenn sie bestanden werden – fahren Sie fort.
• Das Phing-Build-Skript wird ausgeführt:
• Fährt den Produktionsserver herunter und schaltet die Domain auf eine „Im Aufbau“-Seite um
• Führt das SVN-Update beim Produktions-Checkout aus
• Führt das Schema-Deltas-Skript aus
• Führt Tests durch
• Wenn die Tests fehlschlagen, führen Sie das Rollback-Skript aus
• Wenn die Tests bestanden werden, leitet der Server zurück zum Produktions-Checkout

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

Ich stelle derzeit PHP mit Git bereit. Eine einfache Git-Push-Produktion ist alles, was erforderlich ist, um meinen Produktionsserver mit der neuesten Kopie von Git zu aktualisieren. Es ist einfach und schnell, weil Git schlau genug ist, nur die Diffs und nicht das ganze Projekt noch einmal zu senden. Es hilft auch, eine redundante Kopie des Repositorys auf dem Webserver zu behalten, falls auf meiner Seite ein Hardwarefehler auftritt (obwohl ich zur Sicherheit auch auf GitHub pushe).

Wir gebrauchen Webistranoein 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, DB, App usw. und wird parallel bereitgestellt. Es ermöglicht Ihnen, Konfigurationsparameter auf mehreren Ebenen zu überschreiben, z. B. pro Phase, und protokolliert die Ergebnisse jeder Bereitstellung, optional per E-Mail.

Obwohl Capistrano und Webistrano Ruby-Anwendungen sind, ist die Syntax der „Rezepte“ für die Bereitstellung einfach und leistungsfähig genug, um sie für jeden PHP-Programmierer zu verstehen. Ursprünglich wurde Capistrano für Ruby on Rails-Projekte gebaut, passt aber problemlos zu PHP-Projekten.

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

Um die schnellstmögliche Bereitstellung zu ermöglichen, haben wir die installiert fast_remote_cache -Methode, die einen svn-Arbeitskopie-Cache auf dem entfernten Server aktualisiert und dann das Ergebnis hartverlinkt.

ich benutze Apache-Ameise für die Bereitstellung auf verschiedenen Zielen (Entwicklung, QA und Live). Ant ist für die Java-Bereitstellung konzipiert, bietet jedoch eine ziemlich nützliche allgemeine Falllösung für die Bereitstellung beliebiger Dateien.

Die Syntax der build.xml-Datei ist ziemlich einfach zu erlernen – Sie definieren verschiedene Ziele und ihre Abhängigkeiten, die ausgeführt werden, wenn Sie das Ant-Programm auf 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 (unter Verwendung des fileset-Tags) und dann rsyncs 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 auf diese Weise, also würde ich es für Ihre Situation empfehlen, obwohl ich gespannt bin, welche anderen Antworten ich habe werde in diesem Thread sehen.

Ich mache Dinge manuell mit Git. Ein Repository für die Entwicklung, das bekommt git push --mirror‘ed zu einem öffentlichen Repo, und der Live-Server ist ein drittes Repo, das daraus gezogen wird. Ich nehme an, dieser Teil ist derselbe wie Ihr eigenes Setup.

Der große Unterschied besteht darin, dass ich Zweige für fast jede Änderung verwende, an der ich arbeite (ich habe im Moment ungefähr 5) und dazu neige, zwischen ihnen hin und her zu wechseln. Der Master-Zweig wird nicht direkt geändert, außer zum Zusammenführen anderer Zweige.

Ich betreibe den Live-Server direkt vom Master-Branch, und wenn ich mit einem anderen Branch fertig bin und bereit bin, ihn zusammenzuführen, kippe den Server für eine Weile auf diesen Branch um. Wenn es kaputt geht, dauert es Sekunden, es wieder an den Master zu senden. Wenn es funktioniert, wird es in den Master gemergt 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 weiss Phing wurde jetzt schon ein paar Mal erwähnt, aber ich hatte großes Glück damit phpUnderControl. Für uns wir

1. Checken Sie einzelne Kopien von Branches auf lokalen Rechnern aus
2. Zweige werden getestet und dann in Trunk zusammengeführt
3. Commits zu Trunk werden automatisch von phpUnderControl erstellt, führt Tests durch und erstellt die gesamte Dokumentation, wendet Datenbank-Deltas an
4. Trunk wird Qualitätstests unterzogen und dann mit unserem Stable-Zweig zusammengeführt
5. Auch hier erstellt phpUnderControl automatisch Stable, führt Tests durch und generiert Dokumentation und aktualisiert die Datenbank
6. Wenn wir bereit sind, in die Produktion zu pushen, führen wir ein rsync-Skript aus, das die Produktion sichert, die Datenbank aktualisiert und dann die Dateien hochschiebt. Der rsync-Befehl wird von Hand aufgerufen, damit wir sicherstellen können, dass jemand die Werbeaktion beobachtet.

Eine Alternative zu hausgemachten Bereitstellungsskripten ist die Bereitstellung auf einer Plattform als Service, die Ihnen einen Großteil dieser Arbeit abnimmt. Ein PaaS bietet in der Regel sein eigenes Code-Bereitstellungstool sowie Skalierung, Fehlertoleranz (z. B. keine Ausfälle bei Hardwarefehlern) und normalerweise ein großartiges Toolkit für Überwachung, Protokollprüfung usw. Es gibt auch den Vorteil der Bereitstellung auf a bekannte gute Konfiguration, die im Laufe der Zeit auf dem neuesten Stand gehalten wird (ein Kopfschmerz weniger für Sie).

Die PaaS, die ich empfehlen würde, ist dotCloudzusätzlich zu PHP (siehe ihren PHP-Schnellstart) kann es auch MySQL, MongoDB und eine ganze Reihe zusätzlicher Dienste bereitstellen. Es hat auch nette Extras wie Bereitstellung ohne Ausfallzeit, sofortiges Rollback, volle Unterstützung für SSL und Websocket usw. Und es gibt eine kostenlose Stufe, die immer nett ist 🙂

Da ich dort arbeite bin ich natürlich etwas voreingenommen! Andere Optionen, die es wert sind, neben dotCloud überprüft zu werden, sind Pagodabox und Orchestra (jetzt Teil von Engine Yard).

Hoffe das hilft!

Solomon