Ich bin zum ersten Mal auf der SoCraTes in Linz. SoCraTes bedeutet Software Crafting and Testing Conference und das Ganze in Linz. Ein interessantes Konzept, da die Besucher das Programm selbst gestalten.

Das Programm vom Samstag

Die Konferenz findet im 10. und 15. Stock im Wissensturm statt. Der Ausblick über Linz ist der Wahnsinn.

Über den Dächern von Linz
Sooooo viele Dächer

Am Freitag Nachmittag hatten wir das Glück aufs Dach gehen zu können. Das Wetter hat da auch noch mitgespielt. Die Sessions am Freitag vielen leider nicht ganz in meinen Arbeitsbereich, waren dennoch sehr interessant.

Samstag

Continious Integrations & Delivery

Die erste Session war eine Diskussion über CI/CD.
Zur Erklärung. Continious Integrations and Delivery bedeutet kontinuierliche Integration und kontinuierliche Bereitstellung. Und das heißt jetzt was?
Wikipedia sagt dazu:

Die Automatisierung der Integrations- und Auslieferungsprozesse  ermöglicht schnelle, zuverlässige und wiederholbare Deployments.  Erweiterungen oder Fehlerkorrekturen können somit mit geringem Risiko  und niedrigem manuellem Aufwand in die Produktivumgebung oder zum Kunden  ausgeliefert werden. Continuous Delivery wird primär in Kombination mit agilen Methoden eingesetzt.

In Laiensprache... Wenn ich eine Software entwickelt habe, kann ich über diverse Tools eine Automatisierung dahinter stellen, die mir den Quellcode überprüft, zusammen baut und für den aktiven Einsatz am Server bereit stellt.

In dieser Session ging es hauptsächlich um den Erfahrungsaustausch, wer mit welchen Tools arbeitet und welche Erfahrungen damit gemacht wurden.

Die CI/CD Bubble

Viele Begriffe, viele Programme, wenig bekanntes, viel zum nachlesen...

Exploring cool GitLab features - @harald3dcv / 15.06

Die Community Version ist zeitgleich auch die kostenlose Version.
GitLab ist nichts anderes als eine Git Hosting Plattform. Also eine Plattform auf der die Versionierung von Softwareprojekten möglich ist. Sie arbeitet, wenn man es online nutzt, mit einem Cloud-Server.
GitLab ist änlich zu GitHub und Bitbucket mit dem großen Unterschied, dass GitLab keine Einschränkungen bei der Anzahl an privaten Projekten.

Ich arbeite persönlich seit kurzem erst mit GitLab. Vorher hatte ich Bitbucket im Einsatz. Da jedoch auch hier in der kostenlosen Version diverse Einschränkungen waren, bin ich auf GitLab umgestiegen. Ich hab leider noch nicht mal ansatzweise die ganzen Features von GitLab ausprobiert... Leider...

Ein Feature ist der Issues Tracker
Dieser kann wie ein Kanban oder Scrum Board genutzt werden. Für jene die nicht wissen was das heißt: es ist ein virtuelles ToDo Board  ;)

Das Feature Service Desk klingt sehr praktisch ist aber auch kostenpflichtig! Ich hätte mir damit wahrscheinlich meine Supportsoftware, die wir in der Firma laufen hatten, sparen können... Support Emails werden anscheinend hier automatisch in Tasks (Aufgaben) für den Issues Tracker umgewandelt. Die eigene Support-Mailadresse kann in GitLab mit der GitLab Mailadresse verbunden werden. So kann die eigene Firmenadresse benutzt werden und GitLab macht den Rest.

Die Milestones können anscheinend gut für eine Roadmap Planung genutzt werden, auch hier, wenn man dafür zahlt. Muss ich mir auch mal näher anschauen, wenn der Geldscheißer erfunden wurde.

Das Securtiy Dashboard ist wohl ein Feature für die kostenpflichtige Pro Version... Mit ihr können automatisiert Schwachstellen im Code erkannt und dadurch besser behoben werden. Sideeffect: Es scannt auch Docker Container (was das jetzt bedeutet erklär ich irgendwann mal in einem eigenen Post, wenn ich das Prinzip mal wirklich verstanden hab) und Software Packages die zum Beispiel ein Framework wie Laravel nutzt. Ist aber ein Feature vom Ultimate Preis Plan...

