Kategorien
One-Click Installation
Unglaublich. Eine Woche Urlaub schon wieder rum. Schade für mich, gut für euch. Wenn ich mich nämlich wieder den ganzen Tag mit PHP und Qualitätsmanagement beschäftige, dann habe ich auch viel zu schreiben. Ich habe übrigens die ganze Woche an was feinem für phphatesme gebastelt. Ihr dürft gespannt sein.
Da aber heute der Artikel live geht, den ich gestern geschrieben habe, habe ich natürlich nicht gearbeitet (logisch?!). Deswegen dürft ihr euch noch mal eine Weisheit anhören, die eigentlich von Joel Spolsky stammt, von mir aber auf jeden Fall bestätigt werden kann. Es geht um die Installation von Software. Ich nenne es die „One-Click Installation“. Dabei geht es darum, dass eure Software ohne Probleme installiert bzw. gebaut werden kann. Stellt euch mal vor, ihr programmiert an einem bestimmten Projekt, wie zum Beispiel www.heise.de. Um das Projekt lokal auf eurem PC zu laufen zu bringen müsstet ihr jetzt alle Einstellungen, die das System benötigt von Hand einstellen. Ich tippe mal drauf, dass das eine ganze Menge sind und dass vielleicht ein oder zwei Leute auf dieser Welt dies können. Tja dumm gelaufen, wenn man es selbst machen muss und nicht zu den zwei Personen gehört.
Ich habe schon an einigen Projekten gesessen, da hat es Stunden gedauert eine Webseite aufzusetzen, bis sie tatsächlich lief. Das dumme daran war, der Ablauf war immer genau der gleiche! Und alles was immer das gleiche ist, kann man auch in Automatismen packen. Wir basteln uns also „einfach“ ein build-Skript, dass den ganzen Kleinscheiß für uns erledigt und wir setzen uns danach einfach hin und tippen „ant“ (kann natürlich auch make oder so etwas sein) ein. Wie immer bei automatisierten Abläufen wird die Aufzeichnung erst mal Zeit kosten, die ihr aber schnell wieder drinne haben solltet. Hier gilt es natürlich für euch zu entscheiden, wie oft ihr das System aufsetzen müsst und wie sehr ihr von dem Wissen einer Person abhängig seid. Bei den meisten Projekten, in denen ich involviert war, haben wir es zum Schluß hinbekommen uns ein ant Skript zu basteln, das die Anforderunegn erledigt hat.
Natürlich ist diese Anforderung nicht ganz so selbstlos. Im Qualitätsmanagement in der Softwareentwicklung ist der Continuous Integration Prozess meiner Meiner Meinung nach einer der wichtgsten. Nach jedem Commit wird dort das komplette System gebaut und alle Tests gegen die aktuelle Version gefahren. Auch hier spielen Automatismen eine wichtige Rolle. Müsste ich jedes mal, wenn sich was am System ändert (ein ALTER TABLE in der DB reicht ja bereits schon) meinen Continous Integration Server anfassen, würde ich ziemlich schnell einen an der Waffel bekommen (derzeit betreuen wir ca. 30 Webseiten). Das muss also alles automatisch passieren.
Mir fällt gerade ein, dass ich mal die Woche der Automatismen ausrufen könnte, aber vielleicht auch nicht. Mich würde auf jeden Fall mal interessieren, wer von euch so ein Installations Skript für sein System hat. Wie immer wartet die Kommentarfunktion also auf euch.
hi,
alles richtig was du sagst.
aber was ist mit projekten, die regelmaessig in groesstenteils immer dieselben environments installiert/ausgerollt werden muessen (zb dev, stage, testing, live, ..)?
da wird man immer wieder unterschiedliche konfigurationen benoetigen, die allerdings fuer das jeweilige zielsystem meist gleich bleiben. vielleicht aber auch asynchron zu den rollouts veraendert werden.
was man braeuchte waere dann doch ein konfigurations management tool. ich werd mir jedenfalls mal puppet[1] anschauen.
gruss
/christian
1 http://reductivelabs.com/products/puppet/
@Christian: Gute Frage 🙂 Da kommen wir wohl auf das Thema, ob Config Files Teil des Repositories sind oder nicht. Aber auch so kann es relativ komplex werden.
Vielleicht schaffe ich es ja mal ein Beispielprojekt hier vorzustellen.
Mmh… ich kann da ja mal mit unserer http://www.demobereich.de Fahne winken. 🙂 Das ist genau der Grund, weshalb wir Demobereich entwickelt haben. Ein Testsystem incl. Subversion und Trac aufsetzen in 2 Minuten. Und dann bei jedem Commit automatisch auschecken. Demnächsten kommen diverse Qualitätsmanagement-Tests und PHPUnit-Unterstützung mit dazu.
Mit den unterschiedlichen Konfigurationen handhaben wir das so, dass wir alle Einstellungen in einer Konfigurationsdatei halten und je nach Server verschiedene Einstellungen über Zend_Config laden.
1) Config-Files zur Herstellung einer Umgebungs (egal ob Production, Staging oder Developement) gehören ins Repository. Bin ja nicht der Einzige der das brauchen könnte, ebenso ist ein automatisches Backup immer gut
2) Ein automatisiertes Skript zur Herstellung der lokalen Entwicklungsumgung ist schon cool, aber bei kleineren Projekten auch nicht zwingend nötig. Eine sinnvolle Dokumentation reicht ja auch, denn man muss da auch Kosten & Nutzen setzen. Man setzt die lokale Umgebung ja nicht 20x auf. Wenn man natürlich 30 Projekte betreut und minütlich diese Projekte wechselt 😉 dann macht es natürlich auch wieder Sinn.
@Ulf: Wie sieht es denn aus mit Passwörter für die Datenbank? Gehören die mit ins SVN? Da kann doch jeder Entwickler sein eigenes haben und wenn das dann beim Update überschrieben wird ist es auch nicht wirklich gut. Timeout Zeiten könnte ich mir auch vorstellen je nach lokaler Maschine setzen zu müsssen …
@5 Ich bin bei sowas immer ein Freund von Hooks. Wird ja von den (mir) bekannten SCMs weitesgehend unterstützt. Und bezüglich der ENVs, da finde ich die Lösung, von Zend_Config sehr gut, dass man halt eine „Standardconfig“ hat von mir aus Production und die vererbt einfach, die immer gleichen Configs an Ihre „Kinder“.
@Bastian: wieso kriege ich $ statt Euro angezeigt? Ist das absicht oder setzt ihr keinen „Default Locale“ in Zend_Registry? Denn mein Browser steht auf en_US! Ansonsten ist es ein interessantes Produkt.
Bei uns in der Firma haben wir Scripts, die die Einstellungen des Webservers vornehmen. Die COnfig Files werden per Zend_Config geladen, da gibt es dann auch Spezial-Configs für die einzelnen Environments. Einzig die Windows-User müssen noch recht viel von Hand einstellen, denn unsere Tools sind aktuell nur für Linux verfügbar.
@Dennis: Danke für den Hinweis. en-US hab ich auch gerade getestet und den Fehler an die Entwicklung weiter gereicht. An Paypal werden zum Schluss dann aber EUR übertragen, dh. es ist nur ein ungünstiger Anzeige-Bug. Wird aber im nächsten Release behoben.
Also mich würde das Ganze sehr interessieren (ein genereller Ablaufplan + Beispielcode).
Ich persönlich finde es immer etwas schwierig,
wenn sich etwas in der DB-Struktur geändert hat.
Mein derzeitiger Weg:
ein SQL-File anlegen und immer wenn ich was an der Struktur ändere,
dann trage ich dort den SQL Befehl ein.
Falls was transformiert werden soll, wird das auch da eingetragen.
Und aktuell spiele ich das das manuell über phpmyadmin ein…
Nachteil daren:
ich vergesse etwas dort einzutragen und deshalb vergleich ich die Struktur oft (beidseitiger Export + diff) aber das ist doch immer etwas aufwändig.
Gibt es einen eleganteren Weg?
@Nils
Die Congif-Einstellungen für Production / Staging sollten eh gleich sein und in der Developement-Umgebung gibt es zwei Möglichkeiten. Entweder jeder verwendetet das gleiche Setup. Wenn er das nicht tun möchte, dann darf er auf keinen Fall diese Config-Dateien ohne weiteres commiten. Und mal ganz ehrlich, bei seiner lokalen Datenbank kann ja jeder wohl das Passwort einstellen wie es das Projekt vorgibt. Wenn er das nicht möchte, muss er eben mit den Nachteilen leben.
Man möge mir die miserable Rechtschreibung verzeihen, ist ja heute Montag! 😉
@Francois: Für solche Änderungen würde ich definitv zum MySQL Workbench greifen, da das Tool auch nachträgliche Änderungen unterstützt und man die Modifikation direkt in die Datenbank einspielen lassen kann (wenn man will).
Wir handhaben das etwas anders. Die meisten unserer Kunden haben keinen Shellzugang. Make, ant und Co. sind darum eher schlecht zu gebrauchen.
Darum ist eine gute browserbasierte Installation genauso wichtig. Die sollte nur die absolut wichtigsten Sachen abfragen (Datenbank-Zugangsdaten), sich aber so weit wie möglich selber konfigurieren.
Wenn man die Konfigurationsdateien bei einem Checkout nicht überschreibt, sondern statt dessen z.B. mit .dist-Dateien arbeitet, kann man auch ein Update relativ einfach durchführen.
Hi,
wir haben für jeden Entwickler einen Webserver sodass jeder direkt „online“ testen kann und man nicht mit virtuellen Maschinen auf den PCs rumhantieren muss. Jeder hat eine eigene Datenbank und es gibt eben einen Live-Server und eine Live-Datenbank.
Die Webserver haben jeweils eine systemweite config-File die z.B. Datenbank-Zugangsdaten enthält. In diese lokale Datei können dann noch weitere Einstellungen gepackt werden, die dann die des richtigen Config-Files überschreiben (wird also mit include nach der config aus dem SCM eingebunden). Auf dem Live-Webserver gibt es daher auch eine entsprechende lokale Konfiguration.
Datenbankzugangsdaten befinden sich also nicht im SCM und irgendwas beim liveschalten der Änderungen anzupassen ist daher nicht mehr nötig.
Ein vollstäniger Checkout kann durch jeden Entwickler ausgelöst werden und verläuft automatisch unabhängig vom Commit.
Änderungen des Datenbankschemas sind leider noch nicht automatisiert möglich – wie löst ihr das?
Viele Grüße,
Peter
@Dennis: danke für den Tipp, schau ich mir an!
@14 Peter:
Ich habe das so wie Ulf (@4).
Für die Konfiguration verwende ich Zend_Config und
habe einen produktiven, test, qualitäts und entwicklungs Abschnitt.
Die Konfiguration com Q-System erbt vom Produktvsystem und
überschreibt gewisse Werte.
Test vom Q-System und Entwicklung vom Testsystem.
Welches System gesetzt wird, entscheide ich entweder in der htaccess Datei mit „setEnv“ oder da mein Provider das leider verbietet, anhand von einer $_SERVER-Variablen…
Entwicklungssystem ist bei allen Entwicklern gleich, was bei zwei bis drei Personen nicht sonderlich schwer ist.
Da ich auch mehrere Webseiten/Server betreue habe ich mir auf meinem Server ein paar Installationsskripte bereitgelegt, die ich dann nur auf dem jeweiligen System mit einem Einzeile aufrufen muss.
apt-get -y install lynx; lynx -source http://example.com/installdebian01.sh|sh
Dadurch werden gleich alle anderen wichtige Programme nachgeholt, ein mysql-Server aufgesetzt, Phpmyadmin installiert und konfiguiert sowie ein Subversion aufgesetzt.
Subversion hat den Vorteil, dass ich wichtige php-Klassen, nur noch einmal zentral committen muss und die Server updaten sich dann automatisch per Cron-Job. So kann man auch leicht ein Testsystem aufsetzten oder über die Revision-Nummer in einer Text-Datei sicherstellen, dass nur die Stable-Version ausgerollt ist.
Mir war es damals einfach zu lästig, dass wenn eine neue Version eines Flash-Players kam, oder ich eine Änderung an einem php-File vorgenommen habe, danach erstmal 2 h beschäftigt war, bis die Dateien auf allen System ausgeliefert waren.
Schöne Grüße
andreas
So ein Zufall…
Im aktuellen PHP Magazin (1.10) steht ein guter Artikel über Build-Automation.