Ja, willkommen bei Duo. Wir stellen Website, ich
hole Kasten näher. Wir stellen auch einen Moment ein.
Und ich wünsche euch viel Spaß heute Abend.
Ich glaube, ihr habt es gemerkt. Und ja,
beginnen wir mit Uwe. Ja, cool, danke.
Ja, schön hier zu sein. Ich möchte heute reden
über Automated Deployments of Robots. Ihr seht unten schon auf
den Slides, Take of Conference im Januar.
Es ist nicht nur für euch gemacht
Das sind die gleichen Zeits, nochmal refacted. Und ich
hoffe, ihr nehmt mir das nicht ganz so übel.
Seid denn auf Englisch? Ich rede Deutsch. Und möchte aber erstmal,
weil ich ja gar nicht so oft hier bin,
vielleicht noch was über mich erzählen.
Ich bin Ole, ihr findet mich auf Twitter und da Kautstars.
So, auf Twitter unter Codestars.
GitHubNessQuick. Und ich habe am Wochenende meinen Blog umgezogen.
Und wenn die DNS-Einträge schon stimmt,
findet ihr
den Blog unter blog.codestars.de
Ich arbeite über Jim Nou, wie Royer schon gesagt hat,
wir sind voll die coole Firma.
Und wenn ihr voll die Race-Rakete seid, raketet,
dann melden ihr euch an Hauke, Hauke Winkmeye,
weil wir wollen euch haben und wir bezahlen euch auch
ganz viel Geld und ihr habt das geilste Team ever.
We are ring. Gut, genug der Werbung. Hubert,
Roboter, Chatroboter, wer von euch benutzt Hubert,
Cantfoboard, so das Meldespiel.
Boah, okay, drei Leute. Hammer. Gut,
dann erzähle ich euch immerhin was Neues und ihr werdet
hier nicht gelangweilt sitzen. Ja, kenne ich schon.
Wir fangen einfach
mal vorne an
Ähm, und reden über Continuous Deployment. Was meint Continuous
Deployment? Continuous Integration kennen die meisten sicher von euch.
Geht ja darum, den Code regelmäßig zu testen.
Ähm, Headless Browser Sachen auszuführen. Ähm, und zu Packagen und so weiter.
Und wenn man das Ganze noch einen Schritt weiterbringen möchte,
kommt man zu Continuous Deployment. Das heißt,
nachdem ihr getestet habt und Codemetriken erstellt habt, ähm,
könnt ihr euch das Paket bauen, eure Anwendung quasi bauen,
je nachdem, welche Sprache ihr nutzt.
Das Beispiel, was wir nachher noch sehen,
das PHP, da muss man nicht viel bauen.
Soll ja aber Sprachen geben, da muss man was bauen.
Und dann kam die Ployete dann
Das ist Continuous Deployment. Für das Thema heute. Sollte
Basis wissen über Continuous Integration vorhanden sein. Das heißt,
ihr kennt Travis oder Jenkins und habt das irgendwie am besten auch schon mal eingesetzt.
Was ist das Must-Have für Continuous Integration oder Continuous Deployment?
Ganz wichtig, Tests. Ohne Test funktioniert nichts.
Stellt euch vor, ihr baut ein Feature,
ihr jagt es durch Nontainous Integration und ihr habt ein Bug committed.
Ich weiß, das passiert euch nicht,
aber ich habe gehört, es soll vorkommen.
Und dann geht euer Continuous Integration Server hin,
baut das Ding,
die Tests
Die ihr nicht habt, fehlen also auch nicht.
Und wenn das dann fertig ist, läuft das Continuous Deployment los,
um die Deployed in den Bug, ganz großes Kino.
Also Tests. Und was brauchen wir noch neben den Tests?
Mehr Tests. Noch mehr Tests, noch mehr Tests.
Und wenn ihr keine Tests habt, endet es so.
Ja, dann lacht da einer, der kennt das.
Ihr könnt euch einfach sonst auch euren Arbeitskollegen vertrauen.
Das läuft auch total super.
Okay,
Monteneous Delivery
Ist hier so ein typischer Zyklus aus? Ihr macht
den Commit oder den Push, je nach Version Control.
Dann führt ihr die eben erwähnten Tests aus. Dann geht
irgendein Mechanismus hin und deployed in code auf die Live-Basis.
Und wenn ihr richtig gut seid,
so die echten Pros on Downs, die haben noch mehr Tests,
die testen dann nämlich die Live-Umgebung.
Das ist total cool. Welche Tests braucht ihr,
um die Live-Umgebung zu testen? Ihr testet registrieren.
Ganz, ganz wichtig. Ihr testet das Feature,
was euch am meisten Geld einbringt.
Dann testet ihr das Feature,
was sich am zweitmeisten Geld einbringt
Und dann testet ihr das Feature, wo sich die User
am meisten drüber beschweren. Und dann testet ihr das Feature,
dass sich die User überhaupt beschweren können. That's it.
Dieters sind gut. Oh Gott, was trinken wir?
So, als nächstes. Hubert. Wir haben ja gerade
schon gefragt, wer von euch kennt Hubert?
Waren nicht so viele Hubert. Ist ein Stück Software,
das konfrontiert habe. Das ist also per se cool
Was kann man damit machen? Whoward ist ein Chat-Roboter.
Das heißt, ihr habt sowas wie einen Entwickler-Chat eventuell.
Da hängt ihr dann alle drin mit euren Arbeitskollegen,
damit ihr euch nicht von der Seite anquatschen,
wenn ihr gerade am Programmieren seid.
Deswegen hat man einen Chat. So. Und wenn ihr da
eh schon alle drinnen hängt, könnt ihr auch den Roboter da reinhängen,
weil der kann extrem viele coole Dinge.
Was da alles kann, zeige ich euch gleich noch.
Wie gesagt, Hubert kommt von GitHub.
Hubert ist in CoffeeScript geschrieben. Das ist auch die Grund,
warum ich jetzt überhaupt hier stelle und ich habe irgendeinen anderen User-Group,
weil das ist ja auch JavaScript am Ende.
Dann läuft das auf NotaS. Läuft also super auf Heroku
Da gibt es auch eine ganz klasse Anleitung,
ist auch direkt im Repo mit drin.
Und seit dem Wochenende kann man das Ding auch auf Nujizo laufen lassen.
Das ist leider, also es wurde noch keinen Tag erstellt.
Das heißt, ihr müsstet jetzt den Master Out checken, damit das funktioniert.
Wo ist der Unterschied Tyroku? Ihr braucht auf Nujizo oder ihr
braucht, um Huber laufen zu lassen, CLE-Switches.
Das heißt, ihr müsst sagen, welcher Adapter soll das sein?
Also soll das Campfeuer benutzen oder IRC oder Yammer?
Und ihr hört dem auch Namen geben und so weiter.
Das kann Nujizo leider nicht. Und deswegen habe ich
einen Pull-Request gestellt, dass man diese Cellie-Switches auch über Environment-Variablen
steuern kann
Dann hat er auch einen Brain. Das heißt,
ihr könnt dem Dinge sagen, er merkt sich das.
Beispiel wäre User. Ihr könnt so coole Sachen sagen
wie Hubert. Rocco is a bad as gitterest.
Und dann kann jemand hingehen und sagen, who's rocco?
Und who what antwortet. Das ist ein relativ spielhaftes Beispiel
. Aber ihr könnt damit auch wirklich Sachen machen,
die vielleicht wichtig sind, wie zum Beispiel Out-Mechanismen mit O-Out.
Und das speichert ihr also dann in Reddes.
Es gibt, soweit ich weiß, auch noch andere Adapter.
Kann ich jetzt aber nicht ganz viel sagen.
Und er ist extrem erweiterbar
Ich habe gerade schon was über die Adapter erzählt.
Es gibt zwei, die sind Bild in. Das ist zum
einen Campfeuer. Auch im Campfeuer, weil GitHub das benutzt.
Und das Konsolenplagern. Das heißt, wenn ihr lokal entwickeln
wollt an dem Ding, könnt ihr das einfach starten.
Und ihr habt quasi einen Chat, also einen Repel auf der Konsole.
Dann gibt es noch 13 Third-Party-Interfaces. Die fallen mir jetzt
nicht alle ein. Also IRC, XMPP, jammert,
Twitter, Twilio. Also ihr könnt denen auch SMS schicken lassen.
Und lauter so Spielkram. Also er merkt schon,
es ist extrem viel, viel, viel Spielerei damit verbunden.
Und das ist irgendwie auch ganz cool
You want for fun and profit. Also, was kann man damit überhaupt machen?
Die Zahlen sind jetzt, wie gesagt, schon mit Januar.
Ich hoffe, mittlerweile haben wir in Total die 300 geknackt,
weil es hat nämlich nur einer gefehlt. Es gibt sechs Inbelskripte,
da sind so coole Sachen bei wie Whoboard Image Me.
Den gebt ihr dann in Zeitstringen mit.
Whoboard geht zu Google Images und postet den Link im Chat.
Wenn ihr dann Camp Feuer benutzt oder einen richtigen Client,
der auch Bilder inline anzeigen kann,
habt ihr dann das Bild im Chat.
Keiner lag, das ist eigentlich total witzig.
Vor allen Dingen kann er mit viel Dünnschiss getreten werden
Also, who are to fun? Ich erwähnte gerade schon Image Me.
Ihr könnt Ihnen sagen, dass er Afdi-Art bauen soll.
Das kommt anscheinend irgendwie auf den Adapter an,
weil das geht auch gern mal schief.
Ihr könnt noch mehr Bilder posten. Ihr könnt auch mehr Bilder
posten. Und ihr könnt ihm allen möglichen Quatsch beibringen.
Also, das sind einfach Coffeescript-Skripte, die lassen sich innerhalb
von fünf Minuten wirklich selber schreiben.
Und es gibt auch tatsächlich wesentlich mehr von diesen Quatschskripten,
also irgendwas mit Sinn. Ihr habt die Bilder gesehen,
ihr habt Adi umgesehen, das geht von Haus aus nicht.
Wenn ihr das auch wollt,
das Plugin heißt Ad Inline.
Das ist total geil
Ich habe gesagt, man kann viel Quatsch damit machen.
Man kann aber auch wirklich sinnvolle Dinge damit tun.
Hubert kommt von Get Hub. Deswegen klappt das total super. Es gibt,
glaube ich, in den Skripten, die nicht mitkommen,
also in dem Hubert Skripts Repository, gibt es sechs,
sieben Skripte, die allein für die Interaktion mit GitHub sind.
Das sind Dinge wie Hubert, benachrichtige mich, wenn neue Commits kommen.
Whoboot benachrichtige mich, wenn neue Pull-Requests da sind.
Hubert listen mir alle Con-Tributer auf. Hubert listen mir alle
Bugs Whoboot fix, den Bug. Und also da schließt
nur das Tech-App, der codet das nicht für euch.
Das könnt ihr sonst auch noch, wie gesagt,
ganz anderes Interface, baut ihr alles selber ein,
kein Ding.
Aber erstmal schließt ihr
nur die Tech jetzt für euch
Dann soll es Leute geben,
habe ich mir sagen lassen, die benutzen kein GitHub.
Der kann auch Bitbucket. Vielleicht kann der auch noch andere
properitäre Systeme. Sowas wie Track habe ich neulich auch gefunden.
Ich habe gerade schon gesagt, ihr könnt den auch für Roku deployen.
Es gibt auch Heroku-Strips. Ihr könnt euch dann zum Beispiel
den Status eurer Plattform sagen lassen. Und ihr könnt eure
Live-Anwendungen zum Beispiel auch über Heroku mit Hubert skalieren.
Das ist eigentlich ganz sexy. Es geht einfach um euren
Entwicklerchat, sagt Hubert, Anwendungsname, Scale Web auf 4.
Und dann habt ihr plötzlich 4 Web-Dine aus
Das geht auch für das Skalarium. Das ist so ein
weiterer Platform-as-a-Service-Provider, der sich vor EC2 klemmt.
Und das geht zum Beispiel auch mit Jenkins.
Ihr könnt euch Bild... War ich das? Okay,
ihr könnt euch Bildbenachrichtigung geben lassen. Das heißt,
wenn der Bild failt, dann Spam-Tobot,
solange im Chat rum, bis dir das fächst.
Ja, hier, er kennt den Sinn,
das ist echt cool. Das funktioniert auch. Und...
Weil das ja auch total der Hipster-Nountsense ist,
geht das natürlich
auch mit Travis
Als nächstes möchte ich euch kurz zeigen,
wie ihr das Ganze aufsetzen könnt selber.
Ich zeige das jetzt anhand eines beliebigen Unix-Systems. Das sind,
ich sag mal, ganz sechs, sechs ganz einfache Schritte.
Ihr fangt an, damit Notjazz zu kompilieren. Jetzt habt
ihr Glück und benutzt und merkt, dann gibt es Brew.
Oder ihr habt so ein Freak-Betriebssystem, dann müsst ihr dann
irgendwelche Pakete von sonst wo. Und ich habe mir sagen lassen,
wenn man irgendwie aus Debian, Weasy, was backportet,
könnte das funktionieren.
Aber ich benutze auch einen Mac,
deswegen interessiert mich das nicht.
Lohnt ihr euch, Whood. Daran wechselt ihr das und
zeichnet das und macht ein MPMS toll. Und ja,
jetzt kommt eigentlich der wichtigste Schritt, der irgendwie unscheinbar aussieht,
aber tatsächlich ziemlich wichtige Auswirkungen hat. Und zwar macht ihr,
ihr ruft einfach die Hubert Binary auf und sagt,
der stellt euch create und gebt dann das Zielverzeichnis an,
wo euer Roboter hin erstellt werden soll.
Warum ist das wichtig? Wenn ihr den Clone benutzen würdet,
und das würde, das würde ohne Problem funktionieren,
dann würdet ihr quasi auf dem Kernstück Software arbeiten.
Das heißt, wenn ihr eigene Skripte einbauen wollt,
müsstet ihr den Korb hatchen.
Das ist scheiße. Wenn ihr also diesen Create-Befehl aufruft,
ist Hubod
nur eine Dependency
Und das Shadescript, das dann mitgeliefert wird in der installierten Instanz,
ruft nur den eigentlichen Hubert aus der Dependency auf.
Das heißt, wenn es zum Beispiel Updates gibt,
kriegt ihr die auch und müsst nicht euren gepatchten Core irgendwie mergen.
Deswegen ist das ganz, ganz wichtig. Dann,
wenn ihr nicht gerade Campfeuer benutzt oder eigentlich auch,
wenn ihr Campfeuer benutzt, müsst ihr den Adapter konfigurieren.
Ich mache das jetzt gleich nicht mit Campfeuer,
weil das wäre irgendwie zu einfach,
weil das sind zwei Environment-Variablen setzen und dann ist das fertig.
Was ihr dann noch braucht, ist Forever Supervisor in it upstard or Other Scripts.
Sorry, dass wir ein bisschen aus Englisch abweichen,
weil ich habe den auf Englisch erst dran gemacht.
Ihr braucht also irgendwas, das Ding am Laufen hält.
Es gibt einen Command-Hubert Die, was er macht.
Er macht einen Process Exit One und ist weg.
Wenn ihr jetzt also kein Freever-Supervisor-Innen- oder Upside habt,
dann kommt er auch nicht wieder. Das heißt,
ihr geht jedes Mal auf eure Shell und startet jetzt in euren Roboter neu.
Das ist natürlich voll kacke und deswegen nehmt ihr eins dieser Freever-Scripts.
Das sorgt halt einfach dafür, dass sobald der Prozess abstürzt,
ausgeht oder ähnliches, einfach von alleine wieder gestartet wird
Dann die Adapter-Installation. Wir machen das jetzt am Beispiel von IRC.
Ihr fangt an und geht in eure Package-Dason und tragt voll den String ein.
Ihr gebt einfach quasi die Dependency auf den Adapter an.
Die heißen alle Hubot-Dash und dann der Adapter-Name.
Also Hubot-Dash, IRC, who what dash extrem pippe.
Urdash, Twitter und so weiter. Das ist wichtig,
weil der über dieses Namensschema auch geladen wird.
Wenn ihr das getan habt, müsst ihr die Einstellung vornehmen.
Hubot kann man nach meinem Pull-Request sämtliche Optionen über Environment-Varianten,
Environment-Variablen einstellen
Das heißt, auch den Adapter-Konfurien. Ihr gebt also an,
im Beispiel IRC, auf welchen IRC-Server, er connecten soll.
Ihr gebt an, in welchen Räumen er joinen soll.
Und damit habt ihr es auch für den Adapter.
Wenn ihr zum Beispiel einen XMPP-Adapter benutzt und euer Chat irgendwie protected ist,
dann könnt ihr über Environment-Variablen auch Nutzername-Passwort angeben.
Im nächsten Schritt startet ihr dann den Robot.
Das ist hier jetzt zum Beispiel mit den Commandline-Switches,
was ich eben schon erwähnt habe.
Ihr gebt also am DashR an für den Adapter.
Das heißt, er soll mit IRC connecten, über die Environment-Variablen.
Und DashN ist für den Namen
Ihr könnt das auch über Hubert Underscore und dann Adapter oder Hubert Underscore Name,
jetzt um Latest Death auch über den Evironment Variablen setzen.
Soviel zur Installation. Das waren jetzt ein bisschen mehr
als sechs Schritte, aber es geht trotzdem relativ schnell.
Und es gibt im Hubert Repository wirklich sehr gute Anleitung für Windows-Systeme.
Linux und Heroku. Und der Folge-Fest wurde nur unter der Bedingung angenommen,
dass sich noch eine Anleitung für Notiz zu schreibt.
Das mache ich auch noch. Später. Dann möchte ich
euch erzählen, wie ihr selber Hubert extenden könnt
Ich habe euch erzählt, es gibt mindestens 300 Skripte,
die ihr benutzen könnt, fertig.
Die fallen also quasi aus der Tüte. In der Regel,
wenn man den aber wirklich benutzen will, produktiv,
fehlt irgendwas. Irgendein Quatsch fehlt immer. Das heißt,
ihr könnt ihn dann selber erweitern und eure eigenen Skripte schreiben.
Was müsst ihr dafür tun? Ihr schreibt das Coffee Script.
Ihr schreibt ein Coffee Script. Ein Coffee ist mit Pfeil
und legt die in eurem Skriptsorten ab.
Jetzt ist die Frage, wie interagiere ich denn mit Hubert?
Also was sind quasi die Schnittstellen
Hubert kann auch folgende Dinge reagieren. Er kann auf Kommandos reagieren,
die er direkt an ihm schickt. Das sind die Beispiele,
die ich eigentlich die ganze Zeit genannt habe,
so dass sie, hu what die, hu what Image me.
Also immer sein Name und dann halt der eigentliche Befehl. Es muss nicht,
ihr habt es ja gesehen, ihr könnt den Namen ändern,
er reagiert dann auch auf den geänderten Namen natürlich.
Also wenn euer Hubert jetzt nur an Bord heißt,
müsst ihr nicht schreiben Hubert, weil das wäre irgendwie doof.
Dann kann er noch reagieren auf jegliche Worte,
die irgendwie im Chat auftauchen.
Weißt du, das Beispiel ist zum Beispiel Ship it.
Wenn irgendjemand im Chat schreibt, Ship it,
postet er so
ein cooles Eichhörnchenbild
Ja, das ist wirklich witzig. Ich bringe da noch
ein Beispiel beim nächsten Mal. Und was er auch kann
und das macht ihn meiner Meinung nach wirklich mächtig.
Er kann auf HTTP-Requests reagieren. Das ist das,
was benutzt wird,
wenn zum Beispiel die Interaktion mit Travis geschehen soll,
weil Travis kann ja nicht in eurem Chat posten und das
wäre ja irgendwie dann noch ein Roboter mehr oder ist da irgendwie uncool.
Das heißt, ihr gebt in Travis einfach eine Post-URL an
und Hubboard reagiert dann da drauf und in der Post-URL
steht dann auch der Chat-Raum und dann kann Travis einfach
einen vorgefertigten String im Chat posten
Wenn der Bild failt oder, auch wenn er
gut gelaufen ist oder wenn ihr gerade deployed habt.
Ihr könnt dieses HDTP-Interface auch ganz generisch nutzen, weil es
gibt eine Post-Route, wie heißt Faye? Das heißt,
der übergibt dir einfach einen Command, der mir jetzt nicht einfällt,
also einen Get-Parameter und da steht dann halt der String drinne,
der im Chat erscheinen soll. Das heißt,
wenn ihr jetzt irgendwie ein Deployment-Script baut und ihr wollt,
das gar nicht unbedingt über Hubert steuern,
aber ihr wollt gerne eine Benachrichtigung im Chat,
dass der Deploy läuft oder lief oder gelaufen ist,
dann könnt ihr einfach mit Köln,
zack,
einen Kommando an Hubert und er postet das im Chat
Und was er jetzt noch, sie ist live, sind älter.
Was jetzt eingeklammert ist, was seit einer Woche geht, sind Events.
Und zwar interne Events. Ich habe mich gerade über das Shippet-Beispiel
erzählt. Ihr stellt euch vor, irgendjemand schreibt Chippet,
so, also auch mit Commander, also Hubert Shippet.
Das klingt ja wirklich so, als wenn er irgendwas tun soll.
Aktuell postet er ein Eichhörnchenbild und das war's.
Das ist ja ein bisschen mau. Was jetzt geht,
man kann in dieses Shippet-Skript ein Event, ein Event triggern.
Das heißt, ihr triggert das Event, Deploy-Request
Und jedes beliebige andere Skript kann sich auf das Event subscriben.
Das heißt, Edeployed zum Beispiel mit Scalarium. Und euer Scalarium-Skript kann
auf das Event Deployer-Request reagieren und macht dann auch wirklich den Deploy.
Das heißt, das ermöglicht es euch,
innerhalb der Skripte zu kommunizieren und auch Daten zu übergeben,
ohne die anderen Skripts wirklich ändern zu müssen.
Das ist, wie gesagt, erst seit einer Woche gemerged,
an den Hubert-Skript selber findet man dazu gar nichts.
Und es gibt auch erst zwei Events, die darauf reagieren.
Aber das ist Open Source. Und es ist endlich gemerkt,
das heißt, wir können das alle gemeinsam da einbauen
Jetzt merke ich noch ein paar Beispiele zeigen. Die kommen
aus den Originalskripten, die mitgeliefert werden. Sind aber,
damit es auch durch das Leid passt, ein bisschen vereinfacht.
Weil oftmals gerade in den Live-Skripten die Dinger so einfach sind,
dass sie mehrere Sachen in eine Pfeile packen.
Sowas wie Echo, Dai und andere Commands,
die in der Regel nur eine Zeile lang sind,
stehen an einer Datei.
Das habe ich jetzt ein bisschen aufgeräumt.
Das sieht so aus. Ihr macht Module Export,
wie ihr das kennt, kriegt die Roboter-Instanz übergeben.
Und schreibt dann den Reggags. Also Resport ist das Event,
was getriggert wird,
wenn er
direkt angesprochen wird
Das andere Event wäre hier. Also, bei dem Umbeispiel
Schippe zu bleiben, wäre es robot.hier und dann das Reggax.
Dann funktioniert das auch ohne seinen Pre-Facts.
Oder ihr macht robot.de, ihr macht robot.respawnt.
Und dann muss er immer direkt angesprochen werden.
Wie du gedacht hast, funktioniert hier mit Reggax.
Die werden also immer gepasst. Und das ist ein bisschen tricky.
Ihr dürft am Anfang nicht dieses Zirkum-Dach gelöt benutzen,
weil ja gerade bei Respawnt,
der noch der Pre-Fact noch davor muss mit dem Roboter
Ansonsten könnt ihr aber jegliche Jahre Skript Real
extra einfach reinpumpen und kriegt die Matches dann auch,
wie er hier in Sidey 10 See zurückgegeben.
Das Beispiel ist jetzt halt relativ einfach. Er hört,
Hubert, Echo, Nürnkett und er schreibt Nürnkett.
Stellt euch vor, wir haben zwei Roboter im Chat.
Ihr wisst doch, das hinführt. Das ist ziemlich witzig.
Führt aber dafür, dass man relativ schnell Ärger wird,
den jeweiligen Kloppo weiterentkriegt. Deswegen macht das lieber nicht.
Das andere Beispiel, was ich jetzt noch mitgebracht habe,
ist HTTP, was ich vorhin schon erwähnt habe,
wenn ihr quasi von außen euren Roboter triggern wollt
Hier habt ihr eine ganz einfache Versionsausgabe. Das ist eine Variable,
die wird plain gesetzt, irgendwo in dem Chor und wird einfach ausgegeben.
Was jetzt hier passiert ist, dass das,
also hier ist jetzt noch keine Interaktion mit dem Chat,
sondern hier wird quasi einfach der Roboter als Internetseite missbraucht.
Also ihr geht darauf und kriegt tatsächlich einen HTP-200 mit einfach der Version.
Es gibt noch so ein paar andere relativ einfache Routen,
da gibt es dann die Versionsinfo,
da gibt es die Environment Variablen von anderen Kleinkramen.
Ihr könnt das auch, wie gesagt, kombinieren. Das heißt,
ihr übergebt, das ist halt immer ganz wichtig,
wenn ihr das kombinieren wollt, dass ihr den Raum mit übergebt.
Weil Hubert kann halt in mehreren Räumen gleichzeitig sein und
wenn ihr ihn von außen irgendwie triggern wollt,
müsst ihr auch immer sagen, in welchem Raum das gehen soll.
Dafür muss es so ein genanntes User-Objekt geben,
das sagt dann an, in welchem Raum es gepostet werden soll.
Genau. So könnt ihr den ganz einfach erweitern und
ich kann jedem nur raten, probiert das aus,
spielt damit rum, weil das ist wirklich relativ einfach.
Ihr habt auch die Beispiele gesehen und ein Use-Case zu finden
ist wirklich ziemlich einfach,
weil wir haben alle
genug Quatsch im Kauf
Jetzt möchte ich die Teile, die ich euch vorgestellt habe,
zusammenführen. Wir haben am Anfang über Continuous Deployment gesprochen.
Und dem habe ich das Tubot vorgestellt. Und jetzt melde ich
euch sagen, wie ich das zusammengebracht habe. Damals,
vor ungefähr einem halben Jahr, habe ich noch bei Digital Pineers gearbeitet.
Das Beispiel, was ich euch jetzt zeige,
kommt also von Digital Pineers, es kommt nicht von Jimdo,
aber weil ich das ganze Thema so extrem cool finde,
habe ich am Wochenende schon den Jimdo Ball aufgesetzt.
Der hängt jetzt schon im Chat. Also es geht
ganz heiß los jetzt
Wir hatten unseren Code of GitHub, das ist wichtig zu wissen.
Wir hatten die Apps auf Skalarium, das ist auch wichtig zu wissen,
weil das ganz viel Logik aus Who-Ward back afstrahiert in diese bestehenden Anwendungen.
Also eigentlich ist Who-Ward in unserem Beispiel nur ein ganz einfaches User-Interface,
aber nicht über HTML, sondern halt über den Chat.
Wir hatten relativ wenige Entwickler, das hat das Ganze irgendwie
auch nochmal vereinfacht, gerade um das zu testen.
Und wie gesagt, wir hatten den Jabba-Chat.
Also wir hatten den mit dem Jabba-Adapt am Laufen.
Und der Adapter müsst ihr euch aber eigentlich nie wirklich Gedanken machen,
weil das Interface ziemlich gut definiert ist ich das bisher nie erlebt habe,
dass irgendwas irgendwo inkompatibel ist.
Ihr habt ja bestimmt auch alle Twitter.
Und es gibt Herr Bottling. Wenn ihr jetzt also
euer Handy rausholt und Herr Bottling irgendwas fragt,
dann kriegt ihr auch tatsächlich eine Antwort.
Sowas wie Herr Bottling, Mustashmi und dann The Clinton.
Probiert es aus? Ja, das dürft ihr aufs Handy,
sehr cool. Das Ding antwortet. Wie? Bottling.
Nee, Herr Bottling. Also Herr ist wichtig.
Ihr müsst ein bisschen vorsichtig sein. Das Ding läuft auf
unserem Dashboard. Also macht es nicht kaputt
Ich habe euch am Anfang erzählt, was man machen muss,
damit man Continuous Delivery so richtig gut machen kann.
Und das klang alles in einer total geilen Welt,
aber das hatten wir ehrlich gesagt auch nicht.
Also habe ich mich dazu entschlossen,
dass wir das erst mal noch von Hand machen.
Das heißt, der letzte Schritt, wenn das Continuous Integration
gelaufen ist, zum Deployment war noch händisch.
Das heißt, ich bin in den Chat gegangen und gesagt,
Hubert, Deploy, da kommt gleich noch ein Beispiel.
Wir haben Skalarium benutzt und was ich gerade schon meinte,
es gab kein Skalarium-Plugin
Das heißt, ich habe mich halt mal hingesetzt,
am Wochenende, habe mein allererstes Coffees-Projekt gemacht.
Also mein erstes Coffees gehört bei Hubert, da kommt
auch nachher noch Code, der ist doch dementsprechend scheiße.
Aber da muss man einfach mal zu stehen und mittlerweile kann ich es besser so.
Also das ist völlig in Ordnung. Die nächste Slide ist
ein bisschen schwer zu lesen, vielleicht geht's.
Ich habe ein ganz fanciges Highlight-Ding. So haben wir
den nämlich benutzt. Ihr seht ja aus Zühl,
die habe ich auch tatsächlich rausgepult aus den XMPP-Protokollen.
So ist es also damals tatsächlich gelaufen
Der erste erfolgreiche Deploy. Unser Roboter hieß Charlie. Das war,
das war einfach eine längere Geschichte,
das gab es so einen Hund und der hat immer ganz
viel gesabbert und der hat mich immer ganz furchtbar genervt.
Und weil mein Chef mich irgendwie ärgern wollte,
hieß unser Roboter flüsslich Charlie. Und mein Lieblingskommand war Charlie
Die. Gut, also habe ich Charlie gesagt,
Charlie, aufgehetzt, Skalarium, List, Apps.
Darum geht es erst mal los,
weil wir natürlich aufs Galarium mehrere Apps gehostet haben.
Also gibt mir Charlie eine Liste aus mit allen Anwendungen,
die Skalarium so kennt.
Das heißt, wir hatten da Staging-Umgebung,
wir hatten Live-Umgebung
Wir hatten zum teilweise Apps, wir hatten Webs,
also das kann man, glaube ich, ganz gut lesen.
Und bei Skalarium wird alles über so einen Shar-Hash identifiziert.
Das heißt, über den Shar-Hash kann ich auch angeben,
welche App deployed werden soll.
Das habe ich also im nächsten Schritt getan. Ich habe
unserem Roboter gesagt, Skalarium Deploy und dann der Shar-Hash.
Und dann noch Deploy-Message. Der Roboter hat das dann immer noch geprefixt,
damit man wusste, dass es aus dem Chat kommt.
Charlie geht darauf hin, an die Skalarium API
und schickt ein Post-Request auf die App mit dem Hash,
den er hat,
die Outdaten stehen in Environment-Variablen
Und gebt mir das Feedback, dass er das jetzt macht
und dass er jetzt losgeht und er sagt mir Bescheid,
wenn das fertig ist.
Ich habe euch erzählt, es gibt diesen Post-Trigger.
Den habe ich nicht benutzt, weil das irgendwie mir zu
aufwendig war. Ich habe also einfach alle zehn Sekunden,
die API gefragt und der Deploy fertig ist.
Ist nicht ganz so cool, aber es funktioniert.
Und tatsächlich, es hat funktioniert. Also das war tatsächlich
ein kompletter Deploy. Und es ist halt die Skripte,
die sind komplett frei programmierbar. Also ich habe,
wie gesagt, einfach eine HTTP-Call da drin gemacht.
Das ist relativ einfach. Und ich glaube,
in der normalen Praxis von diesem Beispiel vielleicht mal abgesehen.
Ist das nicht immer alles so cool und scheiden die,
dass man mit einem einfachen HTTP-Request seine App deployen kann?
Aber es ist halt komplett skriptbar. Also wenn ihr jetzt
irgendwie Bash-Skripte benutzt, die kann man auch relativ einfach
nach Kaufley-Skript umschreiben und Hubert dann so deployen lassen.
Wie sieht das also aus, was der Roboter da gemacht hat?
Ich sage euch jetzt ein bisschen Go,
wie gesagt, der ist nicht ganz so hübsch.
Ihr könnt das bestimmt auch nicht ganz so gut lesen,
aber ihr könnt euch die Slides nachher noch online angucken
Das ist, wie gesagt, der Original-Code,
der steht auch noch so auf GitHub,
eventuell gab es noch ein paar kleinere Barkfixes von der Community,
das weiß ich nicht.
Erstmal die Klassendefinition. Der Teil ist komplett ohne Hubert.
Also da geht es wirklich nur darum, quasi ein Coffeescript,
geschriebene, programmierbare API zu haben gegen Skalarium.
Also listen mir alle Apps, Deploy, eine App,
liste mir die Clouds. Das ist halt noch so ein
anderer, in eurem Object-Entity ins Skalarium.
Und letztendlich der eigentliche Deploy-Befehl
Soweit und gut, hat aber alles nichts mit Tubert zu tun.
Das ist die Integration mit Hubert. Da seht ihr die Befehle,
also das Skalarium lässt Apps, Galarium lässt Clouds,
Skalarium Deploy. That's it. Ihr seht, das sind
84 Zeilen ungefähr. Ich habe die Kommentare oben ein
bisschen rausgekürzt, aber es sind definitiv unter 100 Zeilen.
Also es ist echt überschaubar, vor allen Dingen,
wenn man bedenkt, dass man eigentlich die Skalariumklasse auch in
der sauberen Dependency auflösen will und nicht einfach mit in das Skript helft.
Guckt euch das nachher nochmal genauer an,
weil ihr könnt das sowieso nicht verfolgen und ich hier
vorne stehe und noch irgendwie was sabbeln
Wie geht's weiter? Was könnt ihr noch so tun?
Wie könnte so ein Setup aussehen? Ihr könntet euren Deploy
triggern lassen von 4Tub, von Travis oder von Jenkins.
Oder auch von irgendeiner selbst gelöteten Lösung.
Soll es ja auch geben. Ihr habt vielleicht gesehen,
Nojizo unterstützt das, Heroko unterstützt das, glaube ich, auch.
Die könnt ihr einfach irgendwie ganz cool an GitHub ran löten,
über die Service Hooks und dann deployen die eure App direkt nach dem Push.
Das ist irgendwie so mäßig cool,
weil da hängt kein Containers Integration dran
Deswegen lieber über eine Containers Integration-Plattform gehen.
Ihr könnt auch unattend it deploys machen. Das heißt,
ihr lasst es eventuell nicht mehr im Chat mitloggen,
sondern lasst das einfach laufen.
Ich finde, man sollte da ein Auge drauf haben.
Aber je nachdem, wie gut die Tests sind, kann das auch funktionieren.
Ihr könnt alles machen. Wie gesagt, das ist Coffees
Grip. Das ist das Ganze auf das Coffees Grip.
Also geht hin und ihr könnt es einfach programmieren.
Also es gibt eigentlich keine Einschränkung. Ihr habt das HTTTP-Interface
zur Verfügung und ihr habt diese Commands und ihr habt das neueste auf Events.
Und das ist total cool. Jetzt habe ich euch
ganz viel erzählt
Und ihr seid schon mal voll geblättet jetzt. Und wir gehen auch gleich
ein Fäustchen machen. Aber ich würde mich total freuen,
wenn ihr jetzt nach Hause kommt oder morgen in die Firma,
probiert es aus, checkt euch das Repo aus,
klont euch den Robot, bringt ihn in den Chat.
Ihr werdet sehen, dieser ganze Spielkram,
das funktioniert total gut, damit die Kollegen zu überzeugen.
Also wenn man einfach mal das Bild von Kollegen postet und
Hua hat da so ein lustiges Schnurrbärtchen drum malt,
das ist total klar, das kommt total gut an.
Spielt mit ihm rum und eventuell guckt mal durch die Skripts.
Ihr werdet sicherlich einige der Tools,
die in den Skripts drin liegen, auch selber benutzen.
Ich habe sie ja vorhin vorgestellt, also GitHub,
Jervice Track, all diese Sachen und guckt es euch
einfach an und guckt auf so einen Source Code.
Der ist wirklich sehr sauber aufgebaut und gar nicht mal so schwer.
Vielen Dank. Ich habe auf den Slides noch die Links
. Die Slides poste ich nachher noch in die Gruppe.
Und wenn ihr noch Fragen habt, dann können wir die
als Player an. Ich glaube, so wie eine Berechtigung,
wenn du jetzt irgendwie doch 20 Leute in dem Film mitnehmen willst,
das ist schon wieder das Gleiche.
Schwere Frage. Will ich mich nicht zu weit aus dem
Fenster lehnen? Ich weiß, es gibt O-Out gegen GitHub
Als fertiges Skript. Wie man da jetzt genau
die Berechtigung einstellen kann, weiß ich nicht.
Weil das mir einfach nur sagen kann, okay,
es dürfen nur die Leute mitschneiden, die der Fund irgendeine Liste anspielt.
Wüsste ich so nicht. Aber also dann wäre ja
dein Chat quasi auch die Liste.
Also so würde ich das dann umsetzen, ne?
Also ein General Passwort oder so. Gerne. Seid ihr
so geplättet? Sehr gut. Dann Pause. Genau.
Huh. Ziehen wir mal eine Viertelstunde. Das können wir
die Feststunde zeigen