Der Firtz und ich

Als ich letztes Jahr begonnen habe, zu podcasten und mich mal informiert habe, wie man an die technische Umsetzung herangeht, stellte sich mir die Landschaft ungefähr zweigeteilt dar:

  1. Website mit Feed als Beiwerk (z.B. WordPress und ein Podcast-Plugin, das einem den Feed generiert)
  2. Feed mit Website als Beiwerk (z.B. DirCaster und irgend eine Lösung für eine Webpräsenz)

Ich kam damals zum Schluss, dass ich eher zu der Fraktion “Feed mit Website als Beiwerk” gehöre. Tools wie Auphonic gab es damalsTM noch nicht, das heißt damalsTM verbrachte nach Aufnahme und Schnitt das Audio noch viel Zeit auf dem eigenen Rechner, um encoded zu werden. Metadaten mussten auch noch in die Audiofiles, wobei viele Informationen eingetragen wurden, die später auch im Feed und in der Website vorkommen würden.

Daher machte ich mich damalsTM daran, möglichst viel davon zu automatisieren. Meine Vision war, ein Shellscript zu haben, dem ich nur das geschnittene WAV-File, sowie eine Textdatei mit den wesentlichen Metadaten und Inhalt für die Website vorlege, und das dann unter Verwendung von SOX encodiert, mit lltags und id3v2 etc. bei den Metadaten nachpflegt, den Feed erzeugt, HTML erzeugt und per curl alles hochlädt, wo es hingehört.

Ich habe auch begonnen, mir so ein Shellscript zu programmieren, dann hat aber Tim Pritlove zuerst eine Umfrage bei Podcastern durchgeführt und angekündigt, dass aus seiner Ecke etwas kommen würde, was endlich ein anständiges Podcast-Tool sein würde, und das auf WordPress aufsetzen würde.

Im Vertrauen, dass der Mann weiß, wovon er redet, habe ich mein Shellscript dann nur für den ganzen Encoding-Kram zu Ende geschrieben, mir ein WordPress mit PodPress aufgesetzt, meinen ersten Podcast an den Start gebracht.

Und es hat sich gelohnt, der Podlove Publisher, der aus dem von Tim initiierten Podlove-Projekt hervorgegangen ist, ist einfach ein feines Stück Software, das ich seit Version 1.1.21-alpha produktiv beim Troja Alert einsetze, und sehr zufrieden bin.

firtz

Trotzdem hat mich der Gedanke, dass mir eigentlich der “Feed mit Website als Beiwerk”-Ansatz näher liegt, nie losgelassen. Und dann kam der Christian von der Hörsuppe irgendwann mit dem Firtz um die Ecke und ich war angefixt.

Als ich mich dann mit meinen dritten Podcast Rausgehauen konfrontiert sah, war die Gelegenheit, mit dem Firtz herumzuspielen, gekommen.

Auch wenn sich für Spoiler Alert und Troja Alert inzwischen durchaus Use Cases ergeben haben, in denen so ein ganzes WordPress berechtigt ist, macht mir das Nutzen des Firtz einfach große Freude! So will ich das haben.

Wie grundsätzlich der Workflow beim veröffentlichen eines Podcasts mit dem Firtz aussieht, hat Christian in seinem produktbegleitenden Podcast und in der Dokumentation des Firtz gut beschrieben. Da will ich Euch jetzt keine Dopplungen zumuten.

Ich kann mir aber vorstellen, dass die Frage von Installation und Wartung durchaus eine Hürde darstellt. Deshalb hier kurz eine Schilderung, wie ihr Euren Firtz sinnvoll auf dem neusten Stand halten könnt.

Installation und Update des Firtz mit git und git-ftp

Ich erkläre hier nicht die Einstellungen, die grundsätzlich im Firtz vorgenommen werden müssen, um den eigenen Podcast einzupflegen. Die Doku, die Christian dazu angefertigt hat ist leicht verständlich und auch recht vollständig. Damit werdet ihr zurechtkommen.

Falls Ihr dort nicht auf alle Fragen Antworten findet, ist Christian auf app.net oder Twitter sehr hilfsbereit, und auch mich könnt ihr gerne auf app.net oder Twitter ansprechen.

