Deployment - Oder wie kommt der Source auf den Server

Ich wollte mal wissen was ihr euch schon alles für gedanken zum Thema Deploment gemacht habt.
Wie kommt bei euch der Source auf den Server. Ladet ihr geänderte Dateien einzeln auf den Server, oder Ladet ihr immer das Komplete Projekt hoch.
Nutzt ihr evtl irgend welche Tools die euch dabei helfen, wenn ja welche.
Dann ist die Frage was passiert bei DB Updates. Autoamtisch einspielen oder von Hand und wie herausfinden was sich geändert hat zum lezten mal.
Ich frage weil ich mir gerade gedanken für so ein System mache und aus Faulheit würde ich glaube zu SVN greifen und auf dem Server einfach immer ein SVN Update machen.
Ich glaube das sich z.B. OGame keine gedanken gemacht hat und die einfach zu Faul sind da Upzudaten und machen deswegen immer neue Unis auf.
So bin auf eure antworten gespannt

da ich allein arbeite ist filezilla und manuelles abgleichen nach bearbeitung auf dem testserver standard. zum reset werden dann einmal alle files vom testserver auf den "richtigen" übertragen. feddisch..
aber ab 2 oder mehr leuten ist svn mit checkin/out auch was feines.. in kombination mit ein paar anderen tools sogar super
aber konkrete erfahrungen hab ich mit svn nicht. hab noch keine verständlichen tuts oder einen "lehrer" gefunden.. und alleine hab ich auch keine lust da 2 tage rumzufrickeln, bis alles so läuft, wie ich es will..

Da ich im Moment noch keinen Server betreibe sondern das Spiel nur auf meinem eigenen Rechner betreibe kann ich dir nur sagen wie ich es tun will.
Entwickelt wird mit SVN (auch jetzt schon). Ist eine Version fertig wird sie in SVN getaggt. Dann wird sie auf dem Testsystem ausgecheckt und "gebaut". Im Fall von meinem Spiel heisst das: Java Klassen kompilieren, JAR Files packen und in die Installation legen, danach die Datenbank aktualisieren und Spielserver neu starten. Wenn sich eine Version auf dem Testsystem bewährt, wird sie als Final getaggt und in den Spielwelten eingespielt.
Datenbankänderungen werden während der Entwicklung in SQL-Scripts protokolliert. Beim Deployment auf den Test- und Produktivsystemen werden die SQL-Scripts dann auf die entsprechenden Datenbanken losgelassen.
Tools sind demzufolge SVN, das Ant-Buildsystem und simple SQL-Scripts für die Datenbank. Grundsätzlich kann der Deploymentprozess automatisch ablaufen und wird das wohl auch tun. Man muss halt auf dem Testsystem die entsprechenden Buildtasks aufrufen. Das Buildsystem kümmert sich dann um die Kompilierung des Codes und für Dinge wie die SQL-Scripts, Verteilung auf den Produktivservern, Neustart der Spielserver kann man eigene Scripts in das Buildsystem einhängen.
Mein Ziel ist es, dass man für das Deployment dann nur noch

Build testserver

bzw.

Build stableservers

im Terminal ausführen muss und der Rest halbwegs automatisch durchläuft. Sonst wird das Release immer ein riesiges Gebastel von Hand..

Ich mache es noch ganz alterstümlich, ich schreibe mir meine neuen und modifizierten Dateien auf und lade sie dann einzeln auf den Server. Also alles manuell.
Das DB-Update kopiere ich mir aus den SQL Protokollen zusammen und lade es dann auf den Server.
Werde demnächst aber auch auf SVN umsteigen, damit Updatefehler nicht passieren.

Das ferne Ziel meinerseits ist es auch ein Verfahren zu entwickeln, wie es exe vorhat. Nur nicht mit ant, sondern mit msbuild.
Momentan nutze ich das VisualStudio und den FTP-Client, sowie den Remote Desktop.
Um eine neue Version aufzuspielen, muss ich folgende Schritte durchführen:
- Releasekompilierung
- Aufbauen einer VPN-Verbindung zum Server
- Verbindung mit dem Remote Desktop
- Anhalten des Hintergrund-Dienstes, das sich um die Ticks kümmert
- Deployment der Website über das Visual Studio. Das Visual Studio erkennt selbstständig die geänderten Dateien.
- Deployment des Hintergrund-Dienstes über einen FTP-Client.
- Während der Programmierung werden alle Datenbankänderungen in einer großen SQL-Datei gespeichert. Diese beinhaltet immer die Änderungen von einer Version zur anderen. Um die Änderungen einzuspielen, nutze ich SQLMyAdmin.
- Starten des Hintergrund-Dienstes
- Schließen der Remote Desktop Verbindung und der VPN-Verbindung.
Aber wie gesagt: Ziel ist es ein ähnliches Verfahren wie exes-Wunschverfahren aufzubauen. Mal schauen ob mir das gelingt.