Was mein Herz hier heute höher schlagen ließ war die Erkenntnis, dass GitLab für Ci/CD sogar ein Template für Laravel hat.  :)
Wieder was neues, mit dem ich mich rumspielen kann. Yeah!! Geil!!

Refuc(k)toring Mob Programming - @Christoph / 15.05

Zuerst sollte man wissen was Refactoring bedeutet.
Wikipedia sagt dazu folgendes:

Refactoring (auch Refaktorisierung, Refaktorierung oder Restrukturierung) bezeichnet in der Software-Entwicklung die manuelle oder automatisierte Strukturverbesserung von Quelltexten unter Beibehaltung des beobachtbaren Programmverhaltens. Dabei sollen Lesbarkeit, Verständlichkeit, Wartbarkeit und Erweiterbarkeit verbessert werden, mit dem Ziel, den jeweiligen Aufwand für Fehleranalyse und funktionale Erweiterungen deutlich zu senken.

Die Session hat sich zum Ziel gemacht, genau das Gegenteil zu erreichen. Anhand des Beispieles FizzBuzz wird gemeinsam programmiert.
Was FizzBuzz ist, musste ich selbst erst mal googeln...

Schreiben Sie ein Programm, das die Zahlen von 1 bis 100 ausgibt. Bei  jeder Zahl, die durch 5 teilbar ist, soll "fizz" ausgegeben werden und  bei jeder Zahl, die durch 7 teilbar ist, soll "buzz" ausgegeben werden.  Wenn die Zahl sowohl durch 7 als auch durch 5 teilbar ist, soll  "fizzbuzz" ausgegeben werden. Der Modulo-Operator ermittelt den Rest bei  Division. Somit ist eine Teilbarkeit einfach dann erreicht, wenn die  Modulo-Operation (%, MOD) den Rest 0 liefert.

Fazit: FizzBuzz ist ein Programm, eine Übung. Mit dieser Übung haben wir gemeinsam versucht den schlimmsten JavaScript-Code ever zu schreiben. Frei nach dem Motto: mess up the code
Und es wurde schlimm, wirklich schlimm. Auch mit meinen bescheidenen Kenntnissen musste ich zugeben, dass das Ergebnis alles andere als ein lesbarer, verständlicher und effizienter Code war. Hat Spaß gemacht!

Which quality gates do you seen in an CI/CD-Pipeline (Docker/Kubernets - Environment) - Uinonah / 15.06


Was CI/CD ist, wurde weiter oben schon geklärt. Hier wurde zusammen getragen wie eine Pipleline aussehen könnte. Von der Entwicklungsumgebung am Rechner bis zum Produktivsystem das der Kunde/User nutzen kann.
Für ein ausgewachsenes Softwareprojekt in einer Firma (also ich geh hier nicht von einem Ein-Personen-Ding aus wie bei mir) durchläuft das Softwareprojekt meist mehrere Stationen. Vom Backend- und Frontendentwickler zum Tester  und eventuell noch andere Stellen sind viele Arbeitsstationen in einem Entwicklungszyklus involviert. Softwareentwicklung ist zumeist ein hochkomplexes Geflecht aus verschiedenen Prozessen. Als (meist) Einzelkämpferin seh ich die komplexen Gebilde oft nur am Rande, wenn Kollegen (sowohl männlich aus auch weiblich hier gemeint) zufällig aus dem Nähkästchen plaudern.

Für einen Newbie wie mich sehr interessant das Ganze visualisiert zu sehen