Installation

Grundsätzlich ist die Installation des Firtz fix gemacht. Eigentlich muss man nur alle Dateien, die im Firtz-Repository liegen auf seinen eigenen Webspace schaufeln, seine eigenen Daten und Einstellungen in der feed.cfg vornehmen, das war’s. Ich schlage jedoch vor, git-ftp zu verwenden.

Zumindest zur Zeit (April 2013) ist relativ viel Bewegung im Code. Christian fixt viele Bugs und fügt noch weitere Features hinzu. In der Zukunft, wenn mal ein wenig mehr Code-Stabilität erreicht ist, wird seltener ein Update nötig sein, aber aktuell will man nicht auf Versionssprünge warten, sondern seinen Firtz sehr up-to-date-halten.

Glücklicherweise geht das sehr leicht, wenn man git verwendet. Praktischerweise entwickelt Christian das ganze auf Github. Wenn Ihr Shellzugang zu dem Server, auf dem Euer Webspace liegt, habt, kann man bestimmt elegantere Workflows machen, aber ich gehe jetzt mal davon aus, dass Ihr (wie ich) FTP-Zugang habt, und das war’s.

Ihr installiert Euch git und git-ftp (Installationsanweisungen).

Dann zieht Ihr Euch erstmal den aktuellen Stand des Firtz auf Euer Rechengerät:

git clone git://github.com/eazyliving/firtz.git

Ich halte es für sinnvoll, dann einen Branch für den eigenen Podcast anzulegen. Den branch könnt ihr benennen, wie ihr wollt. Der Einfachheit verwende ich das Supicast-Beispiel, das Christian in der Doku des Firtz auch verwendet. Wir nehmen also an, Euer Podcast heißt Supicast. Ich nenne dann den Branch auch so.

git branch supicast

Dann wechseln wir in diesen Branch:

git checkout supicast

Jetzt kommen die Einstellungen für den eigenen Podcast. Am einfachsten ist es, die Demo-Dateien umzubenennen und entsprechend zu bearbeiten.

Im Ordner feeds findet Ihr einen Ordner namens demo. Den benennt ihr um in supicast und bearbeitet die Datei feed.cfg nach Euren Bedürfnissen und anhand der Doku des Firtz.

Jetzt kommt git-ftp ins Spiel. Am komfortabelsten ist es, einige Zugangsdaten in die Konfiguration Eures lokalen git-Repositorys von Firtz abzuspeichern:

git config git-ftp.url ftp://host.adresse/eures/webspace/pfad/wo/firtz/liegen/soll
git config git-ftp.user euerFTPusername
git config git-ftp.password euerFTPpasswort

Sinnvoll ist es m.E. auch, git-ftp mitzuteilen, welche Teile des Firtz nicht auf Euren Server sollen, um Platz und Traffic zu sparen. Dazu Eurem Lokalen Firtz-Ordner die Datei .git-ftp-ignore anlegen und folgenden Inhalt einfügen:

