 Einfach immer wieder Dinge, die man verbessern kann. Es gibt immer wieder Ecken, wo man anstößt und genau davon lebt so ein Workflow. Continuous Indication, immer weiter verbessern. Deswegen seht das Ganze nicht als eine eiligende Wollmilch-Sau an, sondern als ein Ideengeber, als ein Proof of Concept. So kann man es machen, muss man aber nicht. Getting started. Das waren eigentlich quasi schon meine Vortragspolien und jetzt steigen wir gleich auch richtig ein. Und wir setzen das Ganze mal auf. Wir stellen uns das faktiveste Szenario vor. Ich kriege einen Anruf von einem Kunden, er möchte eine Webseite haben. Zum Beispiel möchte er einen neuen Podcast starten über die netten Vapus und er braucht jetzt dafür eine entsprechende Webseite. Jetzt fängt eben meine Story an, wie gehe ich als Entwickler daran? Ich habe mir in diesem Zuge verschiedene Dinge zur Eigengemacht. Ich habe zum Beispiel angefangen, Vagrant zu nutzen. Wer Vagrant nicht kennt, das ist ein Tool, mit dem ich virtuellen Maschinen konfigurieren kann und wiederverwenden kann. Darüber habe ich auch selber schon Talk gehalten, findet ihr auf WordPress.tv. Soviel müsst ihr nur wissen. Vagrant ist ein Tool, das auf VirtualBox aufsetzt und ich habe hier eine Konfigurationsdatei mir erstellt, die ich für meine Zwecke jetzt abgewandelt habe auf WordPress. Was ich eben jetzt tue ist, ich werde Vagrant nutzen mit einigen Plugins, nämlich HostUpdater und HostManager, welches mir hilft bei den Domainverwaltung. Ich werde WordPress installieren und das zeige ich euch jetzt einfach mal, wie ich das zum Beispiel angehe. Ich habe mir das Open Source hier auf GitHub gestellt und wenn ich jetzt eine neue, ein komplett neues Projekt brauche, kann ich auf der Kommandozeile einfach sagen, ich lohne mir das Projekt von GitHub, wenn ihr Entwickler seid, sind das normale Tools, die ihr ja täglich nutzt. Gehe in diese Maschine und sag einfach nur Vagrant ab und jetzt werden wir sehen, die ganze Maschine bootet hoch, da ich, wenn man das noch so alle erst mal macht, wird jetzt Scotchbox, das ist eine Basisbox oder ein Betriebssystem, alles schon fertig gepackt, auf den setze ich auf, da es ist ein Ubuntu, das da drin läuft. Darin ist schon Apache installiert, da ist eine MySQL Datenbank schon fertig. Es sind genau die Tools schon vorinstalliert, die wir als Entwickler brauchen und genau diese Schritte muss ich ja nicht jedes Mal wiederholen, sondern die möchte ich am besten automatisieren, mit zum Beispiel Vagrant, was ich hier persönlich mache. Ich habe mir also diese Box gebaut, damit ich diese Schritte nicht wiederholen muss. Während das jetzt im Hintergrund lädt, ich mach kurz noch mal auf die Webseite, was ich mir jetzt in den Schritt noch ein bisschen genauer angeguckt habe, ich habe nicht nur, ich installiere mich nicht nur Apache und MySQL, sondern ich habe mir auch ein paar Provisioning-Scripps geschrieben und ein paar Konfigurationen erstellt, die mir das Arbeiten mit WordPress erleichtern. Denn mein Hintergedanke war, ich möchte nicht eine VM für eine Webseite haben, sondern ich möchte auf einer VM mehrere Webseiten laufen lassen. Weil meine Projekte sind generell so generisch, dass ich da nicht auf eine ganz bestimmte PHP-Version achten muss und ich muss nicht noch zusätzliche Java-Programme installieren, die der Kunde möchte, sondern bei mir ist es ein relativ einfaches WordPress-Projekt und deswegen nutze ich mir, nutze ich das aus, dass ich mir auch Ressourcen schone. Sprich, ich habe mir jetzt hier in den Provisioning Ordner Skripte gebaut, Shell-Skripte, die mir helfen, die beinahe Erstellung einer neuen Webseite diese langriegenden Prozesse einfach zu optimieren. Ich werde es auch gleich zeigen, wenn ich, das passen wir noch ein eben, was es jetzt nämlich macht, es hat die Box runtergeladen und ich habe hier schon eine Domain-Sample-Cast-Local erstellt, die wird beim allerersten Mal laden schon automatisch für euch mitinstalliert. Das Skript wird diese Domain in meine lokale Hostdatei schreiben, dass ich die Nacher in meine Proze eingeben kann und es fängt an, ein WordPress-Repository runter zu laden. Es beginnt mit Composer zu arbeiten, das sind alles Schritte, auf die ich gleich weiter angehen werde. Es beginnt die VHOS-Dateien einzutragen für den Apache, es beginnt eine Datenbank einzustellen, die Config-Datei von WordPress zu editieren, eben diese Dinge, die man für jede neue WordPress-Seite eigentlich neu machen muss. Also habe ich mir das automatisiert, damit ich das eben nicht manuell machen muss. Was ihr jetzt seht, das sind alles noch Composer-Sachen und das ist nämlich der zweite Schritt. Während das lädt, gehe ich schon einen Schritt weiter, um die Zeit effektiv zu nutzen. Und zwar, was diese Vacrant-Box macht, ist, sie nutzt ein weiteres Repository, was ich mir erstellt habe. Ich habe mir nämlich nicht nur Gedanken gemacht zu der lokalen Entwicklungsumgebung, für die ich ja Vacrant nutze, sondern wie kann ich auch WordPress sichernutzen? Wie kann ich das in mein Workflow integrieren, dass ich das nicht immer neu manuell runterladen kann? Kann ich vielleicht noch die Struktur verbessern, um das in Git zu speichern? Und was eben eines dieser Provisioning-Scripts tut, ist, hier, es greift auf dieses Repository zu, WordPress Project Template. Das WordPress Project Template habe ich ganz nah an einem Post von Delicious Prains angelehnt. Das ist eine kanadische WordPress-Firma und die haben einen sehr schönen Beitrag, ein Blog-Beitrag geschrieben, wie sie erklären, wie man Composer unter anderen WordPress-Projekten nutzen kann. Und der Link ist nachher in den Show-Nutze, sage ich schon, in meinem Blog-Beitrag. Was ich jetzt hier quasi mache, ist, ich habe das ein bisschen aufgesplittet, mein Template, und es sieht nicht mehr wie ein typisches WordPress-Repository aus, sondern es ist ganz stark mit Composer verknüpft. Was ist nun Composer? Composer ist ein Dependency-Manager für PHP. Damit kann ich Pakete laden, die ich die andere schon programmiert haben, und kann sie mir über eine Composer JSON-Datei einspeichern. Teile ich gleich ein Groß. Jetzt kurz, alles klar. Composer, da trage ich dann die Dinge ein, die ich brauche, wie zum Beispiel WordPress, bestimmte Plugins, bestimmte Themes, und ich trage die einfach nur einmal ein, und sie werden mir von Composer automatisch runtergeladen. Um das ein bisschen zu optimieren, um diese Git-Struktur nicht zu verwursten und nicht WordPress komplett in Git zu speichern und auch nicht die Themes und Plugins in Git zu speichern, weil das würde das Ganze nur aufblähen, habe ich das Ganze ein bisschen entkoppelt und speichere nur die Dinge in Git, die ich wirklich brauche. Jetzt nochmal ganz kurz einen Schritt zurück. Die Installation ist fertig. Was wir jetzt machen, was wir jetzt alles haben, ist, das Procedural Script ist durchgelaufen, Composer ist fertig, SampleCast Local ist installiert, und das wird der erste Test zur Live-Demo. Wenn alles klappt, sollte ich hoffentlich SampleCast Local aufrufen können und zack, eine WordPress Installation ist ready. Ich kann mich jetzt hier durchklicken, meine Webseite erstellen. Okay, das ist schon der erste Live-Demo-Fehler. SampleCast, atmen ein Passwort, bitte nicht live nachmachen. Ich mache es jetzt nur für diese Demotswecke. So, passwort. Somit habe ich jetzt einfach und schnell meine erste lokale Webseite schon installiert. Die Vacrant Box läuft im Hintergrund, wie ihr seht. Ich habe meine Domain, ich muss also nicht eine komische IP-Adresse eingeben und das macht mir alles Vacrant. Das ist schön, das ist komfortabel und genau das kann ich jetzt optimieren, was ich vorhin meinte. Wenn ich jetzt nämlich sage, ich möchte halt nicht sagen wir SampleCast.local, das ist halt ein Testprojekt, was ich erstellt habe. Aber jetzt brauchen wir ja eine Webseite für unseren Kunden. Das soll ja komplett eine eigene Seite sein. Was ich eben mache ist, ich schau mal kurz mal in die Struktur. Ich habe hier mein Config und Provisioning Ordner und in der Config liegt eine Datei, die heißt Host.list und die enthält einfach nur in Klartext Domainnamen und darüber gehe ich. Für jede Zeile, die ein Domainnamen enthält, wird ein neues WordPress-Projekt erstellt, sofern es nicht existiert. Und das zeige ich auch noch ganz kurz. Was ich jetzt eben mache, ich sage, unser Projekt heißt HAPU Factory.local. Ich kann auch ein alias noch einsetzen. Über den könnte ich dann das Projekt in mein Proser auch aufrufen. Jetzt steht das zwar da drin, aber noch ist nicht viel passiert. Was ich tun muss, ist ein Vacrant Provisioning, das ist ein Befehl von Vacrant, damit der stößt diese Shellscript noch mal an und macht genau das, was ich ihm ja gesagt habe. Ich sehe hier Creating Directory für HAPU Factory und es passiert genau dasselbe, was eben im Hintergrund lief. Es erstellt wieder den Ordner, es lädt dieses WordPress Project Template herunter, initialisiert es, lädt Composer, das ist derzeit noch der aufwendigste Teil, dauert einfach länger. Er stellt mir die Datenbank, editiert meine Confect Datei, schreibt da die lokalen Datenbankinformationen rein und wenn es alles läuft, kann ich dann gleich auch über HAPU Factory.local drauf zugreifen. Gerade läuft es noch nicht, jetzt ist noch nicht alles geladen. Warten wir kurz ab nochmal. Das ist Simsalabim, es läuft und ich kann jetzt nun für meinen Kunden anfangen, WordPress lokal zu entwickeln. Das ist schon mal ein ganz angenehmer Schritt und somit habe ich mir den ersten Teil meines Wirkfluchs schon mal optimiert, dass ich schnell einfach eine neue Webseite erstelle, um Kundenlösungen zu erstellen lokal zu entwickeln, dass ich mir einfach bequem auch was ausprobieren kann. Das heißt, wenn ich ein neues Plug-in zum Beispiel programmiere und ein drittes Plug-in in Review, sag eine fehlfertig und ich habe eine neue Webseite, die nichts anderes behindert. Das sind so die ersten zwei Schritte. Ich habe nun meinen WordPress hier, ich habe im Hintergrund, wir können kurz mal reinschauen, ich habe nun samplecastlocal, WAPU Factory, das sind meine Projektordner und da habe ich genau diese Struktur, die wir eben im Git sehen. Ich habe meine Composer-Datei, ich habe ein Deploy, das ist der letzte Schritt, den ich euch zeige. Ich habe eine Local-Config-Datei, die wird nicht in Git beschweichert. Da stehen meine lokalen Datenbankinformationen drin. Die haben nichts irgendwo online zu suchen, hätten sie auch eh keinen Zeck, aber für mich lokal schalte ich halt, die brauche ich diese Datenbankinformationen, schalte mir das Debugging ein, alles easy-peasy. Ihr seht einen typischen Wendorordner für ein Composer, falls ihr mit Composer bereits gearbeitet habt und nun möchte ich euch kurz zeigen, wie das nochmal genauer aussieht. Dazu wechsle ich mal in PHPStorm und zeige euch verschiedene Dateien, die das Projekt definieren und was ich mir dabei gedacht habe. Denn wenn ihr schon mit Composer vertraut seid und mit WordPress, das habe ich auch eben schon angesprochen. Nein, das ist nicht das Projekt, was ich laden will. Wenn ihr schon bereits mit Composer und WordPress gearbeitet habt und Dinge in Git versioniert, ist die goldene Regel, ich versioniere eigentlich nur das, was sich wirklich ändert. Sofern ich etwas Fremdes über Composer lade, sollte ich es nicht in Git speichern, denn das würde einfach nur mein Projekt aufblähen und braucht ja keine. Also der Code liegt ja schon irgendwie. Also der erste Gedanke, ich muss irgendwie den WordPress Core außerhalb meiner Git-Struktur verwalten. Ich möchte die Plugins und Themes nicht in Git haben, die ich ja über das Repository von WordPress.org laden kann. Wie mache ich das? Und das läuft über verschiedene Wege. Composer, als erstes, da habe ich meine Require-Objekte drin und da schreibe ich meine Dinge rein. Ich lade zum Beispiel WordPress direkt runter. Anmerkung, das ist nicht ein offizielles WordPress.org Repository vom Core, sondern JP Block, ein Entwickler, hat auf GitHub ein Repository erstellt, das alle 15 Minuten WordPress synchronisiert mit GitHub. Und somit kann ich nun über Composer das mir laden und kann sogar eine Version hier angehen. Ihr seht, hier steht jetzt gerade 4.3, in dem es aufgefallen ist. Hier steht nämlich schon Update verfügbar. Und genau das ist der Clue, den ich darin sehe, oder der Vorteil, ich kann nun einfach Versionen bestimmen, die für meinen Projekt wichtig sind. Beispiel, ich sage jetzt hier, ich möchte Version 4.5 haben, nämlich das aktuelle. Wie das gleich im Update aussieht, kommen wir zu. Als Nächstes sehen wir hier WP Packages, FeeM und Plugin, wen das noch nichts sagt, ganz kurz. Es gibt offiziell das Packages.org Repository. Da findet ihr alle Composer-Projekte drin, die ihr laden könnt. Da findet ihr aber keine WordPress-Sachen, also nicht die Plugins und FeeMs. Aber die Entwicklergemeinschaft ist schlau und hat WP Packages erfunden. Dort könnt ihr alle freien FeeMs und Plugins, die ihr auf WordPress.org findet, über Composer-Laden. Beispiel, Jetpack. Guckt, tour dir rein. Das ist ein Plugin. Der Name ist Jetpack. Hier sind verschiedene Versionen. Und jetzt kann ich einfach diese Zeile nehmen in meinen Composer-Laden. Und das wird installiert. Was ich zum Beispiel gerne nutze beim Debacken, ist Debackbar. Das ist ein Plugin. Das hilft mir, um bestimmte Statusnachrichten zu bekommen. Die Zeile kopiere ich mir. Und jetzt kommt der erste Knackpunkt. Ich möchte, wenn ich das Require habe, nicht meinen Debackbar hier reinschreiben. Ich kann das tun, das funktioniert. Aber das würde später zu einem Problem laufen. Also, einem kleineren Problem. Nämlich, Debackbar war ein Plugin, das ich nicht in einem Live-System verwenden sollte oder aktiviert haben sollte, sondern nur lokal verwenden möchte, soll auch nur lokal bleiben. Und das kann Composer auch. Nämlich, es gibt ein Require Dev. Ich sage einfach hier, lad mir Debackbar. Was das tut ist, Composer lädt mir Deback nur in meiner lokalen Entwicklungsumgebung und nicht live. Das werden wir später sehen. Das selbe funktioniert mit Femes. Und ganz wichtig ist, unter Extras könnt ihr dann auch bestimmte Installer-Pars machen. Und da schließt sich der Kreis, wie schaffe ich es bestimmte Dinge in, geht nicht zu speichern. Und das mache ich nämlich so, dass ich bestimmte Pfade angebe und sage, hier installier mir doch bitte WordPress in einen bestimmten Ordner. Zum Beispiel Public-WP. Würde ich das nicht machen, würde WordPress, also hier oben das JP-Ploch, WordPress Repository, würde mir später in einem Wendorordner auftauchen. Aber da nutzt es mir herzlich wenig. Deswegen ändere ich den Pfad hier und es wird hier gespeichert unter Public-WP. Dieser Ordner enthält komplett WordPress. Wie ihr es kennt und runterladen könnt. Aber diesen Ordner kann ich komplett ignorieren, weil der wird ja immer wieder runter geladen, falls sich was ändert. Was ich zudem mache, also stattdessen, ich versioniere eben nur das, was ich brauche. Und das liegt in der Regel im WP-Content Ordner. Das heißt, ich habe mir WP-Content. Ihr seht, hier ist er auch drin, standardmäßig, aber den verwende ich gar nicht. Ich habe nämlich in der Config-Datei angegeben, dass der WP-Content Ordner woanders liegt und kann somit genau sagen, hey, bitte versioniere mir das 2016 Schaltfim. Das ist nämlich ein fiktives Schaltfim, was ich mir selber programmiere für meinen Kunden, das nicht im Repository liegt, aber versioniere nicht 2015 und 2016. Denn diese werden über Composer geladen. Machen wir das schon mal ganz kurz mal an. Wenn ich jetzt Composer Update sage, wird Composer die Änderungen sehen, wird merken, alles klar, ich habe WordPress 4.3 gerade installiert, aber in meiner JSON-Datei steht 4.5. Alles klar, Updaten. Und in Require Dev haben wir eben die Debugbar installiert, die wird jetzt auch noch mitinstalliert. Während das durchläuft, schon mal kurz mal weiter. Es gibt natürlich noch weitere Ordner, die wir beachten müssen, gerade Languages und Upgrades oder Uploads, ganz wichtig. Das sind auch Ordner, die ich nicht versioniere, weil die ändern sich vor allem sehr schnell und meine lokale Entwicklung ist nie selten synchron mit dem Upload-Ordner von Live-System, das der Kunde dann nutzt, also nicht versionieren. Dafür gibt es andere Dinge. Was ich in meinem Template noch tue, ist, ich trenne die Datenbankinformationen. Datenbankinformationen, also generell Passwörter und Nutzer, Daten, niemals in einem Git Repository speichern, auch wenn das privat ist, ganz schlechte Idee. Deswegen wird zum Beispiel Local Config auch komplett ignoriert. Das braucht nämlich keiner in meinem Git Repository, das braucht nur ich lokal. Und genauso muss ich irgendwo auch die Daten von meinem Live-System eintragen. Das brauche ich nicht lokal, das brauche ich live. Und was in der WP Config hier steht, die wurde ein bisschen angepasst. Es checkt, ob eine Production Config vorhanden ist. Diese Production Config enthält die Zugangsdaten zu meiner Live-Datenbank. Wenn nicht, greife auf die lokale Config zurück, weil dann bin ich auf meiner Lokalmaschine. Ihr findet in meinem ganzen Projekt keine Production Config. Diese Datei werde ich später, wenn ich das allererste Mal, dass die Webseite live schalte, auf meinem Server erstellen und an einen Ort auch nur verlinken, wo WordPress drauf zugreifen kann. Also, wir haben jetzt Composer geupdatet. Ihr seht, removing WordPress 433, Installing 4.5. Er hat sogar Teams aktualisiert, hat noch ein paar andere Dinge aktualisiert und hat mir sogar debugbar installiert. Schauen wir, ob das auch stimmt. Was jetzt als Erstes passiert ist, eine Datenbank-Aktualisation. Von 4.3 auf 4.4 gab es nämlich eine Einderung der Datenbank. Einfach aktualisieren, fertig, alles easy peasy, klasse. WordPress läuft und mein Plug-in, Debugbar und Hello Dolly, sind da. Jetzt kann ich die aktivieren. Die brauche ich nämlich für mein Projekt. Ganz besonders Hello Dolly. Und unter Designs, wir haben kein neues Firm hinzugeladen, aber 2015, 2016 sind drin, ein Schaltfirm ist drin, könnt ihr das jetzt auch aktivieren. Das Schaltfirm ist übrigens im Template Project schon drin. Das habe ich einfach nur als Beispiel, das Teil mit reingetan, kann man auch einfach löschen. Das bekommt ihr schon automatisch mitgeliefert, falls man das braucht. Und meine Webseite läuft lokal, alles super, cool. Schauen wir mal weiter, was haben wir bereits? Wir haben das Template, wir haben die lokale Entwicklungsumgebung, wir haben Composer uns angeguckt. Jetzt ist natürlich die große Frage. Ich entwickle so vor mich hin, ich habe meinen Schaltfirm angepasst für den Kunden, er ist happy, ich habe meinen Plug-in, Sachen alle installiert. Wie geht es jetzt weiter? Was passiert da mit? Und da gehe ich nun den Weg, dass ich ja über Git das ganze speicher und ich nutze dazu GitLab. GitLab ist wie GitHub auch ein Git Repository-Hoster. Kostet könnt ihr kostenlos euch auch anmelden. Das ist jetzt einfach nur als Inhose ein anderer. GitLab mit Wacke, das sind so typische Namen, die man meistens hört. Macht dasselbe wie GitLab mit dem einzigen Vorteil, den ich sehe, ist, ich kann unendlich viele private Repositories erstellen. Was mir hilft, denn ich möchte meine ganzen Kundenprojekte nicht in Public Repos versionieren. Also, hat ja nichts dazu zu suchen. Also, ich habe mir zum Beispiel hier Vapro Factory schon angelegt, ein Repository, da ist jetzt noch nichts drin. Was machen wir? Nehmen das einfach, setzen unseren Origin, Mode et Origin fertig und können jetzt loslegen, schon das ganze in unserem GitLab zu versionieren. Das mache ich jetzt einfach mal ganz stupide, und sage einfach, Git at all. Normalerweise würdet ihr das ja schöner machen, aber wir sind ja jetzt hier faul, Entwickler sind faul übrigens, deswegen automatisieren wir auch alles. Ich habe Dinge gespeichert und kann nun über commit, das ganze committen und auf unseren GitLab Server schieben. Das ganze werdet ihr ab. Das war doch so typisch. Einen Moment. Hab ich bereits getan im Vorfeld? Aber es ist nicht im Agent drin. Das könnte es sein. Ihr seht, Live-Demo. Jetzt muss ich aber wieder Git füllen, da funktioniert er nicht. Unter Stress-Koden ist nie eine gute Idee. Wir haben vorhin im Vorfeld überlegt, ob es bei Live-Demos eigentlich auch Vorteile gibt, weil die gehen ja immer schief. Den einzigen Vorteil, den ich sehe, ist, dass Zuschauer sehen, dass auch Programmierende hier vorne stehen, Fehler machen. Und plötzlich fühlt man sich viel besser. Remote, remove, origin. Fügen wir den nochmal zu. Remote at origin. Klasse. Gut, also wir haben das ganze jetzt schön auf unseren GitLab drin. Wir schauen uns ganz kurz mal mal die Falschstruktur an, die da wird. Local config würde man natürlich nicht absprechen. Wie gesagt, das ist einfach nur Testerhalber. Aber was wichtig ist, unter public, seht jetzt kein VP-Ordner, weil den laden wir über Composer. Ihr seht ein VP-Content-Ordner. Allerdings sind dort drin nur die Dinge, die ich wirklich brauche. Zum Beispiel das 2016 Child-Feam. Keine normalen Teams, keine Plugins, die ich über das Repository lade. Nur die Dinge, die ich wirklich explizit möchte. Wie ich das kontrolliere, ist über eine Gitignore-Datei, dass ich sage, alles klar, bitte ignoriere komplett erstmal den Filmsordner. Und ich sage dann nochmal, in dem zweiten Schritt, bitte versioniere aber mein Child-Feam. Dasselbe mache ich mit für Plugins oder für andere Dinge. Ich möchte explizit das in meine Gitignore-Datei reinschreiben, dass ich wirklich versionieren möchte. Um diesen Schritt zu kontrollieren, sage ich möchte eben, die Dinge über Composer auch explizit laden. Wir haben also unsere Sachen auf GitLab liegen. Nur sind genau die Informationen drin, die ich brauche. Und kann nun zum Beispiel mein Child-Feam editieren. Was heißt ich? Da ändere ich zum Beispiel bestimmte Farben und ich ändere das oder ich könnte auch das komplette Feam ändern. Und das wird ja alles in der Composer-Datei gespeichert. Ich werde jetzt zum Beispiel mir ein anderes Feam runterladen. Das heißt, Editor. Halli, Dolly, nehm ich jetzt auch mal beispielhaft raus. Was ich eben dann mache, ist, ich lösche, ich werde mir das Child-Feam einmal kopieren und ich werde mir gleich im selben Schritt ein Child-Feam für Editor erstellen, weil zum Beispiel mein Kunde möchte lieber dieses Feam verwenden oder ich habe es ihm vorgeschlagen. Aber die Änderung mache ich natürlich nicht am Feam selber, sondern im Child-Feam. Trage ich jetzt einfach Editor-Child-Feam ein. Das Template wird Editor sein, Text-Domain wird Editor sein. Und ich müsste jetzt einen Composer-Update nochmal laufen lassen, damit Composer wieder die Dateien ändert, wie z.B. das Editor-Feam. Und es löscht mir gleichzeitig die Feams raus, die ich nicht mehr verwende und auch das Plug-in, das ich nicht mehr verwende. Und das kann ich dann, das ist die falsche Seite, könnte ich jetzt über Feams mir wieder aktivieren und anpassen. Editor-Child-Feam aktivieren. Wunderbar läuft. Das Child-Feam ist da. Wir müssen das ändern und programmieren. Das Ganze werde ich mir jetzt dann wieder schauen kurz rein. Wie ihr seht, Composer, JSON und die Lock-Datei, die Lock-Datei auch immer mit versionieren. Dann werde ich mir jetzt kommenten, laden wir auf unser GitLab-Server und der Spaß ist online und kann später beim Play verwendet werden. Das ist das, was ich gesagt habe, auch explizit erlauben. Da ist es. Editor-Child-Feam wird jetzt auch mit versioniert. Genau, richtige Anmerkung. Wir müssen natürlich, wie gesagt, genau die Dinge auch zulassen, damit das auch funktioniert. Das wird jetzt wieder auf den Server gepusht und ich als Entwickler bin glücklich, habe meine Arbeit getan. Allerdings, der Kunde sieht davon noch nicht viel. Und damit ist das der erste Schritt, das Diploment. Diploment heißt, dass ich als Entwickler mein Fertigeprojekt packe und auf eine Serverschiebe, wo es online zu sehen ist für die Kunden, für die Welt und für die Welthelschaft. Wie kriege ich das auf diesen Server? Ich baue auf SSH, also ich nutze ein Diplomentool, das SSH verwendet und habe das nicht viele das tun, sondern ich mache das lieber auf meinem Rechner und habe mir dafür ein Diploiskript geschrieben. Gründe dafür sind reine Willkür. Ich wollte das gerne das Tool mal ausprobieren und habe es echt schätzen gelernt und das Tool, was ich meine, ist Diploya. Diploya.org ist ein Open-Source-Tool, das auch NPHP für Diploments. Wer Cabistrano kennt das ist ein Rubi geschrieben oder Shippet, da welches ein Notplug in ist, ist sehr ähnlich dazu, hat größtenteils dieselben Funktionen und man kann damit schön Diploin. Und genau das habe ich mir auch in meiner Composite Jason's hinterlegt, hier Diploya um es gleich nutzen zu können. Also, schauen wir nach, was ist das Ziel? Ich habe jetzt bereits meinen Web-Server schon so weit vorgerichtet. Ich habe für die Demo mal kurz rein. Oh, das ist klein. Schauen wir so rein. Ich habe mir bereits einen Test-Server eingerichtet der schon läuft. Ihr könnt das auch hoffentlich alle live nachprobieren, denn über folgende Domänen könnte man, würde man das jetzt sehen. WC, NBG, Formalhaut über Space.de. Einfach jetzt Demo-Zwecken. Da steht einfach nur eine reine Index hat im Elteren mehr nicht. Also unser Ziel ist, über diese Domänen unsere Webseite nun verfügbar zu machen. Was mache ich? Ich werde Diploya nutzen, um diesen Diploi-Prozess anzustoßen. Die Diploya wird automatisch mein Git Repository von GitLab runterziehen. Klammer auf. Dazu muss der Web-Server natürlich auch Zugriff auf GitLab haben. SSH Keys, nur als Anmerkung. Wenn Git runtergeladen ist, wird die Diploya den Composer-Prozess anstoßen. Es wird Shared-Otner anlegen. Es wird Dateien verknüpfen. Und die Webseite wird online sein. Und das in einem oder in einem schönen Diploi-Ment, dass ich auch Roleworks machen kann, was im Anschluss passieren wird. Also ihr findet in diesem Projekt-Template auch ein Diploi-Skript. Das habe ich mir jetzt angepasst für meinen Hoster. In diesem Fall ist es zufällig über Space. Und mache da Folgendes. Ich trage mein Repository ein. Das ist der Link, der gerade GitLab zeigt. Ich habe meine Shared-Files erstellt. Hier taucht wieder die mysteriöse Production-Config auf, die wir ja nicht im Repository sehen, sondern später nur live. Ich erstelle Shared-Directories und mache die Schreiber, die zum Beispiel Uploads und Languages. Was heißt das? Das sind Dateien und Ordner, die ich über verschiedene Diploi-Ments verwenden möchte. Ich möchte euch das so vorstellen. Wenn ich ein Diploi-Prozess anstoße, werden diese Schritte ausgeführt, die ich eben genannt habe. Git wird heruntergeladen, Composer wird installiert und so weiter. Wenn ich das aber ein zweites Mal mache und ich habe nicht diese Ordner verlinkt, dann wird komplette Uploadordner leer sein. Die Languages, die ich vielleicht hinzugefügt habe, werden weg sein, die ich müsste eine neue Production-Config anlegen, die habe ich ja nur einmalig auf meinen Server. Und das jedes Mal manuell zu kopieren, wäre natürlich doof. Deswegen gibt es sogenannte Shared-Directories. Die werden für jeden Diploi-Prozess geteilt. Jedes Mal welchen Replay mit neu anstoße greift der aktuelle Release auf die selben Dateien wieder zu. Was natürlich den Kunden freut, weil bei einem Update sind seine Bilder nicht weg. Die ganzen Informationen für das SSH und den Zugriff habe ich in einer Jammel-Datei hinterlegt. Die sieht beispielhaft so aus. Die hat zum Beispiel einen Namen. Das nenne ich jetzt mal beispielhaft Vapu, hat einen Host, hat einen Username, Identity Files. Man kann es auch mit Passwort machen. Ein Diploi-Parf, wo es also Offenserver hinkommittet wird. Ich kann Stages verwenden. Also ich sage zum Beispiel Production oder Def, wie auch immer, in verschiedene Phasen habe. Und so kann ich das ein bisschen besser konfigurieren. Ich finde diese Jammel-Datei übersichtlicher. Man kann es auch noch mit einem Agent lösen oder man könnte es auch alles hier in eine PHP-Funktion nutzen, um das ein Objekt zu schreiben. Ich finde es so übersichtlicher, aber das sind also Geschmackssagen. Was ich nun speziell noch angepasst habe, ist, ich habe mir ein Task erstellt. Ein Task, der heißt Diploi. Wenn ich diesen Task nun aufrufe, werden diese Unterschritte absolviert. Das deckt sich genau mit den Dingen, die ich eben gesagt habe. Es lädt über Git mein Code runter. Es wird Composer installisiert. Das werden die Scherptateien und Ordner verlinkt. Und es wird eines im Link erstellt für den Release. So, schauen wir mal nach, ob das auch wirklich klappt. Ich habe, wenn ihr das allererste Mal das Projekt benutzt, findet ihr die ausführbare Datei im Wendauordner unter bin dep für Diploier. Ich habe es mir inzwischen einfach schon alias gesetzt. Dep Diploi, das ist der Taskname und Vapu für den Server. Diploier verbindet sich nun über SSH auf den Server, bereitet das Ganze vor, erstellt temporäre Directories für den Release, lädt nun den Git Code herunter, wird gleich den Composer-Prozess anstoßen und das Ganze dann abschließen. Scherptateien, ziemlich fertig. Unsere Webseite ist auf dem Server. Schauen wir mal nach. Irgendwas fehlt hier. Das ist natürlich der allererste Diploi. Der allererste muss natürlich ein bisschen noch vorbereitet werden und da schauen wir jetzt mal kurz auf den Server. Was ich gemacht habe, ist, ich habe das Repository einen bestimmten Ordner verschoben. Der fliegt jetzt in diesem Pfad zum Beispiel, weil der Hoster hat den mir halt so vorgeschrieben und da findet ihr HTML. Im HTML-Ordner seht ihr die Indexdatei, die genau das hier aufruft. Aber ihr seht nun auch WapuFactory.de den Ordner habe ich nämlich angegeben und jetzt müssen wir irgendwie den Server klarmachen, dass die Dateien, die ich will auch in diesem Ordner liegen. Schauen wir kurz mal rein. Hier findet ihr nicht direkt die Git Dateien, sondern eine eigene Diploi-Struktur. Ihr findet einen Simlink für Current und dieser Current liegt, zeigt immer auf den letzten Release. Das hat den Vorteil. Wenn ich einen neuen Diploi-Prozess anstoßen, einen neuen Release mache, können Fehler auftreten. Warum auch immer? Irgendwo fehlt ein Semikolon oder die Farbe gefällt den Kunden doch nicht so kritisch, dass wir sofort zurückgehen müssen. Das erleichtert uns nun die Arbeit mit diesem Link, diesen Link-Ender und wir haben die letzte Version online. Im Shared-Ordner, also im Release-Ordner, findet ihr dann die ganzen verschiedenen Releases. Können wir Spaß das halbe Mal reinschauen. Da finden wir natürlich jetzt erstmal nur einen Ordner, weil das der allererste Diploi war und ihr findet unter Shared die Dateien, die ich in meinem Diploi-Ment angeschrieben habe. Also, kurz reinschauen, genau diese Dinger hier oben. Ich kann das für euch... Warum hat das nie einer gesagt? Ich kann das Ganze auch groß machen, dann könnte ich es viel besser lesen eigentlich. Also, ich kann... Die Bleue hat mir das Production-Config erstellt, hat Ordner erstellt und diese liegen nun in meinem Server hier zur Verfügung. Die ändern sich auch nicht, nur wenn ich es speziell sage oder anstoße, damit ein Release immer darauf zugreifen kann. So, jetzt ist eben die Frage, wie kriege ich das halt umgestellt, dass der Server darauf zugreifen kann? Ganz einfach. Ich... gerade mal vom HTML ein Backup, denn Backups sind wichtig und erstelle mir nun einen symbolischen Link, der auf Current zeigt und nenne den HTML. Unser Hoster guckt nämlich in den HTML Ordner, ob da irgendwas Ausführbares ist und ruft es dann dementsprechend auf. Wenn ich jetzt refresh drücke, wird es immer noch nicht funktionieren, denn der Deploy-Prozess hat zwar eine Production-Config angelegt, aber woher sollte das nämlich auch wissen? Ich habe eine Production-Config mal vorbereitet. Die kopiere ich jetzt einfach hier rein. Da sind die Datenbankinformationen drin. Kein Debug ist angeschaltet. Das wollen wir ja live nicht. Und wenn wir das Ganze aktualisieren, Ben, ich kann nun meine Webseite halt schön wieder einrichten und die ist live verfügbar. Also wenn ihr jetzt schneller seid, als ich, könnt ihr euer eigenes Passwort eintippen. Ich mache anders live natürlich. Die Webseite ist jetzt online. Der Kunde ist zufrieden, kann sich seine Sachen nun nutzen. Sicherlich würde ich jetzt halt was wir jetzt noch machen müssten, das FIM aktivieren. Nämlich unser liebes SchaltfIM, was wir im Git extra gespeichert haben, das ist hier. Wir könnten unsere Plugins aktivieren. Letzt du? Wie wir sehen, sehen wir nichts. Das ist einfach. Nämlich, wo ist BeachBitstorm? Ich möchte Composer haben. Composer. Die da. Wie wir sehen, haben wir nämlich in Require keine Plugins vorgegeben. Ich habe lediglich ein Plugin in Require Def gemacht. Aber bei meinem Deploy-Prozess ist es so schlau, dass ich eben nicht die Def-Installation hinzufüge. Deswegen haben wir gerade auch keine Plugins zu aktivieren. Aber so weit so gut unser Kunde ist zufrieden. Was wir jetzt noch machen in den letzten Minuten ist, ich möchte euch noch ein Rollback zeigen. Und das ist genau der Punkt den ich von Anfang an auch im Kopf hatte, warum ich so ein Workflow überhaupt mir entwickelt habe. Ich möchte nun nämlich was stellen wir uns vor. Der Kunde ruft endblöss an. Ich muss unbedingt sofort diese Change haben. Die Webseite muss so aussehen. Weil es ist ganz wichtig. Das ist ganz wichtig. Wir machen alles möglich von Family sagen Comic Source. Das ist important. Wir testen das nicht. Wir brauchen das gar nicht testen. Der Kunde braucht es. Los. Zu viele. Ah, verdammt. Das wird jetzt auf unseren GitLab geladen. Die wichtige Änderung. Und im Anschluss mache ich einen neuen Diploi. Der Diploi wird genau wieder dasselbe tun. Er wird das Git Repository runterladen. Wird mir alle Packages installieren. Komplett WordPress auch nochmal neu runterladen. Gut Anmerkung, komme ich ganz am Schluss nochmal drauf zu. Ich schlosse das kurz an. Während es jetzt durchläuft, die Frage war oder die Anmerkung bei jedem Diploi wird mein komplettes Composer runterladen. Also das komplette WordPress wird erneut heruntergeladen in neuen Ordner gepackt. Es werden die ganzen Black Ins neu geladen. Das birgt zwei Probleme oder Optimierungsfälle. Erstens. Warum muss ich WordPress jedes Mal neu herunterladen an? Coa hat sich ja nichts geändert. Zweitens. Es behindert einfach den Datenfluss. Also ich jedes Mal dauert dieser Diploi im Prozess lange. Wenn vor allem viel geladen wird. Diploi ja selber. Die arbeiten gerade effektiv daran, das zu optimieren. Wir können natürlich genauso gut sagen, wir legen den WordPress Ordner, den WP Ordner, in unseren Shared Ordner raus. Somit würde der auch nur einmal geladen. Wir können natürlich auch noch einmal die WP Ordner, die WP Ordner, die WP Ordner, die WP Ordner, die WP Ordner, die WP Ordner, die WP Ordner, die WP Ordner, somit würde der auch nur einmal geladen. Somit könnten wir sogar Speicherplatz auf unseren Surfer sparen. Okay, die Änderung ist live. Oh nein, was ist das? Das ist ja schrecklich. Bevor der Kunde das natürlich merkt, nämlich das Schlimmste ist, dass irgendeine Änderung fehlgegangen ist. Wir sehen hier oben keine Iconphones mehr. Ganz schnell zurück. Rollback, Wappu, Bam. Das ist alles wieder beim alten. Das ist die Magic von Rollbacks. Und genau deswegen fand ich das Tool so interessant und wollte das mal ausprobieren. Ich kann nämlich so einfach ohne zu zögern, schnell die letzte Version mir zurückholen, jetzt nochmal in Ruhe in Backfix machen und dann neu debleuen. Hoffentlich geht dann alles gut. So sieht meine Struktur aus. Ich habe, quasi euch alles gezeigt, was jetzt gerade aktiv ist. Das Ganze ist ein Proof-of-Concept und es gibt viele Dinge, wo man noch daran arbeiten kann. Und es gibt zum Beispiel Dinge wie die WPC-LI oder eine Datenbank-Migration, die ich nicht in meinen Workflow beachtet habe. Werde ich in Zukunft noch tun, falls ihr das vermisst habt. Und ihr findet alle meine Sachen auf. Über diesen Link könnt ihr links finden, die ich heute erwähnt habe. Das ist mein Workflow. Vielen Dank fürs Zuhören. Hat jemand Fragen? Die Frage war, ob ich die VirtualBox im Hintergrund, die Vacrantia aussetzt, nur für Apache und MySQL nutzen? Ja, genau. Ich habe beides lokal, das stimmt, aber ich möchte das trotzdem trennen, weil mir diese Kopplung gefällt. Das heißt, wenn ein Projekt abgeschlossen ist, kann ich diese Viertelmaschine mit einem einfachen Kommand löschen. Und alles ist weg. Und keine versteckten Dateien haben sich irgendwo versteckt. Und ich muss die noch mal einzeln löschen. So habe ich eine klare Trennung drin. Und eine Viertelmaschine ist auch nicht so groß. Wir sprechen hier meistens so vielleicht von einem Gigabyte oder zwei Gigabyte. Die Frage war, wo ich einen Datenbank-Export vor dem Deploy habe. Das heißt, man zieht das beim Backup der Datenbank. Aber das ist nicht sehr schön. Also, zur Wiederholung. Wo würde ich den Datenbank-Export als Backup von dem Deploy machen? Wie würde ich das angehen? Das ist ein Gedanke, mit dem ich spiele. Und zwar würde ich genau deswegen die WPC-Li mit der ich ja viele WordPress-Dinge machen kann. Und ich persönlich bin ein Fan von dem kostenpflichtigen Plug-in WP MicroDB Pro von Delicious Brains. Ein tolles Plug-in. Und die haben auch eine WPC-Li-Anbindung. Du kannst mit Deployer normale, alle Commands ausführen auf dem Server über einen Taskrunner. Nicht ein Taskrunner, sondern über ein Run-Command. Und damit könnte ich auch wenn WPC-Li anstoßen und sagen, hey, bevor du irgendwas machst, mach als erstes ein Datenbank-Export. Ist mir das in dieses Directory. Mach dann den ganzen Deploy-Prozess. Fertig. Wenn irgendwas passiert ist und ich mache ein Rollback, könnte ich mein Rollback-Command auch einfach noch ein bisschen anpassen und sage, mit einem Rollback machst du nicht nur den symbolischen Link woanders hin, sondern du ziehst dir auch automatisch von dieser bestimmten Stelle und ziehst es in die Datenbank rein. Das kannst du ja selber definieren. Ich würde es nicht in den Releases reinlegen, weil das ist ein Public Ordner, der rein theoretisch sollte die Datei nicht aufrufbar sein, aber generell was nicht aufrufbar sein sollte immer irgendwie absichern und wenn die Datei nicht von dem System genutzt wird von WordPress-Explizit, würde ich sie in ein eigenes Directory legen. In einem Unterordner auf deinem Server sogar, ich würde sogar so weit gehen und sage, ich ziehe mir die Dumps und lege sie in einem dritten Server hin, falls der Server selber down ist, habe ich trotzdem meine Backups zur Verfügung. Also die Anmerkung war, dass es doch schon nicht sehr zufrieden ist mit dieser dritten Lösung, dass ein dritter Server die hinzugezogen wird damit die Datenbank Backups dort liegen. Ich sehe aber gerade ein optimierter Weg. Da müsste ich mehr Gedanken machen. Ich habe jetzt gerade nicht verstanden die Frage. Also in meiner Konfig-Datei habe ich mit hier Content.dir und Content.url. Da kannst du das eingeben. Das sieht dann nämlich folgendermaßen aus. Das war die letzte Frage. Ich bedanke mich. Wir müssen leider hier schließen, weil die nächste Anmerkung ankommt. Alle Anmerkungen für die Anmerkung. Danke.