Tja nun, was sagst mir das Bild. Im Grunde wird es von links nach rechts gelesen. Ich versuch mich jetzt mal an einer Laienhaften Erklärung...
Die "IDE" ist nichts anderes als die Entwicklungsumgebung am Rechner des Entwicklers. Also ein Programm am Computer. In diesem Programm wird der Quellcode der Software geschrieben. Es gibt hier verschiedenste Sprachen, die genutzt werden können (JAVA (ja die Insel ist auch schön aber hier nicht gemeint), Phyton, Ruby, PHP, Pearl, Go, und wie sie alle heißen). Die einen brauchen mehr Ressourcen, die anderen weniger (würde jetzt den Rahmen sprengen).
Am Ende eines Tages wird der geschriebene Quellcode "gepusht". Meist wird dazu Git verwendet. Das ist nichts anderes als eine Versionsverwaltung der Software die entwickelt wird. Der "Source Code Control" Knoten. Nun liegt der Quellcode auf einem Server (entweder auf dem eigenen oder in der Cloud oder sonstwo).
Das praktische hier ist, wenn mehrere Entwickler an einer Software arbeiten, kann durch die Versionskontrolle Git der Code von den unterschiedlichen Computern bei der Source Code Control zusammen geführt werden (merge).
Von der Source Code Control gehts dann zum Build Server. Der hat dann richtig zum Arbeiten. Hier kommt das berüchtigte Kürzel CI/CD zum Einsatz.
Für mich Laien sieht es so aus, als ob die Möglichkeiten unendlich wären. GitLab bringt zum Beispiel schon einen CI/CD Bereich mit, inklusive Templates die dann an die jeweilige Software angepasst werden können. Eine andere Möglichkeit wäre Jenkins. Persönlich werde ich mich wohl eher mit dem CI/CD Bereich von GitLab beschäftigen. Anyway...
Vom Build Server führen drei Pfeile weg und zwei wieder retour.
Im Binary Artifact Repository finden unter anderem Security Scans statt. Die Überprüfung auf Sicherheit spielt in der Softwareentwicklung eine wesentliche Rolle.
Im Knoten SonarQube wird eine statische Codeanalyse durchgeführt. SonarQube ist ein Programm das auf Java basiert und was ich so höre, in dieser Diskussion, ist es ein Industriestandard. >> https://www.sonarqube.org/  Der Pfeil von SonarQube war hier eine kleine Diskussion, er bezieht sich aber hauptsächlich auf die Ergebnisse die geliefert werden.
Wenn die Software das Binary Artifact Repository und SonarQube überstanden hat, hier keine Fehlermeldungen gekommen sind, wird auf Dev deployed.
Klingt kryptisch....
Dev heißt Development, heißt nichts anderes wie: Das System ist online aber nur für den "internen" gebrauch gedacht damit jeder rum testen und ausprobieren kann.
Deployen, heißt der Build Server baut die Software zusammen und stellt es automatisiert am Dev zur Verfügung. Am Dev werden dann auch so Dinge gemacht wie End2End Test, Integration Tests, Laufzeitanalysen, usw. Man testet auf Herz und Nieren bevor es zum nächsten Knoten, dem Integration, geht. Am Int werden die letzten Scans durchgeführt wie zum Beispiel der Security Scan und vieles mehr.
Nur wenn alle Stationen positiv verlaufen, keine Fehler aufkommen wird der letzte Schritt initialisiert. Prod, steht für Production, Produktivsystem. Jetzt ist es online, dem Kunden zugänglich. Wenn jedoch irgendwo eine Schwachstelle auftaucht oder ein Fehler geworfen wird, geht es oft wieder zurück an den Anfang der Pipeline.

Auf meine Arbeit umgemünzt, werde ich wohl meine erste Gehversuche mit dieser Anleitung machen:
https://geekalicious.pt/en/continuous-integration/analyse-php-laravel-5-project-multilanguage-with-sonarqube/
Bin schon gespannt wie SonarQube bei Laravel Projekten arbeitet.

Nachtrag:

Die SoCraTes als Open Conference funktioniert grandios. Für mich war es das erste Mal, bei einer Open Conference und die Idee dahinter gefällt mir. Vielleicht finde ich den Mut nächstes Jahr selbst eine Session zu gestalten zum Thema Laravel meets VueJS. Ein Jahr hätte ich ja jetzt Zeit mich vorzubereiten ;)
Themen zum Bereich Frontend waren leider dieses Jahr nicht dabei, aber das kann nächstes Jahr wieder ganz anders sein.

Nach der Konferenz gab es noch einen gemütlichen Abschluss im Niu bei gutem Essen. Es mag jetzt vielleicht schon etwas der Gin aus mir sprechen, aber ich bin froh zu so einer vielfältigen Community zu gehören, wie die der Entwickler. Es gibt für mich noch so viel zu entdecken in diesem Bereich. Die Vorfreude auf die ScriptConf in ein paar Wochen steigt.