.gitignore
doc/*
changelog.txt
README.md

Dann kommt die erste Initialisierung:

git-ftp init

Damit lädt git-ftp Euren Stand von Firtz (also den Branch supicast) auf den FTP-Server. Fertig.

Update 1: Was ist, wenn ich etwas an meinen Einstellungen verändere?

Wenn Ihr etwas verändert, neue Folge, das CSS der Website aufhübschen, was auch immer, wird das ganze erstmal in Euer git-repo “committed”.

Falls neue Dateien hinzugekommen sind:

git add .

Dann der eigentliche Commit:

git commit -a -m "Kurze Beschreibung der Veränderung."

Jetzt muss das ganze auf den Server:

git-ftp push

Jetzt nimmt git-ftp nur die Änderungen vor, die sich seit Eurem letzten Upload verändert haben. Git sei Dank weiß es ja, welche Dateien neu sind, welche gelöscht wurden, und welche hinzugekommen sind. Genau diese Operationen führt es auf dem FTP-Server jetzt durch. Fertig.

Und wenn sich am Firtz etwas verändert?

Wenn Christian ein Update gemacht hat, wechselt Ihr wieder zu Eurer jungfräulichen Variante des Firtz:

git checkout master

Und holt Euch den aktuellen Stand:

git pull

Euer Branch “master” ist jetzt aktuell. Also zurück zu Eurer Arbeitskopie, dem Branch supicast:

git checkout supicast

Dann die Veränderungen in Euren Branch übernehmen:

git merge master

Hier schlägt Euch git eine Standard-Commit-Message vor, die Ihr einfach übernehmen könnt. Fertig!

In der Regel sollte es hier keine Schwierigkeiten geben, da Ihr eigentlich nur Änderungen in Eurem Verzeichnis feed/supicast vornehmt. Wenn Ihr woanders Änderungen vornehmt, gehe ich davon aus, dass Ihr wisst, was Ihr tut und auch mit entsprechenden Merge-Konflikten umgehen könnt.

Dann kommt das ganze wieder auf den Server:

git-ftp push

Firtz-Upgrade erledigt! Tadaa!!

Optional: Testumgebung

Wenn Ihr gerne eine Möglichkeit hättet, mit dem Firtz ein bisschen rumzuspielen bzw. Updates erst zu testen, bevor Ihr sie auf den eigentlichen Server packt, gibt einem git und git-ftp da ein paar nützliche Möglichkeiten in die Hand.

Wenn Ihr gerade in Eurem supicast-Branch seid erstellt Ihr einen Kopie davon als weiteren Branch und nennt ihn z.B. supitest.

git branch supitest

In git-ftp legt ihr dann ein sogenanntes Scope an, das sind alternative FTP-Zugangsdaten, die genau für solche Fälle gedacht sind.

git config git-ftp.supitest.url ftp://host.adresse/eures/webspace/pfad/wo/die/Testumgebung/liegen/soll
git config git-ftp.supitest.user euerFTPusername
git config git-ftp.supitest.password euerFTPpasswort

Hier müssen nur die Angaben gemacht werden, die von Eurem regulären Setup abweichen. Wenn ihr z.B. mit dem Selben Usernamen und Passwort zugreift, aber das ganze in einen anderen Ordner Eures Webspace schiebt, reicht es für das Scope supitest nur den Wert git-ftp.supitest.url anzugeben, und die anderen weg zu lassen.

Wenn ihr nun etwas testen wollt, dann wechselt ihr in Euren supitest-Branch:

git checkout supitest

Macht Eure Änderungen und committet sie:

git add .
git commit -a -m "Mal was ausprobieren."

Und dann ladet sie dann in das Scope supitest hoch.

git-ftp push -s supitest

Dann guckt Ihr Euch die Website an, ob ihr mit dem Ergebnis zufrieden seid. Wenn ja, gilt es, das ganze in Euren Produktions-Firtz zu übertragen.

git checkout supicast
git merge supitest
git-ftp push

Tadaa!!

5 Gedanken zu “Der Firtz und ich

  1. Gern geschehen. Ich freu mich auf das, was da kommen wird…

  2. Mal noch ‘ne Frage: Was passiert denn, wenn ich z.B. in der index.php ‘ne Zeile hinzufüge? Aktuell sieht’s so aus, als würden die beiden Versionen der Datei bei einem Update gemerget – kann das sein? Bzw. hast Du irgendwo noch eine Ressource, wie ich Merge-Konflikte auflösen kann?

  3. Das war jetzt vielleicht nicht ganz Dein Ansinnen, aber ich habe aktuell im Zuge einer Neuinstallation des Macs mal eine Alternative ausprobiert, die etwas mehr GUI bietet: Via Github-App klone ich mir das Repository vom Firtz auf den Mac in ein Verzeichnis meiner Wahl. Und mit dem FTP-Programm Transmit synchronisiere ich dann einfach diesen Ordner mit meinem Server. Änderungen im Firtz gelangen über einen Github-Sync im lokalen Verzeichnis und dann auf beschriebenen Weg auf dem Server. Funktioniert tadellos und ist vielleicht ein Weg für Leute (wie mich), die das Terminal etwas respektvoll behandeln.

Kommentar verfassen