Es ist ein fork von einem virtualhost create script und macht folgendes:

– holt den letzten symfony 1.4 stable release via svn
– setzt alle notwendigen rechte zB auf den cache folder
– bereitet die datenbank vor
– legt eine app an
– macht eine .gitignore
– und ruft das virtualhost creator script auf, was den vhost anlegt auf “web”

Einfach im Verzeichnis wo die scripte liegen:

./symfony_installer.sh myproject

… durchhangeln und dann auf http://myproject.local aufrufen

Entfernen kann man das Projekt inkl. virtual host auch wieder:

sudo ./virtualhost --delete myproject.local --symfony

… kommt vielleicht 2 Jahre zu spät ;)

git prompt – GIT repository status direkt im shell prompt.

nützlich und schön bunt.

#wipe old version of build db
mysql -uUSER -pPW drop build-db

#wipe the build workspace
rm -rf ./build-workspace

#checkout the sourcecode
git clone git@my-domain.com:my-repository ./build-workspace

cd build-workspace

#(re)configure database for build server
php ./symfony configure:database "mysql:host=build-db-server;dbname=build-server-sql-user"

#(re)build db
php ./symfony doctrine:build-db

der Einfachkeit halber liegt der zu migrierende sql dump schon im repository.
Könnte man natürlich auch jetzt von remote holen.

#import some test data
mysql -uUSER -pPW --force database_name < data/sql/some_data_to_migrate.sql

hier sollte keine Handarbeit mehr nötig sein,
da man ja alle DB Änderungen per doctrine migrations gemacht hat.
Im Gegensatz zu schema Änderungen bleibt man so abwärtskompatibel zu Vorgängerversionen.

#migrate the test data / db if necessary
php ./symfony doctrine:migrate

zum guten Schluss alles testen

#run test, save results as xml
php ./symfony test:all -xml=path/to/results.xml

Es lohnt sich in mehrfacher Hinsicht wirklich das komplette Projekt inkl. DB automatisiert von 0 installierbar zu machen.
Auch wenn es vielleicht erstmal nur auf ein paar Instanzen laufen soll.

Man kann erstens bei verteiltem Arbeiten schnell mal eine weitere Arbeitskopie auf einem anderen Rechner erstellen.

Zweitens kann man relativ einfach ein continuous integration setup auf die Beine stellen und sofort ruhiger schlafen ;)

Außerdem kann man ständig die Migration von aktuellen Live Daten, oder einer Vorgängerversion in die Entwicklungsversion testen.
“Continuous Migration” ;)

Wir legen uns das remove.ed Skript an:

“%” steht für in der ganzen Datei,
“s” wie search
“,mein langer satz den ich loswerden möchte,,” ersetzen durch “nichts” hier könnte zwischen dem 2. und 3. Komma auch “mein neuer satz stehen”.
“g” greedy – ersetzt alles… nicht nur den erst besten Hit.
“w” schreiben
“q” feierband / quit

jetzt der voodoo: suche alle Dateien und ersetze es mit den Angaben von Ed. (Aus unserer remove.ed)

erstmal testen:

Wenn aufm Bildschirm eine entsprechend lange Liste mit den richtigen Pfaden und Dateien auftaucht, prima! So in etwa:

jetzt abfeuern – das gleiche wie eben, nur das wir mit der letzten Pipe das ganze an die bash übergeben, denn die Ausgabe oben sind gültige Shell Befehle.

Und knick knack – weg sind sie!