ich verwende SVN.
Das erste Einrichten dauerte bei mir vielleicht eine Stunde:
mit svnadmin create ein Repo erstellen.
Konfigdatei (Repro/conf/svnserve.conf) so anpasen, dass nur User in einer PW-Datei Zugriff bekommen und diese erstellen. Die Defaultkonfigdatei ist so gut kommentiert, dass man mit dieser alleine gut zurechtkommt.
Den Server per svnserve -d -r Repro starten.
Eventuell um svnserve ein kleines Start/Stopscript basteln und/oder es ins Startsriptsystem des Servers reinbauen.
Das wars.
Nun müssen die Daten irgendwohin extrahiert werden.
das geht mit
svn checkout --username user --password pw svn://localhost/btw/trunk/screenshots /var/kunden/webs/mifritsche/worm-hole/screenshots
Damit es automatich nach jeder Änderung aktualisiert wird in Repo/hooks eine Datei post-commit erstellen (oder das Template kopieren) und eine Zeile ala
svn update --username user --password pw svn://localhost/btw/trunk/screenshots /var/kunden/webs/mifritsche/worm-hole/screenshots
reinkopieren. Ausführbar machen nicht vergessen
Das war die Grundkonfiguration.
Auf dem Client nehme ich TortoiseSVN, was sich in den Explorer (und totalcmd ) integriert. Irgendwo nen Ordner anlegen, rechte Maustaste->SVN Checkout und "Anweisungen folgen" :-)
Hochladen geht über SVN Commit. Wenn das nicht über das Hauptverzeichniss aufgerufen wird muss die Datei eventuell geaddet werden, das geht übers Kontextmenü.
Einige Tipps und Tricks:
-Zeilenendungen. Linux ist da gerade bei shelldateien empfindlich. Dafür hat svn aber eine nette Lösung: svn:eol-style:native. Dann bestimmt das System, von wo man das Repro holt wie die Zeilenenden aussehen. Das kann man in den Dateieigenschaften ändern.
-Dateien, die ignoriert werden sollen. Dazu zählen v.a. individuelle Konfigdateien eines php-"Systems" (hat jemand einen besseren Ausdruck?) wie das Forum, einzelne Unis etc., temponäre Dateien wie komplierte Templates, BRs, Logdateien etc. Lösung: Rechte Maustaste ->Add to ignroe-liste->Datei ignorieren.
-Dateien mit speziellen Rechten. Dazu zählen v.a. die berühmten 777-Verzeichnisse oder ausführbare Dateien. Die Berechtigungen werden durch das hook bei Änderungen zurückgestellt. Dazu einfach ein chown bzw. chmod in das Hook einfügen. Für ausführbare Dateien gibt'S aber auch die SVN-Eigenschaft executable, die wie eol-style:native bei den Dateieigenschaften einzustellen ist.
Wenn man eine neue Version möchte, kein Problem: einfach eine Checkout-Zeile in die hooks einfügen und eventuelle Anpassungen vornehmen. Oder man kopiert z.B. /branches/adminuni nach /trunk/uni1, damit man für jedes Uni eine eigene Version haben kann. Das geht mit 3 Klicks im Repo-Browser (rechte Maustaste->TortoiseSVN->Repo Browser).
Das war der Crashkurs SVN :-)
SQL-Änderungen hauen wir in einen internen Bereich des Forums und schreiben uns da auf, wenn was in welches Uni kam. natürlich könnte man das auch über das hook realisieren, brauchten wir aber noch nicht.

