Kategorien
Deployment bei phphatesme (Stand Februar 2010)
Nachdem ich gestern einen kleine Proof of Concept gebastelt habe und der, nach der Anzahl der Kommentare zufolge, recht gut den Tag gefüllt hat, wollen wir diesen Donnerstag dazu nutzen ein wenig aus dem Nähkästchen zu plaudern.
Da ich meinen Source-Code nicht mehr einfach per FTP auf den Server schiebe, wie ich das vielleicht vor einiger Zeit noch gemacht habe, möchte ich erzählen, wie der Deploymentprozess bei uns im Moment aussieht und wohin ich noch kommen will, denn der Stand, wie es derzeit läuft ist zwar ausreichend, aber ist nicht meine Zielarchitektur.
Punkt eins: für die Datenbank habe ich keine Lösung. Da fast alle, bis jetzt waren es sogar alle, Datenbankänderungen, die ich in diesem Blog hatte, abwärtskompatibel waren, war da eine komplexe Lösung auch nicht nötig. Das passiert also händisch, falls es passiert.
Gehen wir also zurück zum Quellcode. Wie viele von euch auch verwende ich eine Versionsverwaltung, bei mir ist es SVN, für mein Projekt. Das ist ganz praktisch, da ich so ohne Probleme an mehreren Rechnern arbeiten kann. Das Backup hat sich damit auch erledigt. Habe ich eine Funktionalität fertig und die soll live gehen, so habe ich mein Staging-System, das sich auch auf dem Live-Server befindet. Unter beta.phphatesme.com kann dieses erreicht werden. Alles was ich dort machen muss ist ein svn -up und schon sind die aktuellen PHP Files auf dem System. Dann teste ich das ganze unter der „geheimen“ url und wenn alles funktioniert, dann stelle ich live.
Livestellen ist in meinem Fall ein Shellskript, dass den Quellcode in das Live-Verzeichnis kopiert. Mehr ist nicht nötig.
Was mir fehlt, aber bis jetzt auch nicht benötigt war, ist der Rollback. Natürlich kann man sagen, dass das grob fahrlässig ist, nicht zu dem Stand vor dem Release zurückkehren zu können, aber wir sind nicht kommerziell, uns verzeiht man, wenn wir mal 30min down sind. Und wenn es dann mal wirklich die Lösung des Problem gewesen wäre, dann hätte ich am nächsten Tag die Lösung live. Da bin ich mir sicher.
Wie es eigentlich sein sollte oder besser, wie ich es mir vorstellen würde ist wie folgt: Das Livestellen der Sourcen ist nicht ein umkopieren, sondern einen symbolischen Link umlegen. Damit bleiben alle Versionen live und ich kann zu jeder zurückkehren, wenn ich will. Ich werde mich die nächste Zeit mal hinsetzen und das ganze in Visio oder so gießen, damit man es auch versteht.
Was man sich einfach merken sollte ist, dass man SVN und Co. verwenden, ein Stagingsystem andenken und ein Rollback planen/ermöglichen sollte.
Ein svn update birgt Sicherheits-Gefahren, wenn man damit Programmcode auf ein Staging- oder Livesystem spielt. Grund ist, dass ebenfalls die .svn Ordner ausgecheckt werden, und ggf. lesbar für jedermann sind. Besser ist hier ein svn export. Damit werden keine svn internen Informationen mit ausgecheckt, sondern nur der reine Programmcode. Alternativ sollte man zumindest den Zugriff auf die .svn Ordner mittels .htaccess (zum Beispiel) schützen.
RewriteRule (\.svn)/(.*?) – [F,L]
Grüsse,
Stephan
Deployment per SVN ist relativ schick. Hier agiert aber der Zielserver aktiv, sprich er muss die neue Version aus dem SVN anfordern. Ich untersuche momentan den anderen Weg. Der CI-Server packt alles in eine zip, die man per phing oder ant auf das Zielsystem deployed. Aber wie man auch immer deployed – Hauptsache es passt in die Infrastruktur und alles funktioniert.
Übrigens gibt es Leute die dich für die Aussage, dass svn ein Backup ersetzt, hauen würden. Wir hatten bei diesem Thema einmal eine sehr hitzige Diskussion 😀
Grüße
Dein Rollback ist doch SVN selbst!? Ein „svn update -r[Nummer]“ bringt Dir die gewünschte Revision zurück. Warum machst Du Dein Produktiv-Verzeichnis nicht auch zur Arbeitskopie, dann könntest Du es auch über SVN update und gegebenenfalls rollbacken (geiles Denglisch). Ich bevorzuge bei meinem Projekt allerdings auch die Lösung mit den Symlinks.
DB Modifikationen rollt svn aber nicht zurück 🙂
Nope, und Configänderungen mit DBPws und ähnlichem auch nicht 😉
Aber muss mich ersterem anschließen, hail phing, hail symlinks :))) Sehr nette Sache.
Hallo,
Bei unter VCS bzw DVCS projekten handhabe ich es so.
Tagen/Branchen jeder version.
/var/www/domain.com/package_v1_0
/var/www/domain.com/package_v1_1
… und so weiter.
dann gibts einen sym link:
/var/www/domain.com/current der auf das jeweilige aktuelle verzeichniss zeigt.
Ich glaube diese variante hast du auch gemeint.
bezüglich Datenbank version management kann ich dir nur empfehlen mal doctrine anzusehen. (letzen phpmagazin war eh ein netter artikel dazu)
my2c
Ludwig
Diese sind ja in den meisten Fällen (so wie im Artikel erwähnt) abwärtskompatibel. Daten, die nach einem nicht abwärtskompatiblen Datenbankupdate eingetragen wurden gehen doch bei einem Rollback immer verloren, oder kennt jemand dafür eine gute Lösung? Man kann ja nicht die Daten aus der neuen Struktur mit der alten Struktur mergen. Migrations von Doctrine machen es übrigens möglich die Datenbank in SVN zu versionieren.
@Udo jetzt mal von meinem personal dislike gegen Doctrine abgesehen (jaaa ich weiss, dass die neue Version viel besser sein soll, put flame here…) kann man sehr wohl bei einem Versionsupdate automatisch eine bestimmte DB-Datei schreiben lassen, und beim Versionsupdate fürs Rollback gleich der letzten Version im Rollout eine Art Fallback-File erstellen. Kommt mir ebenfalls sehr elegant vor. Oder irre ich mich? Bin ich der einzige den es ankotzt, dass hier in solchen Fällen immer nur von SQL gesprochen wird? 😀
Die folgenden Links dazu könnten euch interessieren:
http://stackoverflow.com/questions/800294/how-to-get-started-deploying-php-applications-from-a-subversion-repository
http://morethanseven.net/2008/01/30/simple-deployment-with-svn-and-phing/
Im Moment deployen wir auch per svn-update. Das geht super fix wenn man mal schnell was ändern muss. Und wenn irgendwas schief geht, kann man in wenigen Sekunden wieder zurück. Wir haben nun überlegt mit Branches und Versionen zu arbeiten und dann nur 1-2 mal pro Woche zu deployen. Allerdings wird wohl eher eine Umstellung auf GIT erfolgen, da hab ich allerdings noch keine Erfahrungen damit. Sie das bei euch anders aus?
Du kannst dir doch vor jedem Release ein SVN-Tag deines Standes/deiner Version anlegen und diesen Tag dann wie bereits erwähnt via svn export irgendwo hin auschecken und meinetwegen im Anschluss ver(sym)linken. So hebst du dir jeden Release schön betitelt im SVN auf. Zumindest gilt das für den Code.. 😉
@Nils Wir arbeiten gerade an einem automatischen Update für Datenbankstrukturen. Dieses erlaubt ein Ausrollen der Updates auf einem oder mehreren Zielserver per Push oder Pull und ein begrenztes Rollback.
Die Beschreibung der XML-Skripte ist bereits öffentlich zugänglich unter: http://yanaframework.net/docs/8-45-102.html
Den Quellcode werden wir als Open-Source herausgeben mit Unterstützung für automatische SQL-Generierung: auf MySQL, PostgreSQL, Oracle, DB2, MS-SQL. Momentan plane ich die Generierung auf XSLT umzusetzen, damit sie auch für andere Programmiersprachen wie Java 1:1 einsetzbar ist.
In PHP-Code bliebe dann nur noch das Push- oder Pullverfahren und die Versionsermittlung am Datenbankserver. Letztere über eine Logtabelle, welche die Änderungen in ähnlicher Weise protokolliert wie SVN dies tun würde, wenn es denn ein SVN für Datenbankserver gäbe 😉
Ich denke damit haben wir zumindest die Datenbank gut im Griff.
Ansonsten empfehle ich Phar-Archive mit Deploymentdeskriptor und einen Package-Manager mit Version-Repository … oder man benutzt einfach den PEAR-Installer. Der macht ja im Wesentlichen genau das.
Das alles ist natürlich nicht gedacht für kleinere private Projekte, sondern vor allem für größere Anwendungen im Enterprise-Umfeld oder größere Open-Source Software.
Hat jemand hier Erfahrungen mit phing/phar Deployments und kann ein wenig davon berichten?
Mich wuerde vor allem interessieren, wie hoch der Aufwand anfangs war bis der Workflow passte und wie dieser dann ungefaehr aussah.
Die erwähnten Sicherheitsprobleme durch die .svn Folders sind ein guter Grund, sich mal mit Git zu beschäftigen. Da gibt es nur noch ein zentrales .git-Verzeichnis und so ist es ein leichtes, das entweder zu löschen oder – ein wenig eleganter – das Projekt so zu planen, dass das .git ausserhalb von Doc-Root liegt.
Alex, mit svn export erstellt man sich ein „sauberes“ Verzeichnis ohne .svn Inhalte.
„svn export“ sollte man auf jedenfall einem „svn update“ vorziehen, sonst kenn man auch die Verzeichnisstruktur die nicht im DocumentRoot vorhanden ist und hat einen Angriffspunkt!
Wenn man sich mal so umschaut, was es denn so für nette Deployment Tools gibt, so muss ich sagen finde ich ControlTier (http://controltier.org/wiki/Main_Page) eine wirklich gute Lösung (ohne es bisher jemals getestet zu haben). Die Features, die ControlTier hat, sind glaube ich für jede Enterprise Applikation nützlich, vor allem, wenn dahinter noch etwas mehr steckt als nur eine Webseite + Datenbank
Mir ging es übrigens auch mal so, dass sich eine sehr zweifelhafte Firma versucht hat über ein Abbild unseres SVNs (nur die Ordner) anzudingen. So dass wir auf deren „professionelle“ Hilfe zurückgreifen um diese Sicherheitslücke auszumerzen. Zum Glück hatten wir jemanden der uns auf die „SVN-Lücke“ gebracht hat, ansonsten wäre es wohl recht teuer geworden.
Ich habe dazu auch einen kleinen Text verfasst: http://www.fractalcenter.de/2009/10/subversion-auf-dem-webserver/#content
Wie im Text beschrieben und oben auch schon genannt ist svn export recht langsam. Wenn man dies natürlich in ein anderes Verzeichnis macht und erst am Schluss einen Symlink setzt, ist dies wohl der sicherste Weg. Sollte ich vielleicht meinen Artikel gleich mal überarbeiten. 🙂
MaikL,
svn export + symlink ist genau der praktikabelste Weg. Dazu ein komfortables Shell-Skript und es geht nicht einfacher. So behält man am besten die Kontrolle.
Aber was ist wenn ich ein Projekt im GB Bereich habe? Dann brauch ich ja ewig wenn ich jedesmal ein export mache. (Ok bei uns ist der Großteil dann Bilder, aber das ist ein anderes Thema 😉 )
Zum Thema DB-Rollback. Man muss doch blos vor dem svn update oder dem sync (dabei die .svn Verzeichnisse einfach excluden) einen DB-dump erzeugen. Damit kann man exakt an die Stelle zurück springen. Dann wären jedoch die Kommentare weg, die seit dem geschrieben worden. Aber immerhin erst mal ein sicheres Rollback.
Die Verzeichnisstruktur kann man dann wie gesagt per svn up -r xx oder per symlink versionieren.
Alternativ ginge natürlich auch eine Kopie der DB „datenbank_live“ nach „datenbank_1“ etc… zu machen. Dann entsprechend die Config files anzupassen. So kann man auch ganz schnell umschalten oder im Testsystem schon die Änderungen drin haben, die im live noch nicht sind.
@Alex: Ich glaube so viele php Projekte im GB-Bereich gibt es weltweit gar nicht, oder?
@Nils – unsere Seite ist aber leider so groß. Das liegt aber wirklich zu 90% an den Bildern. Die wurden damals mit ins SVN aufgenommen und haben sich seit dem immer weiter „vermehrt“. Inzwischen ist das Ganze einige GB groß. Deshalb können wir das dann nur per svn-update machen. Aber die .svn Ordner sind entsprechend geschützt. Und auf GIT wird auch bald umgestellt (dann fliegen sicher auch mal die Bilder ausm Repo).
Von Capistrano (http://www.capify.org/index.php/Capistrano) kann man sich auch ein paar Anregungen holen. Dort werden Symlinks eingesetzt. Aber auch die Loesung fuer Daten, die per Upload ins htdocs-Verzeichnis kommen und nicht im Repository liegen, werden so behandelt
Für das Wald- und Wiesen – Deployment möchte ich mal auf „sitecopy“ hinweisen. Sitecopy ist mehr oder weniger ftp, nutzt aber Profile, um sich Server und Konfigurationen zu merken.
Man kann für verschiedene Releases neue Profile anlegen, für verschiedene Server ebenso und exclude bzw. ignore (.svn) Anweisungen geben. Sitecopy liest den Stand der remote site ein (fetch) und überträgt bei einem Update dann auch nur die geänderten Dateien. Ein Update ist dann z.B. der Befehl „sitecopy -u my_site_v1″…
Gebe auch noch mal kurz meinen Senf hinzu (auch wenn recht spät und schon viel gesagt wurde).
Das automatische Deployen + das Verbiegen von symbolischen Links ist auch der Weg welchen ich beruflich nutze. Hat den erheblichen Vorteil super schnell und einfach zurückrollen zu können. Im Idealfall sollte das Deployen auf den Live-System aus getaggten Versionen des SVN kommen so weit sind wir aber auch noch nicht.
@Christian
Wir deployen mit phing. Hat den Vorteil dass man ein paar notwendige Änderungen während des deployen dort hinein tun kann (z.B. Adaption der htacess im Bezug auf environments usw. oder auch des Setzen der ZF-Library, die wir somit nicht jedes mal ausrollen müssen). Die ganzen PHAR-Befehle sind auch alle sehr trivial und erinnern sehr stark an Ant (und Maven). Vorteil daran ist auch man kann noch entsprechend loggen was bei Fehlschlägen von Builds ganz sinnvoll ist. Ebenso kann man die XML-Skripte selbst auch versionieren.
@Nils
PHP-Projekte selbst sind wohl selten über 1GB, aber Datenbanken sicherlich häufiger. Darum kann man da nicht so schnell was versionieren sonst ist die Platte schnell voll. Auch weiß ich nicht wie man 1GB mit Bildern vollpackt. Im Web sollten diese doch skaliert und optimiert sein. Das müssten ja dann > 100.000 Bilder sein…
Im übrigen würde ich das Testsystem immer per htacess schützen. Das kann dann auch in den Build-Skript mit rein. Irgendwann erkennt Google doch mal die Seite bzw. der Konkurrent (für dieses private Projekt sicherlich nicht so wichtig, aber im business schon).
Bei Datenbankänderungen bin ich mittlerweile auch überzeugt, dass man diese nicht zu 100% versionieren kann. Ich glaube man muss für seinen Anwendungsfall den sinnvollsten Weg finden. Spätestens wenn man mit einem Deployments Spalten löscht kann man nicht ohne weiteres zurückrollen, da die Informationen nun mal gelöscht sind. Auch bei Hinzufügen von neuen Spalten (ich finde Doctrine handhabt das super) will man öfters auch diese Spalten mit irgendwelchen Werten füllen. Da ist mir noch kein Weg eingefallen, wie man dies automatisieren kann. Ebenso kommt bei System wie WordPress (oder Magento) auch hinzu, dass man aufgrund von Änderungen im Admin-Panel Daten in der Datenbank verändert, löscht und hinzufügt. Kenne da auch keinen praktikablen Weg dies wieder dem SVN bekant zu machen (trivialer Fall: Der Blog-Admin installiert ein neues Plug-In).
Generell wäre das Thema automatisches Deployment sicherlich ein gutes Panel-Thema auf irgendwelchen Konferenten. MVC kann mittlerweile ja jeder (bzw. sollte es können 😉 ), aber gerade beim Deployen kann man sicherlich noch viel optimieren. Auch da es wohl keine perfekte Lösung gibt.
Las mich raten, deine „geheime Url“ ist phphatesme.local? 😉
Bei demobereich.de haben wir ein automatisches Deployment integriert. Dh. bei jedem Commit wird automatisch, wenn gewünscht, ein Deploy angestoßen und direkt unter einer eigenen Subdomain veröffentlicht. Natürlich mit Zugriffsschutz für Projektmitglieder. Ich kann auch problemlos mehrere Branches gleichzeitig ausgecheckt zum Testen vorhalten, was bei größeren Projekten mit vielen Mitarbeitern sinnvoll ist. Dann hat jeder seine eigene Subdomain zum Testen und kann dort fleißig sein.