Der erste Teil bzw. die Einleitung zur Serie kam schon mal ganz gut an und viele sind gespannt, wie es weiter geht. Das freut mich ungemein und motiviert natürlich weiter zu schreiben. Aber ich erzähle euch ein Geheimnis: Ich bin genau so gespannt wie ihr 😀 Nun aber mal Schluss mit den leeren Worten und ran an den Speck. Heute möchte ich noch etwas theoretisch bleiben und ganz vorne anfangen. Denn bevor man sich einen guten Workflow zusammen stellen kann sollten wir mal gucken, was Workflow eigentlich bedeutet.
Der Workflow
Also was ist ein Workflow überhaupt und warum brauche ich so etwas? Wikipedia definiert „Workflow“ wie folgt:
Ein Arbeitsablauf (englisch: workflow) ist eine definierte Abfolge von Aktivitäten in einem Arbeitssystem einer Organisation.
Ok, das klingt ja schön und gut, aber wie so immer sind solche Definitionen immer allgemein gehalten und von Entwickler lese ich jetzt hier nichts raus. Denn da ist schon der erste Knackpunkt. Wir müssen uns bewusst machen, was eigentlich unsere Arbeitsschritte sind und wie wir sie ausführen. Zudem kommt hinzu das viele Schritte in einem Workflow abhängig von einander sind. Bevor ich die fertige Webseite meines Kunden auf den Server hochlade muss ich sie erstmal erstellen. Klingt komisch, ist aber so.
Ein andere wichtiger Punkt ist: In der Definition steht nichts von Automatisierung. Das ist ganz wichtig. Denn ein Workflow definiert lediglich die Schritte und ordnet sie in eine sinnvolle Reihenfolge an. Wie die Schritte ausgeführt werden ist für den Workflow an sich relativ uninteressant. Für mich als Web-Worker spielt Automatisierung aber natürlich eine große Rolle und so fern es geht versuche ich meine Schritte dahin zu bringen. Ein manueller Workflow, beim ich alle Schritte selber ausführen muss, ist zwar möglich aber nicht gerade bequem und wenn ich Dinge automatisieren kann, indem ich z.B. Skripte schreibe oder Tools nutze, dann erleichtert es mir die Arbeit.
Von der Idee bis zur Webseite
Ich habe bereits erwähnt, dass es nicht den einen Workflow gibt und das die Schritte und somit der Arbeitsablauf stark vom Ziel abhängen. Das klingt logisch, aber wird doch sehr oft außer Acht gelassen. Man sieht es (leider) so oft, dass für verschiedene Aufgaben immer wieder die selben Tools genutzt werde nur weil man sie ja kennt. Oftmals wird gar nicht darüber nachgedacht, ob es vielleicht sinnvoller wäre seinen Workflow zu überdenken, da für die neue Aufgabe andere Tools und Schritte nützlicher wären. Daher sollte man immer das Ziel vor Augen haben um die entsprechenden Werkzeuge mit zu nehmen auf die Reise. Wenn ich eine Alpen Überquerung plane, dann gucke ich schließlich auch, dass ich festes Schuhwerk, einen vernünftigen Rucksack und genug Proviant dabei habe. Ich gehe nicht auf die Tour mit Flip-Flops, denn schließlich hat das ja gut geklappt auf der Wanderung um die Insel in der Nordsee. Deshalb lasst uns erstmal gucken wohin die Reise geht um dann zu schauen welche Schritte ich dafür betrachten muss / sollte.
In dieser Serie entwickeln wir gemeinsam einen Workflow für eine Kunden-Webseite. Unser Szenario ist daher folgendes: Ein Kunden möchte von einem Freelancer eine (WordPress-)Seite haben. Sprich, wir entwickeln die Webseite lokal auf unserem Computer und am Schluss muss es auf einem Server gepackt werden, damit die Seite über den Browser aufrufbar ist. Ich weiß, das klingt jetzt ziemlich banal und für viele ist das klar, aber ich übertreibe hier ganz bewusst um die Aufgabe komplett zu erschließen und in kleine Teile zerlegen zu können.
Fangen wir gemeinsam ganz vorne an und arbeiten uns bis nach hinten durch um so viele Teilaspekte herauszufiltern wie möglich. Diese Schritte werden wir dann im Detail in den folgenden Artikel näher beleuchten.
1. Lokale Entwicklungsumgebung
Die lokale Entwicklungsumgebung bildet unseren Rahmen, damit wir überhaupt lokal arbeiten können. Dazu zähle ich nicht nur den Text Editor (oder IDE) in dem wir Code schreiben, sondern auch den lokalen Server oder eine VM. Gerade wenn wir fürs Web entwickeln benötigen wir einen lokalen Server um unsere Arbeit auch angucken zu können. (Außer ihr seid Chuck Norris – Chuck Norris kann ohne einen lokalen Server eine Webseite fehlerfrei programmieren.)
2. Versionierung
Wenn wir programmieren ist es immer gut sich über eine Art der Versionierung Gedanken zu machen. In der Regel wird hier git genommen, aber andere sind genau so gut. Hauptsache ihr versioniert euren Code. Es ist auch sinnvoll zu überlegen, wie die Projekt-Struktur aussehen kann und sich jetzt schon Gedanken zu machen welche Dateien wir versionieren, welche wir später auf den Server packen und welche Dateien wir womöglich über Dependency-Manager holen können.
3. Deploy
Mit dem Deploy sind wir dann schon soweit, dass wir der Meinung sind unser Code darf auf einen Webserver. FTP ist wohl den meisten ein Begriff, aber an dieser Lösung stören mich viele Dinge. Daher gucken wir uns eine mögliche Alternative an, wie wir mit SSH unsern Code ausliefern. Eine interessante Möglichkeit bietet auch die Idee von Rollbacks. Damit ist gemeint, dass wir jederzeit ohne Aufwand zu einem früheren Stand zurückkehren können. Wie das genau aussehen kann schauen wir uns später an. Wenn es zudem sehr wichtige Projekte sind können wir in diesem Schritt auch noch überlegen eine zusätzliche Stage einzubauen: Eine Zwischenebene bevor die Webseite final Live geht, damit sich der Kunde vorher versichern kann, dass alles stimmt.
4. Projekt Abschließen
Dieser vierte Punkt ist weniger ein eigener Arbeitsschritt, mehr ein sich Gedanken machen, was kommt danach. Wenn ein Projekt abgeschlossen ist 05und neue Projekt stehen vor der Tür, dann möchte man vielleicht wieder Platz machen auf der Platte. Daher möchten wir am Schluss kurz mal über alles gucken und schauen uns an was man wie sinnvoll löschen kann ohne sein Projekt komplett zu zerstören.
Fazit
Wir haben uns nun einmal klar gemacht, was Workflow eigentlich bedeutet und das man immer vom erwünschten Endergebnis ausgehen sollte um nicht am Ziel vorbei zu schießen. Anhand einer Kunden-Webseite haben wir nun vier Teilbereiche definiert: 1. eine lokale Entwicklungsumgebung, damit wir vernünftig arbeiten können; 2. Versionierung, damit kein Fortschritt verloren geht; 3. Deploy, um unsere Arbeit auch zeigen zu können und 4. das Abschließen des Projekts.
Im nächsten Teil fangen wir mit der lokalen Entwicklungsumgebung an. Ich möchte euch zeigen, was ich nutze und für mich funktioniert.