Deployment besteht bei Spacetale aus drei Komponenten: Anwendung (da Java-Servlets: komprimierte .WAR), statische Inhalte (Bilder, XMLs) und Datenbankanpassungen.
Die Anwendung geht per SCP hoch, die statischen Daten inspiriert durch Woodworker per wget aus einem SVN Export (da fliegen im Gegensatz zum Checkout keine Verwaltungsdateien mehr rum) und die Datenbankänderungen verwalten wir als Delta zur aktuellen Live-DB im Release-Zweig des SVN-Repository und legen sie gleich so an, dass zum Live-Stellen die Ausführung aller Delta-Skripte gegen die Live-DB trotz heterogener Datenbanklandschaft (Testen: HSQLDB, Live: MySQL) ausreicht, um den Server mit dem neuen Release direkt wieder hochzufahren.
Nach dem Release säubern wir dann den Release-Zweig von allen alten DB-Skripten, um die Übersicht zu bewahren.

Ich finds eigentlich auch sehr praktisch die SQL-Dumps (aka Scripts) im SVN zu bewahren. Dazu mach ich immer mit mysqldump einen Dump, der dann teils von Hand, teils automatisch von allen INSERTs befreit wird, die nicht für die nackte Start-DB bestimmt sind.
So hab ich neben dem Zugriff auf alte DB-Schemata auch ein Changelog, was sich an der DB-Struktur geändert hat.
Ansonsten alles wie meine Vorredner. Wir haben allerdings alles im SVN - Bilder, CSS, JS, PHP. SVN versteht sich auch gut mit Binärdateien.

Da ich alleine entwickle muss ich mir derzeit uzm Glück keinen Kopf um Sourcemanagement machen.
Tabellenänderungen mache ich grundsätzlich zum einen in meinen Create_Table.php's als auch in einer "alter_table.php", welche dann alle Änderungen seit dem letzten Deployment enhält.
Auf diese Weise geht nichts verloren.
Dateien komplett per FTP...klar - setzte aber voraus, das gerade die Datenbankmoduel automatisch erkennen, ob Sie auf dem Testserver oder dem Life-System laufen (wegen passwort, etc.) ;-)
Gruß
Alex

Original von CmdGabriel
Dateien komplett per FTP...klar - setzte aber voraus, das gerade die Datenbankmoduel automatisch erkennen, ob Sie auf dem Testserver oder dem Life-System laufen (wegen passwort, etc.) ;-)

Das löse ich ganz einfach so:

if(is_readable('/var/www/server')){

define('SERVER', true);
}
else{
define('SERVER', false);
}

if(SERVER){

$server = 'localhost';
$datenbank = '...';
$datenbank_benutzer = '...';
$datenbank_passwrot = '...';
}
else{
$server = 'localhost';
$datenbank = '...';
$datenbank_benutzer = '...';
$datenbank_passwrot = '...';
}
In den www-root eine leere Date gesetzt, die nicht per FTP übertragen wird, da ich damitmit nur auf die Unterordner zugreife

Original von CmdGabriel
Da ich alleine entwickle muss ich mir derzeit uzm Glück keinen Kopf um Sourcemanagement machen.
...
Gruß
Alex

das finde ich aber komisch - ich nutze selbst bei kleinerne projekte wo ich weiß das da nur ich dran arbeite svn
finde ich einfach bequemer den da brauch ich mich nur um ein zentrales backup kümmern

Original von woodworker

Original von CmdGabriel
Da ich alleine entwickle muss ich mir derzeit uzm Glück keinen Kopf um Sourcemanagement machen.
...
Gruß
Alex

das finde ich aber komisch - ich nutze selbst bei kleinerne projekte wo ich weiß das da nur ich dran arbeite svn
finde ich einfach bequemer den da brauch ich mich nur um ein zentrales backup kümmern
Dazu kommt dann noch die Versionierung. Ich kann immer eine funktionierende Version aus dem Hut zaubern und wenn man sich mal verrant hat, dreht man halt wieder gezielt zu einem bestimmten Punkt zurück.

