Netzpiraten

Für das Deployment des Radiant CMS verwende ich schon seit längerem Capistrano und bin auch sehr zufrieden damit. Nachdem nun auch schon einige Seiten damit produktiv sind, bin ich immer häufiger über die gleiche Aufgabe gestolpert wenn eine Weiterentwicklung anstand:

1. Produktive Datenbank dumpen
2. Dump und Assets auf die lokale Maschine kopieren
3. Datenbankdump einlesen
4. Entwickeln
5. Lokale Datenbank dumpen
6. Dump und Assets auf die Stagingumgebung kopieren
7. Datenbank einlesen
8. Kunden informieren
9. Datenbankdump und Assets auf die Produktivumgebung kopieren
10. Datenbankdump einlesen

Uff… jedes Mail ziemlich viel repetitive Arbeit. Da ich minimalistisch veranlagt bin, habe ich natürlich eine Lösung gesucht um mich wieder auf die wesentlichen Dinge konzentrieren zu können. Dabei rausgekommen ist mein…

Capistrano Sync Rezept

Installation

Für die Installation muss man das Rezept einfach nach lib/recipes in die Ruby on Rails Applikation kopieren und in das Capfile folgende Zeile einfügen:

Dir['lib/recipes/*.rb'].each { |receipe| load(receipe) }

Konfiguration

In der Deploykonfiguration config/deploy.rb können nun zwei Einstellungen vorgenommen werden:

set :sync_directories, %w(assets)
set :sync_backups, 3

Mit sync_directories werden die Verzeichnisse definiert, welche man zwischen den Umgebungen synchronisiert haben möchte - ‘assets’ ist dabei auch gleich die Defaulteinstellungund kann beliebig erweitern werden (z.B. mit ‘galleries’). sync_backups definiert die Anzahl der Backups welche auf dem System behalten werden, doch mehr dazu später.

Für den Zugriff auf die Datenbank liest das Rezept die lokale config/database.yml Datei, wesshalb dort dann auch die Zugriffsdaten der Datenbank aller Umgebungen eingetragen werden müssen. Dies ist ja kein Problem, da diese Datei sowieso schon im .gitignore eingetragen ist und nie eingecheckt wird, oder?

Für das Reibungslose deployment sollte man natürlich die Public-Key SSH Authentifizierung eingerichtet haben.

Sync!

Da in einer Multistageumgebung x Umgebungen vorhanden sein können, gibt es keine Kommandos für eine direkte Synchronisation zwischen den Umgebungen. Es muss immer via die lokale Entwicklungsumgebung synchronisiert werden.

Das zu Beginn beschriebene Synchronisationsszenario sieht nun mit dem Capistrano Rezept folgendermassen aus:

1. cap production sync:down
2. Entwickeln
3. cap staging sync:up
4. Kunden informieren
5. cap production sync:up

Das ist also schon definitiv etwas schneller… Der Task sync:down ruft übrigens lediglich die beiden tasks sync:down:db und sync:down:fs auf. Es ist also mit diesen Tasks auch möglich, nur das Dateisystem oder die Datenbank zu synchronisieren, wie uns das Kommando ‘cap -T’ zeigt:

cap sync:down
cap sync:down:db
cap sync:down:fs
cap sync:setup
cap sync:up
cap sync:up:db
cap sync:up:fs

Abhängigkeiten

Das Rezept benötigt rsync für die Synchronisation der Dateien, damit nur immer die Differenz und nicht jedesmal alle Dateien synchronisiert werde. Auch wird der Datenbankdump mit mysqldump gemacht, wesshalb im Moment die Datenbanksynchronisation nur mit MySql läuft. Die Faulheit welche mit zum Schreiben des Rezeptes veranlasst hat, verhindert eben auch gleichzeitig die Entwicklung von Features welches ich selber im Moment nicht benötige

Backups

Da ich unter einer angeborenen Datenverlustsparanoia leide, musste natürlich auch ein Backupmechanismus her. Dazu wird das Verzeichnis ‘shared/sync‘ beim deploy:setup task automatisch angelegt. In diesem Verzeichnis werden nun die erzeugten Datenbankdumps abgelegt und beim Hochladen eines DB-Dumps wird vor dem Einlesen noch zusätzlich ein Dump auf der Umgebung erstellt bevor der hochgeladene Dump eingelesen wird.

Auch bei der Synchronisation von Verzeichnissen auf die Umgebung wird vorher ein Archiv erstellt und abgelegt - sicher ist sicher

Ein Task für ein Rollback existiert nicht - bei einem Fehler ist dann einfach Handarbeit angesagt.

Happy syncing!

Lesezeichen