Deploy von PHP-Applikationen

Transkript

1 Deploy von PHP-Applikationen Jan Burkl System Engineer Zend Technologies

2 Wer bin ich? Jan Burkl PHP Entwickler seit 2001 Projektarbeit Bei Zend seit 2006 System Engineer Zend Certified Engineer PHP 5 Zend Framework

3 Agenda Worüber wir sprechen werden Deployment->Testing->Staging->Production SVN/rsync/PEAR/yum Mechanismen Worüber wir nicht sprechen werden Build Tools (Phing, Maven, etc.) Datenbank Versionierung / Deployment Continuous Integration MSI Installationen (Sorry MS folks )

4 Application Stages Development Testing/QA Staging Production

5 Schon ausgewachsen? Benefit Wo stehen Sie? Uptime!! Verschiedene Dev Environments Testen & validieren der Applikation Testen & validieren des Environments Struktur

6 Development Grund Den Entwicklern eine Umgebung geben, um Code zu schreiben Charakteristik Sollte der Produktionsumgebung ähnlich sein normalerweise ist sie es nicht Normalerweise lokale Entwicklung, obwohl es nicht notwendig wäre

7 Testing Grund Eine Non-Programming Umgebung liefern, um Funktionalität zu testen Charakteristik Continuous Integration kann integriert werden Normalerweise keine Entwicklung, nur Testen Entwickler selbst sollten nicht testen, wenn möglich Eingeschränktes Outbound Networking Zend Server Monitoring und Code Tracing benutzen, um Fehler zu reproduzieren

8 Applikation vorbereiten zum Weitergeben an System Administratoren (the stuff we re here to talk about)

9 Staging Grund Deployment Prozess/Skripting testen (nicht unbedingt den Code) Charakteristik Entwickler haben normalerweise keinen Zugriff, es sei denn sie sind auch der Sysadmin Sehr eingeschränktes Outbound Networking Spiegelt das Produktionssystem normalerweise am Besten

10 Change Control Ein formaler Prozess um sicherzustellen, dass Änderungen in einer kontrollierten und koordinierten Art und Weise durchgeführt werden Schutz vor unnötigen Änderungen wegen fehlender Weitsicht Erfordert das Dokumentieren des Release Prozesses Software Versionsnummer Pläne für Rollback (getestet? j/n) Erwartete Ausfallzeit Auswirkungen auf Kunden Muss vor jeglicher Änderung der Produktion gemacht werden

11 Pre-Production (Optional) Grund Den Code in der Produktionsumgebung ohne Auswirkung für den Kunden testen Charakteristik Nicht üblich in der Cloud oder in großen Deployments Deployment auf dem Produktivsystem umgehend bevor es live gestellt wird Die Applikation wird mit Produktions-Einstellungen aber ohne Kunden-Interaktion getestet

12 Production Grund Es wird gemacht, was gemacht werden soll Charakteristik Entwickler haben keinen Zugriff (sonst könnten sie in Versuchung geführt werden, direkt etwas zu fixen) Deployment sollte ohne Input vom Entwickler möglich sein Sehr limitierter Inbound Traffic normalerweise ausschließlich der Service, der benutzt werden soll, z.b. HTTP

13 Application - Überlegungen Die Applikation im Bewusstsein der unterschiedlichen Umgebungen entwickeln Zend_Config_* ist ein guter Anfang Nicht den Umgebungs-Typ im Code setzen Environment Variablen können in Server Config gesetzt werden Das bedeutet, dass Development Settings in der Produktion versehentlich eingeschaltet werden Produktion ist das Default Environment Minimiert das Risiko eines versehentlichen Daten-Lecks

14 Deployment Option 1 Source Control Benefits Einfach Source Control sollte bereits im Einsatz sein Versionierung Pre/Post Install Scripts Automatische Deployments sehr einfach einzusetzen Nachteile Möchte man Details zum Zugriff auf den Source Code auf dem Produktionssystem haben? Source Control muss von Produktionssystem erreichbar sein Deny Access zu.svn Verzeichnissen

15 Deployment Option 2 rsync Benefits Einfach (Normalerweise) schon auf dem System installiert Nachteile Kein Deployment Script kann ausgeführt werden Nicht integriert in PHP oder das OS Rollbacks erfordern das zurückrollen des gesamten Source Server Keine Versionierung Eine Option ist den Source Tree vor rsync zu verschieben

16 Deployment Option 3 PEAR Benefits Designt für PHP Sehr scriptable Geeignet zum Löschen von Cache oder ähnlich Ist näher an PHP Cross Platform kompatibel Nachteile Admins müssen sich mit PHP auskennen Limitiert auf PHP Deployment Verfügbare Tools sind restriktiv eigenes package.xml bauen

17 Deployment Option 4 OS-basiert Benefits Einfach als Teil des Server Deployments hinzugefügt Cloud friendly Admins wissen schon, wie es geht OS-Requirements können beschrieben werden Downtime nur während der wirklichen Installation nicht während Network Transfer Zeit Nachteile Hängt von der verwendeten Umgebung ab Jedes PHP Deployment Skript muss mit der Applikation deployed werden und im %post Hook ausgeführt werden, z.b. Cache löschen

18 Welches nehmen? Was einfaches? rsync Verschieden Plattformen? PEAR Interner Deploy mit minimalem Developer Input? OS (yum/apt)

19 Continuous Deployment Automatisiertes Deployment Stabile End-to-End Integration Erfordert eine Menge Vertrauen, dass die Entwickler eine komplett getestete Applikation mit Frontend und Backend Code haben Wahrscheinlich zu viel Arbeit, wenn man die Anzahl der Server an seinen Fingern ablesen kann Kann hilfreich sein vorher sicherstellen, dass man weiß was man tut

20 Takeaways Keine Notwendigkeit für Copy-and-Paste Deployment Keine Notwendigkeit für (S)FTP Einfacher Rollback Mechanismus Vorbereitet sein auf Fehler während des Deployments Versuchen die Anzahl der Skripte so gering wie möglich zu halten

21 Follow us! Zend Technologies (Kevin Schroeder)

22 Get this information and all the examples at eschrade.com

23 Dankeschön!