Versionierung hängt eigentlich nicht mit mehreren Entwicklern zusammen. Tools wie SVN oder CVS sind kein Ersatz für Entwicklerkommunikation. Der Sinn (zumindest für mich) ist einfach der, dass ich mehrere Versionen pflegen kann.
Beispiel 1: ich hab Version 1.0 fertig und fange an Version 1.1 zu entwickeln. Während ich das tu wird in Version 1.0 ein Bug entdeckt. Also check ich mir die 1.0 aus SVN aus, fix den Bug und check den Fix als Version 1.0.1 wieder ein. Die Entwicklung von Version 1.1 wird davon nicht betroffen.
Beispiel 2: ich entwickel gerade an einer Version. Zwischendurch fällt mir (oder einem anderen Entwickler) ein Feature ein, dass aber längere Zeit zum Implementieren braucht. Also mache ich einen Branch (Nebenzweig) im aktuellen Versionszweig auf und implementier das Feature dort. Wenn es passt und für gut und funktionierend befunden wurde wird der Branch wieder mit dem Hauptzweig zusammengeführt. Ansonsten wird der Branch halt verworfen oder einige Zeit ruhen gelassen bis man sich wieder darum kümmern kann. So kann man auch eine große Änderung durchführen ohne damit die Entwicklung im Hauptzweig zu blockieren.
Oberflächlich kann man solche Sachen auch "händisch" erledigen. Für jede Version/Branch einfach eine Kopie des Sourcecodes auf die Platte legen. Bei 1-2 Versionen und einem Branch funktioniert das auch noch. Aber wenn du mal zwei Hauptversionen von denen jede noch 2-3 Unterversionen von denen jede eigene Patchlevel hat und gleichzeitig im Hauptzweig (und eventuell in einer anderen Version) noch mehrere Branches existieren funktioniert die "händische" Variante nicht mehr.
Dazu kommt noch das was Todi erwähnt. Es passiert halt manchmal, dass man einen oder mehrere Tage an etwas entwickelt und dann feststellt, dass es eigentlich Müll war. Ohne Sourcemanagement kannst du dann unter Umständen dutzende von Sourcefiles durchackern um alle Änderungen rückgängig zu machen. Mit Sourcemanagement check ich einfach die vorherige Version aus oder schmeiss den aktuellen Branch weg.
Ich benutze deswegen generell ein Sourcemanagement, egal ob ich alleine oder mit mehreren Entwicklern an dem Projekt sitze.

Ich benutze für das Ausliefern der Ruby Sourcen, und statischen Inhalten subversion (und mehr braucht das Spiel auch nicht). Wobei mein SVN-Server hier auf meinem PC läuft und auf dem Spiele-Server läuft nur ein Subversion-Client. Ist eine Version fertig und getestet, bekommt sie ein Tag und auf dem Spiele-Server kann man dann mit einem 'svn switch' den work space auf die neue Version umstellen. Dabei werden dann nur die geänderten Dateien übertragen. Änderungen im Datenbank-Schema werden von mir manuell in einer Datei namens update_schema.sql gepflegt. Dessen Inhalt muß dann mit dem begin einer neuen Version gelöscht werden. Hat leider den Nachteil, dass das Aktualisieren einer Version immer nur auf die nächste möglich ist. Wer hier ein Tool kennt, das vernünftig ein Diff auf DDL machen kann, kann mir da ja mal einen Tip geben.

besonders bei rails (soll aber angeblich auch bei allen anderen apps gehen) soll sich capistrano lohnen

Capistrano is a standalone utility that can also integrate nicely with Rails. You simply provide Capistrano with a deployment “recipe” that describes your various servers and their roles, and voila! You magically have single-command deployment. It even allows you to roll a bad version out of production and revert back to the previous release.

ich habs selbst noch nicht probiert aber es sieht sehr lecker aus

Capistrano ist eine feine Sache. Leider bin ich noch nicht dazu gekommen, mein Projekt darauf umzustellen. Man muss aber wissen, dass Capistrano eigentlich nichts anderes ist, als ein kleines Deployment-Script. man kann es vergleichen mit make, ant oder rake. Die "Magie" liegt eigentlich in dem, was bei Capistrano genutzt wird.
Als Basis nutzt es nämlich auch nur ein SVN-Repository, aus dem es den aktuellen Projektstand bezieht, um den Code auf dem Server zu beziehen. Für die Datenbankaktualisierung nutzt es die Rails Migrations. Migrations enthalten einfach nur versionierte Datenbankänderungen und Rails spielt immer die Änderungen ein, die eine höhere Versionsnummer haben, als der aktuelle Stand in der DB. Und am Ende werden noch die Konfigurationsdateien angepasst. Fertig.

Zur Entwicklung CVS ...
Nach diversen Tests wird der Code dann aus der Entwicklungsversion per FTP auf den Server geladen.