00:00:00: Hallo und herzlich willkommen zu einer neuen Folge Devs on Tape. Heute mit dem Titel "Versionierung?

00:00:06: Ja, mach ich". Kurz vorweg, weil wir ja so einen spannenden und kontroversen Podcast hier haben,

00:00:11: eine Triggerwarnung. Dieser Podcast enthält aller Wahrscheinlichkeit Nachwiederholungen zu

00:00:16: der letzten Folge, wo es auch um Versionierung ging. Also bitte, wer da Dupletten findet,

00:00:21: bitte einfach ein Kenntnis nehmen und die Wichtigkeit dieser Themen berücksichtigen. Viel Spaß!

00:00:29: Ja, auch "Hallo" wieder von mir. Auch wieder ein sehr spannendes Thema, auch wieder Versionierung.

00:00:51: Ja, aber ich bin gespannt, wie ihr diese Folge finden werdet. Das ist ein bisschen,

00:00:56: ein bisschen anderer Bezug. Daher meine erste Frage geht an dich, Kai. Wie ist das jetzt

00:01:03: eigentlich, wenn ich anfangen möchte? Was muss ich machen, worauf muss ich achten,

00:01:06: worüber muss ich nachdenken? Erzähl mir alles.

00:01:08: Ich hoffe, jetzt ist er nicht sofort schon direkt mit einem duplizierten Thema ankommen wie das

00:01:13: letzte Mal. Das überschneidet sich natürlich sehr. Ja, wie ich mit Versionierung anfangen möchte,

00:01:19: ist erstmal natürlich ein starker Willen erzeugen. Ich hoffe, der Titel, der hat auf jeden Fall schon

00:01:22: ... nur so ein bisschen diesen Input gegeben.

00:01:24: Versionierung sollte keine Frage mehr sein, ...

00:01:26: ... ob ich das mache, sondern einfach nur, ...

00:01:28: ... wann ich am besten damit anfangen kann.

00:01:30: Die Antwort ist sofort.

00:01:31: Wie fange ich denn da konkret mit an?

00:01:34: Ja, ich stimme erstmal mein Projekt ...

00:01:37: ... oder mein, ob es jetzt ein privates, eigenes Projekt ist ...

00:01:40: ... oder vielleicht ein Open-Source-Projekt ...

00:01:41: ... oder ein betriebliches Projekt irgendwo.

00:01:44: Stimme ich erstmal darauf ein, ...

00:01:47: ... dass das von den Entwicklungsprozessen ...

00:01:48: ... in diese Richtung geht.

00:01:49: Und dann gehe ich natürlich so vor, ...

00:01:51: dass ich nachdem ich die Person dafür sensibilisiert habe, dass wir das machen wollen und dass wir in diese Richtung gehen wollen,

00:01:57: stecke ich natürlich erst mal ab, was wir für Funktionen, was wir für einen Umfang von der Visionierung wir einsetzen wollen.

00:02:04: Und da kommen natürlich diese ganzen Features und diese ganzen Passworts ins Spiel.

00:02:09: Kurz nochmal vorweg, auch hier wird sich wahrscheinlich sehr stark auch widerspiegeln oder erkennen lassen, dass wir starke Fans von Git sind

00:02:15: und deswegen uns ziemlich häufig auch darauf beziehen, welche Features es bei Git gibt und welche wir da einsetzen können.

00:02:21: Wenn wir anfangen würden mit Versionierungen, dann würden wir uns erst mal natürlich auf

00:02:26: viele Dinge einigen müssen.

00:02:28: Und das bezieht sich zum Beispiel auf das Branching, was wir in der letzten Folge auch

00:02:31: recht unfallreich erklärt haben.

00:02:33: Noch mal kurz erklärt für diejenigen, die vielleicht die letzte Folge nicht gehört

00:02:37: haben, was Branching ist.

00:02:41: Da können wir eigentlich wieder diese Analogie nehmen.

00:02:44: Wir können einfach sagen, wenn wir Branching machen, dann machen wir eine Kopie, einen

00:02:47: Klon von unserem aktuellen Repository und arbeiten auf einer Kopie weiter, damit wir

00:02:51: die den Hauptcore nicht beeinflussen und gegebenenfalls die Kollegen, die auf anderen

00:02:54: Branches sind, auch nicht beeinflussen. Davon gibt es auch nochmal eine abgewandte Variante

00:03:00: oder etwas auf einem höheren Level aufgehängtes Feature. Das hatten wir in der letzten Folge

00:03:03: noch nicht besprochen. Das ist das Forking von einem Repository. Wenn wir damit starten

00:03:09: wollen oder wenn wir das erlauben wollen für unser Projekt, was sich kurz als Anmerkung,

00:03:13: was sich wahrscheinlich eher für große Projekte oder größere Projekte eignet, dann, wenn

00:03:18: Wenn wir das Vorgehen machen wollen, dann machen wir einen direkten Klon von einem gesamten

00:03:21: Repository, welches aber nicht das Hauptziel hat, wieder in den Core zurückzufliessen,

00:03:25: sondern eher als Kopie, als Ausgangspunkt, ein anderes Repository zu nehmen und davon

00:03:30: abzustammen, auf oberstem Level, und dann halt autark weiterarbeiten zu können.

00:03:37: Das hat eigentlich praktisch diesen gleichen Effekt, wie ich kopiere mir ein Ordner und

00:03:40: arbeite nur noch in dieser Kopie weiter und lasse den Ursprung davon unberührt, weil es

00:03:45: dass es sich insofern fast um ein anderes Projekt handelt.

00:03:48: Wenn wir dann in diesem Fork arbeiten,

00:03:51: dann können wir diesen Bezug zur Hauptrepository noch nutzen,

00:03:54: können rübergucken, was hat sich denn in meinem Fork,

00:03:56: im Gegensatz zu dem anderen Fork, in welche Richtung bewegt.

00:03:59: Aber nur in seltenen Fällen, je nachdem, wie man sich einigt

00:04:03: und wie man diese Vorgehensweise macht,

00:04:05: würde Dark Code wieder vom Fork in das Hauptrepository wandern.

00:04:09: Das gibt natürlich auch Projekte, die das sehr intensiv verfolgen,

00:04:12: Aber in den meisten Fällen ist es so, wenn man einen Fork macht, das sehe ich sehr häufig bei privaten oder eigenen Projekten, wo ich mir einen Fork von einem Open Source Tool ziehe,

00:04:20: hat das für mich nicht den Sinn, dass es später in das Hauptrepository zurückfließen soll.

00:04:26: Wie starte ich denn jetzt also?

00:04:29: Ich einige mich mit meinem Team oder für mich selber über die Arbeitsweise, benutze ich Fork, benutze ich Branching, benutze ich diese ganzen Git-Features

00:04:37: Oder benutze ich sie eben nicht oder fange ich erst mal klein an und steigere mich damit diese Funktionalität?

00:04:42: Ich arbeite mich auf jeden Fall erst mal da rein ein, was für Features gibt es, welche Features nutze ich davon und setze mir dann erst mal diese grobe Plattform auf.

00:04:51: Dann entscheide ich mich im nächsten Schritt erstmal, wo kann denn mein Endpunkt für diese Repository liegen?

00:04:57: Das kann bei Git oder bei SVN gleichermaßen ein Remote Server sein oder ein lokales System, vielleicht eine NetNAS, die Container unterstützt,

00:05:06: ... unterstütze, wo ich dann einen extra Container ...

00:05:07: ... für meine Versionierungssoftware hochfahre.

00:05:10: Es kann Raspberry Pi sein, es kann ein anderer Laptop ...

00:05:12: ... bei mir zu Hause sein.

00:05:13: Das kann auch ein eigener Web-Server sein oder ein ...

00:05:17: ... eigener Server, den man irgendwo anmietet, wo man ...

00:05:19: ... das laufen lässt.

00:05:19: Oder ich habe in meiner Firma oder in meiner Umgebung, ...

00:05:24: ... in der ich arbeite, kann ich einen Server oder ...

00:05:26: ... so eine Plattform, die bereits existiert, einfach ...

00:05:28: ... auswählen.

00:05:29: Und dann gibt es die Möglichkeit zu wählen, mache ich ...

00:05:31: ... das Ganze on-premises, bei mir lokal, in den eigenen ...

00:05:34: ... wir wenden noch mal im eigenen System.

00:05:35: Nutzt sich dafür vielleicht die Cloud ...

00:05:37: ... mit den verschiedenen Anbietern, ...

00:05:38: ... die wir auch in der letzten Folge ...

00:05:39: ... schon erwähnt haben.

00:05:40: Oder ...

00:05:41: ... wie gehen wir da vor?

00:05:43: Wo ist unser Endpunkt?

00:05:44: Wo ...

00:05:45: ... arbeiten wir damit?

00:05:46: Und das ist erst mal so dieses ...

00:05:47: ... technische Abstecken.

00:05:48: Wo machen wir das?

00:05:49: Wie machen wir das?

00:05:50: Wie achten wir darauf, ...

00:05:51: ... dass es gepflegt wird?

00:05:52: Dass die Umgebung betreut wird.

00:05:54: Und das Abstecken der Features.

00:05:56: Benutzen wir Lockfunktionen?

00:05:57: Ist das notwendig bei wenigen Leuten?

00:06:00: Oder macht es auch Sinn dann ...

00:06:01: ... erst ab einer größeren Teamgröße ...

00:06:03: das Logging einzuführen, benutze ich Branching, Forking und so weiter, wie schon erwähnt.

00:06:06: Und dann gibt es natürlich auch noch dieser Prozess, den das Ganze auch noch so ein bisschen

00:06:10: als Klammer umschreibt, und zwar ist es auch das Know-how der Leute einzufangen. Also wie

00:06:17: viel verstehen die Leute von der Versionierung? Wie viel haben die damit schon gearbeitet?

00:06:20: Was beherrschen die vielleicht schon? Was haben die schon in ihrer tagtäglichen Arbeit damit gemacht?

00:06:25: Und wo überschneiden sich diese Fähigkeiten? Also ist das Team auf dem gleichen Stand? Können

00:06:30: die unterschiedliche Rollen in diesem Projekt, was Diversionierung und Software angeht, übernehmen,

00:06:34: ist der eine der Super-Reviewer, kann der nächste super die Umgebung betreuen, ist der nächste

00:06:38: eher auf diesem Ticketing und auf der Verwaltung der Umgebung auf logischer Ebene, auf Issue-Ebene

00:06:43: zum Beispiel besser geeignet und dann gibt es halt diese verschiedenen Abstufungen. Das muss

00:06:48: erstmal alles vorhanden sein, das muss erstmal alles abgesprochen sein und eingesammelt sein.

00:06:53: Also das ist so der Prozess, der vor dem Start tatsächlich Diversionierung zu nutzen, auf jeden

00:06:58: notwendig ist. Was würdest du noch dazu sagen? Was fällt dir dazu noch ein?

00:07:04: Also im Großen und Ganzen hast du die meisten Sachen schon erwähnt. Ich persönlich habe eher

00:07:11: Erfahrungen gemacht, also das halt bei einer Integration, das Know-how bzw. die bisherigen

00:07:18: Erfahrungen und die, wie soll man sagen, Änderungsbereitschaft der jeweiligen Kollegen

00:07:25: oder von einem selbst, je nachdem, doch auch sehr wichtig ist.

00:07:29: Also wir nehmen diesen ganzen technischen Themen und dem Know-how selbst einfach,

00:07:34: wie sind es die Leute gewohnt zu arbeiten?

00:07:38: Gibt es vielleicht eine Versionierung, also ein Produkt, welches dem am nächsten kommt?

00:07:43: Oder kann ich meine Prozesse erstmal so ausrichten, dass es am besten zu ihnen passt,

00:07:47: um sich dann zum Beispiel weiterzuentwickeln?

00:07:50: Also so dieses Zwischenmenschliche finde ich, kann man auch auf jeden Fall dann vorher schon vielleicht ein bisschen gucken, wie das dann ist.

00:07:59: Vielleicht auch den Leuten das ein bisschen schmackhaft machen, was man denn da für Funktionen hat und gucken, was man selber für organisatorische Prozesse hat

00:08:08: und was einen dann dabei unterstützen kann.

00:08:10: Ich hatte mal ein Projekt, wo das Reviewing ganz wichtig war.

00:08:16: Da war dann beispielsweise Git mit der UI ganz, ganz weit vorne.

00:08:22: Git lebt dann im speziellen, um genau diesen Prozess zu unterstützen.

00:08:26: Da kann man vielleicht auch noch mal ein bisschen links und rechts gucken, wie dann da so die Strukturen sind.

00:08:31: Ich habe es jetzt gerade auch schon mal so ein bisschen vorweg genommen.

00:08:34: Das ist ja auch dieser Konsens, den wir in der letzten Folge gefunden haben.

00:08:38: Welche Technologie benutzt du denn jetzt am liebsten?

00:08:42: Also du hast schon mal Git angekündigt ...

00:08:43: ... oder hast auch Git schon mal gesagt.

00:08:44: Was würdest du jetzt an den Hauptfeatures, ...

00:08:49: ... an den meistverwendetsten Features, ...

00:08:50: ... an den Projekten sehen, ...

00:08:52: ... die du bisher so durchgeführt hast?

00:08:54: Also da nach wie vor, ...

00:08:57: ... ich glaube ich in der letzten Folge ...

00:08:59: ... wie gefühlt 50 mal erwähnt, ...

00:09:00: ... ich liebe Git und Branching vor allen Dingen.

00:09:04: Also diese Branching-Funktion, ...

00:09:06: Die UIs, die noch dazukommen, die mich dabei unterstützen, meine Aufgaben, die ich halt

00:09:14: machen muss einfach, eben wie zum Beispiel die Abnahme etc., dass ich die dann auch gut

00:09:19: ausführen kann, wie beispielsweise mit einem GitHub oder mit einem GitLab oder meinetwegen

00:09:25: auch, man kann das ja auch über eine Kommandozeile machen, wobei das dann vielleicht nicht so

00:09:28: angenehm ist.

00:09:29: Selbst auf dem Low-Level kann man das auch gut machen.

00:09:34: Also Branching und Reviewing, das waren so die meistgenutzten Features.

00:09:39: Also Branching als logisches Feature, was GitHub, wie du schon sagtest, sowohl in der

00:09:45: UI als auch auf der reinen Kommandozeile unterstützt, ist natürlich ein Feature, was in dem Core

00:09:49: von Git super verankert ist und was man da super verwenden kann.

00:09:52: Wenn man jetzt die Oberfläche betrachtet, hast du gerade erwähnt, dass du mit GitLab

00:09:56: diesen Reviewing-Prozess super fandest.

00:09:57: Ich glaube, an der Stelle auch nochmal zu erwähnen, und das ist auch so mein kleiner

00:10:00: ... Favorit, ist GitHub zu verwenden, ...

00:10:03: ... habe ich jetzt schon einige Projekte ...

00:10:04: ... darauf betreut und auch selber geowned.

00:10:05: Da habe ich die verschiedenen UI-Features ...

00:10:10: ... einfach lieben gelernt.

00:10:10: Also klar, wenn man Branching macht, ...

00:10:13: ... wenn man Pull-Requests durchführt, ...

00:10:15: ... wenn man Workflows anlegt, ...

00:10:16: ... auf die wir später noch mal zu sprechen kommen, ...

00:10:18: ... dann ist das alles von der Logik her ...

00:10:21: ... sehr sinnvoll und gut zu machen ...

00:10:22: ... und zu lieben oder zu hassen.

00:10:23: Aber wenn die UI dazu super ist, ...

00:10:25: ... also wenn dieser Prozess, ...

00:10:26: ... wie ich diese Features bediene, gut funktioniert, ...

00:10:29: ... dann ist das schon mal die halbe Miete.

00:10:31: Wenn ich mir jetzt überlege, ...

00:10:32: ... wie Straight Forward jetzt zum Beispiel GitHub, ...

00:10:34: ... und zwar es ist jetzt keine Werbung, ...

00:10:36: ... muss man dazu sagen, heutzutage glaube ich, ...

00:10:38: ... diese Workflows und die Prozesse, ...

00:10:41: ... die die da in der UI einbinden ...

00:10:43: ... und das auch stetig weiterentwickeln, ...

00:10:44: ... die sind echt ziemlich beeindruckend.

00:10:46: Das heißt, wenn jemand ...

00:10:48: ... einen Pull Request macht, ...

00:10:49: ... ich werde darüber benachrichtigt, ...

00:10:50: ... dass in einer separaten Übersicht, ...

00:10:53: ... welcher Pull Request von wem, ...

00:10:54: ... auf welchem Level wann gemacht wurde ...

00:10:56: ... und kann mir dann mit ein paar wenigen Klicks ...

00:10:58: alle Files anzeigen lassen, die geändert wurden. Große Files sind eingeklappt, kleine Files werden

00:11:03: sofort ausgeklappt dargestellt, mit Rot und Grün hervorgehoben. Welche Zeilen sind gelöscht

00:11:09: worden, welche sind dazugekommen, wer hat an welcher Stelle irgendwelche Anmerkungen gemacht,

00:11:14: wo kann ich was machen, wo hat sich wie was von zwei verschiedenen Branches getroffen. Das lässt sich

00:11:19: alles mit einer Oberfläche super einfach bedienen und teilweise sogar auf Zeilenebene akzeptieren,

00:11:24: ... welche Änderungen vorgenommen worden sind.

00:11:25: Und dann kommt jetzt auch noch ein neuer Begriff dazu ...

00:11:29: ... und zwar das Blaming.

00:11:30: Hatten wir jetzt so noch nicht erwähnt bisher.

00:11:32: Da, wie der Begriff schon sagt, ...

00:11:35: ... kann ich meine, ...

00:11:36: ... ich will es jetzt nicht negativ konnotiert sagen, ...

00:11:39: ... aber eigentlich kann ich tatsächlich auf eine Stelle zeigen ...

00:11:41: ... und sagen, nee, so nicht.

00:11:42: Da habe ich was auszusetzen, da möchte ich was beanstanden.

00:11:46: Wenn man so den Begriff übersetzt mit "beanstanden".

00:11:48: Das kann man in der UI super machen.

00:11:50: Man geht Seite für Seite durch, ...

00:11:52: ... findet dann da so ein Plus, wenn man mit der Zeile ...

00:11:53: ... drüber geht, klickt drauf und sagt, ...

00:11:55: ... diese Zeile finde ich so nicht in Ordnung.

00:11:57: Da würde ich nochmal drüber gehen, vielleicht habe ich ...

00:11:59: ... hier irgendwie einen nicht aussagekräftigen ...

00:12:01: ... variablen Namen, was nur so rein ...

00:12:03: ... rein Code Convention technisch oder ...

00:12:05: ... Lesbarkeitstechnisch relevant ist.

00:12:07: Oder man sieht halt tatsächlich eine Sicherheitslücke ...

00:12:09: ... oder irgendeinen funktionalen Fehler, ...

00:12:11: ... den man schon sofort rauserkennen kann.

00:12:13: Dann kann ich das genau an der Stelle anmerken und kann ...

00:12:15: ... sagen, so das sind meine Anmerkungen, ich gebe das ...

00:12:17: ... jetzt zurück an den Entwickler, der bekommt die ...

00:12:19: ... gleiche Übersicht, sieht das an welcher Stelle, wie was ...

00:12:21: ... beanstaltet wird, kann diese Zeilen editieren, ...

00:12:24: ... wieder zurückgeben und dann kann das Approval stattfinden.

00:12:27: Und das alles, ohne auf der Kommandozeile zu arbeiten, ...

00:12:29: ... ohne großartig viele Versionen von irgendwas ...

00:12:33: ... hin und her zu schieben, das ist alles in der UI möglich ...

00:12:35: ... und ermöglicht deshalb einfach eine super wenig ...

00:12:38: ... Overhead zu diesem Prozess, den man da eigentlich ...

00:12:41: ... abbilden möchte. Also noch mal, man committet Code, ...

00:12:43: ... will den übernehmen, jemand hat daran was auszusetzen, ...

00:12:46: ... spielt ihn zurück, ich mache meine Änderung, ...

00:12:48: ... committet den Code wieder, derjenige sagt, ...

00:12:50: Okay, nehme ich so an, passt, der Rest stimmt, ich lasse das jetzt mit einfließen.

00:12:54: Das lässt sich alles mit den Git-Standardmitteln machen, ist aber mit einer schönen UI wesentlich

00:12:59: schneller und angenehmer machbar.

00:13:00: Ja, da wo du das eben noch mal so erwähnt hattest, da ist mir dann auch aufgefallen,

00:13:05: dass im Endeffekt geht es ja darum, wir reden jetzt sehr, sehr viel darüber und vielleicht

00:13:10: mit diesen ganzen Voraussetzungen, wo man sich Gedanken drüber machen muss, hört sich

00:13:14: vielleicht alles sehr viel an.

00:13:16: Aber im Endeffekt wollen wir ja einen Tool nutzen, eine Basis haben, die uns das Leben

00:13:22: erleichtert und mit der wir nicht noch mehr Kopfschmerzen haben als mit unserem Coach

00:13:25: schon und den Anforderungen.

00:13:27: Und ich finde, das verschreibt oder umfasst es eigentlich ganz gut mit diesen UIs noch

00:13:31: dazu, dass es uns einfach so viel Arbeit abnimmt, weil es Leute gibt, die das natürlich als

00:13:37: Geschäftsmodell haben und dann natürlich auch versuchen, die UIs so benutzerfreundlich

00:13:43: ... viel möglich zu gestalten, ...

00:13:44: ... um Features zur Verfügung zu stellen, ...

00:13:45: ... die man dann braucht im alltäglichen Doing, ...

00:13:48: ... ohne dass man irgendwie noch ...

00:13:49: ... einen weirden Overhead hat oder so was, ...

00:13:51: ... dass man da sich manuell Daten angucken muss ...

00:13:53: ... und da raussuchen muss, was man da geändert hat, ...

00:13:55: ... etc.

00:13:56: Also, genau, ich finde, das umreißt es eigentlich ganz gut, ...

00:13:59: ... dieses, dass man einfach was hat, ...

00:14:03: ... was einem das Leben erleichtert.

00:14:04: Ja, Caro, wie würdest du denn jetzt mit Versionierung anfangen?

00:14:07: Also, wie würdest du jetzt starten, ...

00:14:09: ... wenn du jetzt ein Hörer dieses Podcasts wärst ...

00:14:11: Und wer ist jetzt total angefixt von dieser Versionierung ...

00:14:15: ... und möchte es jetzt sofort starten, ...

00:14:16: ... weil die beiden da im Podcast darauf hingewiesen haben, ...

00:14:19: ... dass das dann jeder machen muss.

00:14:20: Wie würdest du starten, wenn du ...

00:14:21: ... jetzt gerade die Folge fertig gehört hast?

00:14:23: Also das einfachste ist, ...

00:14:24: ... mit dem Start denke ich einen GitHub-Account, ...

00:14:27: ... weil man sich den kostenfrei machen kann.

00:14:29: Man muss da nichts aufsetzen, gar nichts.

00:14:30: Wobei das Aufsetzen natürlich auch nicht so lange dauert, ...

00:14:33: ... aber da habe ich halt einfach schon ...

00:14:34: ... dieses kleine Server-Ding, ...

00:14:36: ... da habe ich auch ...

00:14:37: ... einen richtig coolen Client für den Rechner.

00:14:40: Es gibt auch GitHub Desktop, wo ich drüber meine Sources verwalten kann und kann das

00:14:46: dann auch direkt mit anderen sharen.

00:14:47: Und da habe ich alle Features, die ich brauche.

00:14:49: Da hat man die tollen Sachen, die Kai eben erwähnt hat, die ich erwähnt habe.

00:14:53: Was noch bei mir dazu kommt, ich habe ja schon öfter erwähnt, ich komme aus dem Datenbankbereich.

00:15:01: Das ist oft so, dass wenn man mit Versionierung startet, dass man dann eigentlich schon ein

00:15:07: bestehendes System hat.

00:15:09: Man hat eine Datenbank, man hat dort Tabellen drin und alles mögliche und anderen Krams,

00:15:14: die man in seiner Datenbank haben kann.

00:15:16: Und da gibt es so Tools, mit denen man die Objekte exportieren kann, damit ich dann da

00:15:21: quasi mit einer frischen aufgesetzten Dateistruktur anfangen kann.

00:15:27: Kann mir das dann einfach in mein Repo reinziehen per Drag & Drop und dann kann ich da loslegen

00:15:32: in GitHub.

00:15:33: Und du?

00:15:34: Okay, das beschreibt jetzt so ein bisschen den Moment,

00:15:37: wenn du schon mal das eingesetzt hast und du weißt, wo du klicken musst,

00:15:40: du weißt, was du einrichten musst und du weißt eigentlich schon

00:15:42: einigermaßen Bescheid, wie du so ein Repo aufsetzt.

00:15:45: Wenn ich jetzt mal da zurückdenke, wie meine ersten Berührungspunkte

00:15:48: mit GitHub waren und das könnte jetzt oder GitLab oder Bitbucket,

00:15:51: das war überall einheitlich, muss ich sagen.

00:15:53: Welchen, welche Schritte ich dann mache?

00:15:57: Ich gehe auf dieses Portal, ich melde mich an.

00:15:59: Das kennt jeder, das kann jeder machen.

00:16:01: Und dann finde ich da einen großen Button in den meisten Fällen,

00:16:03: der sagt neue Repository oder ich werde sogar gefragt in diesen UIs,

00:16:06: möchtest du direkt starten und ein Repository anlegen?

00:16:09: Dann mache ich das, gebe vergebten Namen.

00:16:11: Jetzt beziehe ich mich mal auf GitHub und auf Bitbucket.

00:16:14: Ich möchte ein privates oder ein Public Repo anlegen.

00:16:19: Hängt auch natürlich wieder davon ab, ob man jetzt einen öffentlichen

00:16:21: Cloud Dienst nimmt, nimmt oder eine eigene Umgebung installiert bei sich.

00:16:25: Dann ist es eigentlich egal, ob Public oder Private.

00:16:27: Wenn ich jetzt bei GitHub bin, entscheide ich mich dafür, Public oder Private.

00:16:30: Wähle das aus und drücke dann auf Anlegen.

00:16:33: Ich habe noch ein paar weitere Auswahlmöglichkeiten, die das ein bisschen einfacher machen, das zu definieren, was ich denn will.

00:16:37: So, und dann habe ich mein leeres repo da und sehe wirklich eine Schritt-für-Schritt-Anleitung, wie ich jetzt damit umgehen kann.

00:16:44: Da ist der Button, mit dem habe ich die Möglichkeit, jetzt bei GitHub spezifisch das GitHub Desktop zu öffnen und der richtet sich dann vollautomatisch selber ein.

00:16:52: Der sagt dann, okay, hier, ich wurde aufgerufen von dieser Repository, die lege ich jetzt hier an.

00:16:56: Wo möchtest du die Lokal bei dir anlegen?

00:16:58: Also in der Ordnerstruktur auf dem Dateisystem akzeptieren.

00:17:01: und dann hat man die Repo schon fertig im Sync.

00:17:04: Alles, was remote ist, ist da.

00:17:05: Alles, was kleinseitig ist, ist da.

00:17:07: Und dann habe ich das schon mal vorliegen.

00:17:09: Dann habe ich bei GitHub noch die Möglichkeit,

00:17:11: in dem initialen Status,

00:17:13: oder das geht auch bei GitLab und bei Bitbucket auch,

00:17:16: sofort eine ReadMe anlegen zu lassen,

00:17:18: damit eine Datei bereits schon im Repo liegt.

00:17:19: Das ist vielleicht zum Auschecken auf dem Kleinen schon mal ganz angenehm,

00:17:22: dass man sofort eine Datei hat

00:17:23: und sieht, dass der Syncing-Prozess funktioniert,

00:17:26: dass man so ein bisschen diese Startseite

00:17:27: von der Versionierungssoftware,

00:17:28: von diesem Repository schon mal angelegt hat.

00:17:30: Meistens ist das ein Markdown, das ist das Fall.

00:17:32: Ja, aber im Regelfall, wenn man eine leere Repository anlegt,

00:17:36: sieht man dann Schritt für Schritt, was muss ich denn jetzt machen?

00:17:39: Und dann sieht man in dem ersten Block, was muss ich machen, wenn ich eine leere Repo habe,

00:17:42: ein neues Projekt starte, welche Kommandozeilen befehle,

00:17:45: würde ich jetzt auf einem Mac oder auf einem Linux-System

00:17:47: oder vielleicht auch auf einem Windows-System

00:17:49: in der Konsole eingeben, um das Ganze so zu initialisieren.

00:17:54: Im nächsten Schritt sehe ich, ich habe einen vorhandenen Ordner,

00:17:57: wo schon Files drin liegen.

00:17:58: Wenn ich jetzt mal auf das Bezug nehme, was du gerade eben gesagt hast, mit dem Exportieren von Datenmang Schemata oder das Exportieren von Objekten generell aus der Datenmang, die schon existieren, die möchte ich gerne in die Versionierung bringen,

00:18:10: dann habe ich schon lokal vielleicht Source Code liegen, der nur in die Versionierung reinkommt.

00:18:14: Das dürfte für alle Hörer hier interessant sein, die schon Softwareentwicklung machen und nachträglich jetzt Versionierung in das Projekt einführen möchten.

00:18:20: gibt es dann da die genauen Anweisungen, die man auf Konsolen-Ebene eingeben kann,

00:18:25: um alle lokal in dem Folder befindlichen Dateien dem Repository hinzufügt

00:18:31: und initial einmal committed mit einer Beschreibung, wie zum Beispiel "init"

00:18:35: ist glaube ich das beliebteste, der erste commit ins Repository,

00:18:38: alle existierenden Dateien dort aufzunehmen.

00:18:40: Das bekommt man alles schon mit in diesem Startscreen vom Repository.

00:18:45: Und ein dritter Punkt unten drunter ist, ich habe bereits eine andere Vorhandel-Repository,

00:18:48: ... möchte aber diese Repository als weiteres, ...

00:18:51: ... jetzt wird sehr spezifisch, mit sehr vielen Begriffen, ...

00:18:53: ... aber ich möchte eine weitere Remote für meine, ...

00:18:55: ... ein neuer Mirror, ein neuer Remote ...

00:18:59: ... für meine Repository-Lokale anlegen, ...

00:19:00: ... dann habe ich sogar mit Git die Möglichkeit, ...

00:19:03: ... also jetzt mit Git, nicht mit GitLab ...

00:19:05: ... oder mit einer dieser Frontends dafür, ...

00:19:07: ... mit Git generell die Möglichkeit, ...

00:19:09: ... mehrere entfernte Systeme, ...

00:19:11: ... Versionierungssysteme zu wählen ...

00:19:13: ... und auch unterschiedlich zu diesen ...

00:19:15: ... Versionierungssystemen zu pushen.

00:19:17: Diese Anweisungen finde ich alle im Repository, wo ich jeden dieser Fälle ...

00:19:20: ... der eintreten kann, wenn ich ein Repository anlege, ...

00:19:24: ... kriege ich da schon mal die Anleitung, wie ich das bediene und wie ich das mache.

00:19:28: Das wären so die ersten Schritte.

00:19:30: Das würde ich machen, sowohl beim Kunden als auch für meine eigenen Projekte.

00:19:35: Entweder ich starte mit einem Fork, dann ist alles schon vorgegeben und ich habe einen Klon.

00:19:38: Oder ich starte auf der grünen Wiese und fange an meine Dateien hochzuladen, ...

00:19:42: ... also einmal in das Repository zu committen.

00:19:45: Oder ich fange erst dann an, Dateien lokal anzulegen und committe die dann letztendlich

00:19:50: in das Repository fortlaufend, während ich mein Projekt neu ans Laufen bringe.

00:19:55: Dann noch ein Punkt ganz wichtig, den hatten wir auch noch nicht genannt, bei Git ist es

00:19:59: dann noch ganz hilfreich, vielleicht einen Git-Ignore hinzuzufügen, weil man sonst, wenn

00:20:04: man sehr, sehr viele Dateien hat und auch wenn man jetzt einen Export von einem Datenbankschema

00:20:07: hat, dass man vielleicht die Insätze nicht mit aufnehmen möchte, weil Daten vielleicht

00:20:13: ... getrennt aufbewahrt werden, dann kann man in ...

00:20:15: ... diese Git-ignore-Datei lokal den Repository-Anweisungen ...

00:20:18: ... geben, welche Dateien denn getrackt werden sollen ...

00:20:21: ... und welche nicht. Das hat dann zur Folge, dass ich ...

00:20:24: ... lokal bei mir die ganzen Dateien vorliegen habe, ...

00:20:26: ... aber nicht bei einer Änderung meiner lokalen ...

00:20:28: ... Änderungen wirklich alles mit hochgeladen werden ...

00:20:31: ... sollen. Ein kleines Beispiel ist ein Node.js-Projekt, ...

00:20:33: ... wo man viele andere Libraries hinzuzieht, die ...

00:20:36: ... wiederum ganz viele Repositories sind.

00:20:38: Da möchte ich nicht jedes Mal den Code, den ich ...

00:20:40: ... sowieso beim Installieren woanders herbeziehe, ...

00:20:43: möchte ich nicht in diesem sogenannten Node-Modules-Order jedes Mal mit in

00:20:46: meinem Repository reinschicken, weil sonst habe ich eine Kopie von 580

00:20:50: Repositories bei mir in meinem Lokalen, obwohl das da keinen Sinn macht.

00:20:54: Dann schließe ich das aus und dann habe ich in meinem Repository zum Start eine

00:20:59: Git-Ignore, die das verhindert ist, falls da reingelangt, die nicht da rein sollen,

00:21:04: Passwort-Files, unbenötigte Files oder vielleicht eigene Notizen und dann

00:21:09: habe ich eine ReadMe da drin, die erklärt, was habe ich denn hier und die automatisch

00:21:12: für Dokumentationsgründe, für das eigentliche Repository sinnvoll ist, für andere, die da draufgucken.

00:21:18: Das wäre so mein Start. Damit würde ich loslegen in der Versenierung.

00:21:22: Sehr ausführlich.

00:21:24: Ja, wenn ich da schon mal so drin bin, dann...

00:21:27: Ja, genau, also...

00:21:31: Habe ich jetzt gerade ein schlechtes Gewissen, dass ich nur so wenig gesagt habe.

00:21:35: Also tatsächlich ist meine Devise eigentlich immer, ich laufe einfach los.

00:21:41: Ob das jetzt vielleicht immer so gut ist oder nicht, aber ich würde es dann wahrscheinlich

00:21:48: auch so machen, wenn das dann so genau beschrieben ist.

00:21:51: Aber genau diese Herangehensweise kann ich dann nur jedem empfehlen, einfach mal was

00:21:55: auszuprobieren.

00:21:56: Das ist ja aber auch der Grund, warum wir diesen Podcast hier zu zweit machen, damit

00:21:59: man unterschiedliche Herangehensweisen sehen kann.

00:22:01: Ich glaube, da muss jeder seine eigenen Erfahrungen machen.

00:22:06: Ich glaube nicht, dass jeder jetzt anhand dessen, was ich jetzt gerade eben gesagt habe, sofort

00:22:10: ... einen Fahrplan hat, wie er dann starten soll, ...

00:22:12: ... das macht man alles so, wie man das selber empfindet ...

00:22:14: ... und ich glaube, da kann man auch durchaus, ...

00:22:17: ... wie du das gemacht hast, mit dem, was du da beschrieben hast, ...

00:22:19: ... auch schon mal super ins Projekt starten.

00:22:21: Ja, Mensch, jetzt haben wir unsere persönliche Perspektive ...

00:22:26: ... einmal umrissen, noch mal, ...

00:22:29: ... vielleicht von einem anderen Blickwinkel.

00:22:31: Wir haben so ein bisschen überlegt, ...

00:22:33: ... worüber müsste man nachdenken, ...

00:22:35: ... bevor ich dann überhaupt mich zum Beispiel ...

00:22:37: für ein Produkt entscheide oder bevor ich überhaupt loslege.

00:22:41: Aber wie ist das denn, wenn ich das in einer Firma machen möchte oder in einem Projekt?

00:22:45: Kai, wie würdest du das angehen?

00:22:48: Welche Fragen würdest du dir stellen oder auf was würdest du achten?

00:22:52: Ja, also das ist von Fall zu Fall unterschiedlich und das hängt auch ganz davon ab,

00:22:57: in welcher Rolle ich in dieses Projekt reinkomme.

00:22:59: Wenn ich starte als Entwickler, dann würde ich natürlich meine Best Practices oder

00:23:03: Good Practices, wie man es nennt, mit einbringen und die Erfahrungen,

00:23:06: die ich gemacht habe teilen. Das ist immer ganz wichtig, dass man seine Erfahrung mit anderen teilt

00:23:10: und die Vorteile vielleicht aufzeigt, um dann den entsprechenden Personen, die Entscheidungen treffen

00:23:16: oder die solche Wege einschlagen sollen, auf den thematischen Trich dazu bringen, dass das vielleicht

00:23:22: eine gute Wahl wäre, das zu machen. Wenn ich jetzt in einer beratenden Funktion irgendwo enttrete,

00:23:27: wo genau das von mir erwartet wird, um solche Prozesse zu verbessern und zu optimieren, dann

00:23:32: ... würde ich ganz klar sofort eine Roadmap starten ...

00:23:34: ... und alle dafür sensibilisieren, was es da gibt, ...

00:23:37: ... dass man so was machen muss.

00:23:38: Und ...

00:23:39: ... wie man das dann macht, das ist dann halt ein Prozess.

00:23:43: Man guckt, was hat man vorliegen ...

00:23:44: ... und was für ein Projekt handelt es sich, ...

00:23:46: ... wer programmiert da, wie viele Leute programmieren da.

00:23:50: Das würde ich alles erst mal, ...

00:23:51: ... wenn man es so ganz konkret bezeichnen würde, ...

00:23:53: ... in Meetings, ...

00:23:54: ... in Abstimmungsrunden, ...

00:23:56: ... in Präsentationen, würde ich das erst mal vorweg ...

00:23:58: ... ausführlich behandeln, ...

00:24:01: aber trotzdem so schnell wie es nur irgendwie geht, du hast es gerade schon mal erwähnt,

00:24:04: und das überschneidet sich auch so ein bisschen mit den privaten Wegen, die man da einschlägt,

00:24:08: dieses "einfach loslegen" sollte immer ein Bestandteil davon sein.

00:24:13: Also wir müssen nicht sagen, wenn man jetzt einmal angefangen hat, Versionierung zu verwenden

00:24:18: oder ein Fahrt einzuschreiten oder zu beschreiten, dass es dann unumgänglich ist, diesen Weg weiter zu verfolgen.

00:24:27: Da geht es ganz klar um die Tool-Auswahl, nutze ich SV1, nutze ich Git,

00:24:31: Da kann natürlich jemand mit Erfahrung dann sofort sagen, ...

00:24:34: ... was das Beste für dieses Projektumfeld ist, ...

00:24:35: ... aber es ist kein Pardon, wenn man sagt, ...

00:24:38: ... man starte mit SVN und stellt irgendwann ...

00:24:40: ... im Entwicklungsprozess im Idealfall recht am Anfang fest.

00:24:43: Wir benötigen aber noch mehr Features, ...

00:24:45: ... weil wir in unserer Arbeitsweise in diesem Projekt ...

00:24:47: ... vielleicht noch das eine oder andere Feature mehr benötigen.

00:24:50: Weg kann man auch noch mal rüber nach Git wechseln.

00:24:52: Das House Code Git nicht verloren.

00:24:53: Man kann auch tatsächlich auch von einer Technologie ...

00:24:56: ... auf die nächste wechseln, ohne Fortschritte zu verlieren.

00:24:59: Man kann die Historie von den Dateien auch übertragen.

00:25:01: Das gibt da Migrationsmöglichkeiten, das zu tun.

00:25:04: Aber tatsächlich nur noch mal, um das zu wiederholen,

00:25:06: einfach loslegen sollte auf jeden Fall in der Devise sein.

00:25:10: Man sollte nicht erst mal alles totquatschen,

00:25:12: wie ich es wahrscheinlich jetzt in diesem Podcast schon zehnmal gemacht habe.

00:25:15: Ich würde einfach starten.

00:25:16: Ich würde mir überlegen, wie kann ich jetzt dann schnellstmöglich

00:25:18: in diese Versionierung wechseln, um dann vielleicht auch diese

00:25:21: Conventions und die Einigung über die Features und so was vielleicht

00:25:24: auch dann festzustellen,

00:25:27: während ich daran arbeite.

00:25:28: Wer kann im Vorfeld bitte sagen, ob ich Branches brauche,

00:25:31: wenn noch nicht klar ist, wie das Projekt läuft?

00:25:33: Das muss man dann einfach feststellen und mal erfahren.

00:25:36: Und wir mit unserem Fable für Git können natürlich sagen,

00:25:40: man kann Git ganz einfach starten, wirklich einfach loslegen.

00:25:43: Alle auf der Hauptrepository arbeiten, trotzdem Pull Requests

00:25:47: für einzelne Commits machen und dann später feststellen,

00:25:50: wir können jetzt alle recht gut damit umgehen.

00:25:52: Wir führen jetzt Branches ein und entwickeln damit.

00:25:55: Das ist ein laufender Prozess, der immer mit Dokumentation und Schulung einhergeht.

00:25:59: Da sollte man immer wieder darauf aufbauen, auf das, was man hat und kann dann eventuell

00:26:04: auch wirklich zu einer richtig professionellen Anwendung von Git laufen.

00:26:12: Weicht das irgendwie bei dir ab, wenn du jetzt zum Kunden gehst und würdest sagen,

00:26:15: du würdest gerne Versionierung benutzen?

00:26:16: Wie würdest du das angehen?

00:26:17: Also eigentlich recht ähnlich.

00:26:20: Ich habe da schon mehrfach die Möglichkeit, den Kunden dabei zu begleiten, eine Versionierung

00:26:26: bzw. im spezifischen GIT einzuführen, aus verschiedensten Gründen.

00:26:31: In der Regel war es tatsächlich so, ich habe es ja vorhin schon erwähnt, gerade mit den

00:26:35: Kollegen, man hat vielleicht auch mal sehr heterogene Teams von der Altersstruktur, von

00:26:42: der Know-how-Struktur, von den Skills, von der Technologie etc.

00:26:47: Das ist manchmal nicht so einfach, die Leute an einen Punkt zu bringen.

00:26:51: Und da habe ich auch festgestellt, dass gerade dieses Arbeiten auf dem Hauptbranche, also auf dem Master oder wie man ihn auch immer nennen möchte,

00:26:59: dass man da erstmal ohne Branching arbeitet, dass man sich quasi an die Prozesse gewöhnt,

00:27:04: dass man vielleicht auch so Tools wie dieses, wir hatten das vorhin schon, das Todd Toys, dass man das benutzt,

00:27:13: Weil das, wenn man vorher im Windows Explorer gearbeitet hat, integriert es sich einfach sehr gut

00:27:20: und die Leute kennen das irgendwie so ein bisschen mehr, dass so die Verbindung irgendwie da vom Tool her zumindest.

00:27:27: Dass man erstmal, auch wenn es sehr unbeliebt ist, aber ich hab damit eigentlich immer gute Erfahrungen gemacht,

00:27:34: dass man erstmal zum Beispiel auf der Kommandozeile arbeitet.

00:27:37: Ich hab mich da am Anfang auch gegen gewehrt, aber am Ende hat sich doch herausgestellt,

00:27:42: dass es einfach, es bringt einem so ein bisschen bei, die einzelnen Schritte kennenzulernen.

00:27:47: Und dann kann ich zum Beispiel auch besser beurteilen, was mein Tool denn macht, wenn

00:27:51: ich da auf diesen Button klicke.

00:27:53: Weil oft ist es so, die meisten ziehen sich dann irgendeine UI ran, zum Beispiel Source

00:27:58: Tree, weil die kostenfrei ist und dann fangen sie auf einmal an, Dinge zu verändern im Repo,

00:28:05: weil da irgendwo im Hintergrund ein Haken aktiviert ist, aber sie wissen eigentlich gar nicht,

00:28:09: dann passiert und dann geht da halt was kaputt, ohne jetzt in technische Details rein gehen zu wollen.

00:28:14: Dann, dass man sich dann irgendwie steigert, zwischendurch so ein paar Häppchen eben rausgibt,

00:28:20: wie dieses Reviewing an Features, damit sie auch natürlich einen Vorteil irgendwo sehen.

00:28:25: Und dann in das Branching reingeht und dann auch eine Release-Struktur schafft und dann kann man

00:28:32: auch alle nachgelagerten Prozesse, von denen du bestimmt gleich noch was erzählst, kann man dann

00:28:37: auch integrieren, dann kann man irgendwann darüber sprechen, wie das denn ist. Es gibt zum Beispiel

00:28:44: teilweise die Devise, dass man ein Commit pro Feature hat, dass man dann über so, ich sag mal

00:28:52: jetzt Schönheitsgeschichten sprechen kann, also so die Kühe dann am Ende und irgendwie so, dass es

00:28:59: der Prozess, den ich da auch gehen würde. Und genau da am Rande erwähnt, meistens macht das mehr

00:29:05: Arbeit als man denkt, wenn man das Ganze mit begleitet. Also oft habe ich mir gedacht,

00:29:10: okay, wenn wir jetzt die drei Befehle rausgeben, das wird dann schon klappen, aber trotzdem gibt

00:29:16: es da noch super viele Fragen, super viele Verständnisgeschichten. Man muss die Leute

00:29:19: einfach an die Hand nehmen und so ein bisschen ja einfach mit begleiten auf dem Weg.

00:29:23: Ich habe das jetzt gerade bei dir rausgehört, dass wenn man so UIs verwendet, das klang jetzt

00:29:29: alles nicht nach einer Hypothese oder nach irgendwelchen theoretischen Dingen. Ich glaube,

00:29:33: Du hast bestimmt schon das eine oder andere mal festgestellt, ...

00:29:35: ... dass es da irgendwelche ernst zu nehmenden ...

00:29:36: ... Probleme im Repository gibt ...

00:29:38: ... oder vielleicht auch selber verursacht oder auch erlebt.

00:29:40: Was würdest du sagen, wenn man dich jetzt mal fragen würde, ...

00:29:42: ... erzähl mal aus dem Nähkästchen, ...

00:29:44: ... was ist denn der worst case ...

00:29:46: ... oder was ist das Schlimmste, was dir schon mal passiert ist?

00:29:49: Das Schlimmste, also ich habe auch schon ...

00:29:55: ... mehrfach Dinge aus Versehen gelöscht.

00:29:57: Ich habe gesehen, dass ...

00:29:59: dass auf einmal irgendwie das komplette Repo verändert wurde, obwohl nur zwei, drei Dateien

00:30:05: verändert wurden, ursprünglich. Also wie gesagt, wie auch immer diese Sachen da alle

00:30:08: passiert sind. Jetzt explizit auf ein Tool bezogen hatte ich ja eben schon genannt "Source Tree".

00:30:14: Da ist zum Beispiel mal so gewesen, also man kann in ein Git Repository quasi ein anderes

00:30:21: geht Repository reinhängen. Das ist ein Submodul, nennt sich das. Und damit kann man zum Beispiel,

00:30:31: wenn man so Komponenten aus einem anderen Software verwendet, kann man die dann da einbinden

00:30:35: und auf einer bestimmten Version auch so belassen. Und wenn man dann bereit ist zum Update, dann

00:30:40: kann man dieses Submodul updaten auf einen neueren Stand. Und zum Beispiel dieses Source

00:30:47: hat irgendwo im Hintergrund einen Haken, das dafür gesorgt hat, dass dieses Submodul immer

00:30:52: auf den neuesten Stand geupdatet wurde.

00:30:54: Das ist natürlich ungünstig, wenn man dann darauf angewiesen ist, dass es auf der Version

00:31:00: bleibt zum Beispiel.

00:31:01: Und man wundert sich dann natürlich auch immer, warum dieses Submodul denn jetzt geupdatet

00:31:06: wurde und muss das dann immer wieder zurückrollen.

00:31:08: Und das hat ein paar Stunden Arbeit gekostet.

00:31:11: Zum Glück nicht nur mich, also mich nur relativ wenig im Verhältnis zu den Kollegen, aber

00:31:17: Das war schon echt ein Phänomen, wo ich doch sehr überrascht war.

00:31:19: Das klingt wie so ein bisschen wie so ein Callback auf unsere Folge, auf unsere Folgen

00:31:24: "Library Nightmare", wo man einfach Source Code von anderen permanent mit reinbeziehten

00:31:28: Updates macht und nicht genau weiß, was da passiert ist und das dann irgendwelche Nebeneffekte

00:31:32: hatte.

00:31:33: Ja, auf jeden Fall.

00:31:35: Und ja, ansonsten, wie gesagt, gerade dieses, ich sag mal, Standalone Tools, da gab es

00:31:42: dann auch öfter Buttons, wo dann auf einmal Aktionen in Kombination ausgeführt worden.

00:31:48: Oder wo zum Beispiel, was auch was ganz Spannendes, was ich schon gesehen habe, ist, wenn man

00:31:55: einen Merch-Konflikt hat, also wenn man Sources, die gleichzeitig verändert wurden, zusammenführt

00:32:00: und zum Beispiel zwei Leute die gleiche Stelle verändert haben, dann kommt ein Konflikt auf

00:32:06: und diesen Konflikt muss ich halt lösen, indem ich zum Beispiel sage, ja, die neue Version

00:32:12: ist die richtigere, weil die aktueller ist.

00:32:14: Oder ich muss das beides irgendwie so zusammenführen.

00:32:17: Und im Hintergrund fügt Git dort, um das zu kennzeichnen,

00:32:20: so Steuerelemente ein.

00:32:22: Mit diesen, ich weiß gar nicht, Angel Wings,

00:32:24: ich weiß gar nicht, wie die auf Deutsch heißen,

00:32:27: diese größer als kleiner als Eier.

00:32:29: Krokodile, kann man dazu auch sagen, Caro.

00:32:31: (Lachen)

00:32:33: Das Krokodil, was nach links guckt, und das Krokodil, was nach rechts.

00:32:36: Genau, also die Krokodile.

00:32:38: (Lachen)

00:32:39: und führt dort über Steuerelemente ein.

00:32:42: Und zum Beispiel hatte der Kollege, der hatte das nicht so auf dem Schirm quasi,

00:32:52: dass der Konflikt, wenn ich ihn dann per Tool auflöse, dass er das dann automatisch entfernt.

00:33:00: Also das regelt dann ja zum Beispiel bei ToTros Git,

00:33:03: gibt es ja auch ein Konfliktmanagement, was man benutzen kann und in der Git UI bestimmt auch.

00:33:08: Dann wurde das so gepusht und dann hat die Installation halt nicht funktioniert, weil

00:33:15: da noch ein paar Steuerzeichen drin waren, die nicht aufgelöst wurden.

00:33:18: Das sind so, glaube ich, die größten Schnitzer, aber das sind einfach Sachen, die passieren

00:33:25: dann am Anfang.

00:33:26: Dadurch geht im Zweifeln die Installation kaputt, aber nicht das gesamte Projekt.

00:33:29: Aber ihr seid nicht die Einzigen, muss ich sagen.

00:33:31: Ich habe genau das gleiche Phänomen auch schon erlebt.

00:33:33: Das ist vielleicht auch einfach mal so ein Punkt, das zu erwähnen, wenn man damit startet,

00:33:37: um diesen Weg nochmal zurück zu dieser Frage zu kriegen.

00:33:41: Ich sollte nicht, um die Versionierung einzuführen,

00:33:44: direkt einen fullblauen Tool nutzen, was all diese Funktionalitäten bereitstellt

00:33:48: und auch noch vielleicht automatisiert ausführt.

00:33:51: Wenn ich jetzt zum Beispiel an Visual Studio Code denke,

00:33:54: damals gab es die Erweiterung Git Lens und mittlerweile ist da eine sehr gute Versionskontrolle

00:33:59: in VS Code auch direkt mit drin.

00:34:02: Da gibt es viele Funktionen, die einem auch sehr schlüssig zur Verfügung stehen,

00:34:07: oder die auch sehr schlüssig da in der UI angeordnet sind.

00:34:10: Aber wenn ich mit diesen Features in meinem Projekt nicht arbeite,

00:34:13: dann können die dafür sorgen, dass ich ganz schnell in einen Punkt weiterkomme,

00:34:18: wo ich nicht mehr verstehe, was da passiert.

00:34:19: Ein ganz konkreter Fall ist, ich nehme meine Dateien, füge die dann einem Commit hinzu,

00:34:24: und dann kommt die Frage, da ist das Remote Repository und die Files sind neuer,

00:34:28: da sind diese Konflikte, die dann auftauchen.

00:34:30: Und da würde man jetzt eigentlich auf der Kommandozeile oder sowas konkrete Anweisungen kriegen,

00:34:34: die sagen, was denn da jetzt passiert ist.

00:34:37: Und dann würde ich mich da reinlesen und überlegen, warum das denn jetzt passiert ist und würde die Lösung dafür finden.

00:34:41: Wenn ich eine UI habe, dann werden mir Dinge vorgeschlagen,

00:34:44: das ist jetzt nicht wortelos voll gegenüber diesen Tools oder dieser Tools, die das anbieten.

00:34:49: Die gehen halt davon aus, dass man da schon mehr weiß und mehr kann,

00:34:52: dass ich dann gegebenenfalls irgendwie diesen Commit durchführe.

00:34:57: Aber die Konflikte oder die Files, die nicht editiert werden sollen,

00:35:00: erst mal so auf eine Halde lege und die ich nochmal zurücklege

00:35:04: für einen weiteren Commit, der das dann auflöst.

00:35:06: Und da bin ich ganz schnell in dem Punkt, wenn ich das Prinzip nicht verstehe,

00:35:09: dass ich einen Commit mache, wo noch nicht alles mitgekommen ist,

00:35:12: wo meine Files lokal sich denen in der Repository unterscheiden,

00:35:15: wo ich nicht mehr einen klaren Baum habe, den ich entlanglaufen kann,

00:35:18: wo ich dann ganz schnell verstehen muss, was passiert jetzt.

00:35:20: Und im Zweifel, wenn das dann mal ein Freitag Abend ist

00:35:23: und ich meine Arbeit eigentlich abgeben wollte, zu echt langer Zeit Overtime irgendwie führt.

00:35:29: Weil ich, wenn ich das nicht verstehe, was dieses Tool da für mich gemacht hat oder von mir verlangt

00:35:34: an diesem Zeitpunkt, wann da ich da echt ein Rabbit hole, mich da noch weiterbilden zu müssen.

00:35:38: Wenn ich die Standardoperation auf der Kommandozeile verwende, dann bin ich da auf jeden Fall erst mal

00:35:44: auf der sicheren Seite. Lern dabei zwar viel, aber da muss man auf jeden Fall aufpassen,

00:35:48: dass die UI oder die IDE dann nicht schlauer ist, als man selbst was die Funktionalitäten angeht,

00:35:52: die man verwendet oder dass man das alles einfach so konfiguriert, dass wirklich nur

00:35:56: die Basissachen genutzt werden und keine weiteren Automatismen da angefeuert werden.

00:36:01: Das wäre jetzt nochmal so etwas, was ich dazu beitragen kann.

00:36:04: Vielleicht um an der Stelle jetzt nochmal kurz auf die Integration zur Sprache zu kommen

00:36:11: oder zu sprechen zu kommen.

00:36:13: Was kann man denn alles noch over the top machen?

00:36:15: Also wenn ich wirklich jetzt mal fortgeschritten in dem ganzen Prinzip bin und noch mehr Zeit

00:36:18: sparen möchte, noch mehr Automatisierung durchführen möchte, Stichwort ist die ICD

00:36:22: und DevOps. Das ist eigentlich ein Thema für sich. Da werden wir mit Sicherheit auch am

00:36:26: Folgenden nochmal eine Folge darüber machen, was diese ganzen Pipelines und diese ganzen

00:36:29: Entwicklungsprozesse so mit sich bringen. Da gibt es ganz sicher auch Gäste, die bei uns

00:36:34: in dem Podcast dieses Thema weitaus besser und umfangreicher erklären können. Aber im

00:36:40: Zusammenhang mit der Versionierung, mit diesen Plattformen, die wir schon erwähnt haben,

00:36:43: in dieser und in der letzten Folge, können wir vielleicht nochmal eine Übersicht schaffen,

00:36:47: wo man denn auch da starten kann oder wo man auch da sich mit wenigen Klicks schon Arbeitserleichterungen

00:36:51: verschaffen kann. Hast du damit schon Erfahrungen gemacht mit den Funktionalitäten, Pipelines,

00:36:56: Deployments und so weiter, die man so in diesen gängigen Plattformen einfach verwenden kann?

00:37:01: Ne, tatsächlich nicht. Deswegen finde ich es auch sehr spannend, was du gleich so zu erzählen hast.

00:37:07: Ich habe das nun schon mal gesehen bei meinen Java-Kollegen, dass die solche Pipelines sich

00:37:12: aufgebaut haben, wo dann auch die Unit-Tests automatisch ausgeführt werden etc. Aber

00:37:17: selbst integriert habe ich es schon lange nicht und auch selber genutzt auch noch nicht.

00:37:21: Okay, also ohne da jetzt in dem großen Thema DevOps oder CI/CD schon zu viel vorwegzunehmen

00:37:29: oder auch dem ganzen nicht gerecht zu werden, kann ich dieses Basisprinzip anhand von z.B.

00:37:35: Testing Frameworks im JavaScript umfeldmal kurz umreißen.

00:37:37: Was wir da z.B. haben bei Node.js oder bei generell JavaScript-Programmierung, da haben

00:37:42: wir viele Tools, die Tests ermöglichen, ob das jetzt Mocker ist, ob das Mocker und Schall

00:37:46: zusammen ist, ob das Jest ist, wenn man das Facebook Framework nutzen möchte.

00:37:50: Dann gibt es da die Möglichkeit, dass man in seiner Entwicklungsumgebung, in seinem Projekt,

00:37:56: Lokaltests schreiben kann und die auch automatisiert bei sich vielleicht ausführen

00:37:59: kann oder auch Hände starten kann oder auch in der IDE so einen Button hat, der sagt,

00:38:03: jetzt bitte einen Test ausführen. Wenn man das Ganze vielleicht eher noch mehr automatisieren

00:38:08: möchte in Hinblick auf Versionierung, dann stellen diese Plattformen und diese Portale,

00:38:12: ... die wir schon vorgestellt haben, ...

00:38:14: ... ganz einfach die Möglichkeiten, ...

00:38:16: ... dass man sogenannte Hooks ...

00:38:18: ... oder sogenannte Events verwendet ...

00:38:19: ... innerhalb dieser Repository.

00:38:21: Das ist der Vorteil, wenn man halt nicht nur Git Plane nutzt ...

00:38:23: ... oder ganz einfach die Git Software, ...

00:38:25: ... sondern wirklich so ein Service verwendet, ...

00:38:27: ... der das bereitstellt, ...

00:38:28: ... ob jetzt selber installiert in Form von GitLab ...

00:38:30: ... oder Bitbucket ...

00:38:31: ... oder ob man jetzt einen Online-Service nutzt, ...

00:38:34: ... wie auch diese Public-Variante von GitLab oder auch GitHub.

00:38:36: Und dann gibt es da Presets, ...

00:38:39: ... dann gibt es auch schon fertige Lösungen, ...

00:38:40: ... wo man sagen kann, dass diese Tests, ...

00:38:41: die man lokal bei sich installiert hat, also die Software Jest zum Beispiel, die man da dann ausführen kann mit Testfiles,

00:38:51: also geschriebenen Testskripten, die auch im Repository selber liegen.

00:38:54: Da kann ich mir diesen Arbeitsprozess von der rein lokalen Maschine bei meiner Entwicklung,

00:38:59: kann ich auch auslagern oder zusätzlich noch aufsetzen in das Repository selbst.

00:39:04: Und das sieht dann ganz konkret so aus, dass ich eine Definition in meinem Repository hinterlege,

00:39:09: ... welche Automatismen durchgeführt werden.

00:39:11: Und die sind dann in einem anderen Markt abgeschrieben, ...

00:39:14: ... meistens aus einem Jammel zum Beispiel, ...

00:39:15: ... in so einer Tree-Auflistung.

00:39:18: Welche Schritte sollen durchgeführt werden, ...

00:39:21: ... wenn welche Events passieren?

00:39:22: Ja, also beispielsweise, ich höre auf jeden Commit, ...

00:39:26: ... ich höre auf jeden Merchrequest ...

00:39:27: ... und ich höre auf jeden, oder Pullrequest, ...

00:39:30: ... oder ich höre auf jede Release-Herstellung ...

00:39:33: ... in meiner Repository.

00:39:34: So, also gehe ich hin und sage, ...

00:39:37: ... bei jedem Commit in das Haupt-Repository ...

00:39:39: wird erst mal ein Pull Request gestellt. Ich möchte gerne, dass dieser Code in den

00:39:42: Core fließt. Dann kann ich auf dieses Event eines Pull Requestes reagieren mittels dieser

00:39:48: Automatismen und kann sagen, wenn dieser Pull Request erstellt wird, wird automatisch etwas

00:39:52: durchgeführt und das können diese Jest Tests sein. Dann geht eine separate Maschine hin,

00:39:57: das kann Container sein, bei dem Dienstleister selber, also bei GitHub selber zum Beispiel,

00:40:01: oder es kann einen Aufruf zu einem eigenen Runner nennen, die sich, oder Worker, auf eine eigene

00:40:08: Maschine ausgeführt werden, dann holen die sich die Sources ab, also quasi den Code,

00:40:15: der in dem Repository ist, zusammen mit dem, was ich neu hinzufügen möchte und führt

00:40:19: dann Operationen für mich aus.

00:40:21: Und das können Tests sein, das können Kompilierungen sein, das können verschiedene Packetierungen

00:40:27: sein oder Formatierungen von Code.

00:40:29: Das können die Prozesse sein, die ich vielleicht händisch gemacht hätte und die auch immer

00:40:32: wieder Kern sind.

00:40:33: So, und wenn ich jetzt so eine Pipeline mir angucke und ich habe ein Node.js Projekt und

00:40:37: ... und sage, ich habe da sowieso meine Testdefinition, ...

00:40:39: ... weil wir uns darauf geeinigt haben, ...

00:40:40: ... dass jedes Feature auch sich selber testet.

00:40:43: Dann habe ich meine Testdefinitionsfiles ...

00:40:45: ... in einem bestimmten Ordner ...

00:40:47: ... und darauf kann logischerweise natürlich mein GitHub ...

00:40:49: ... zugreifen und sagen, in diesem Verzeichnis ...

00:40:51: ... sind alle meine Tests, ...

00:40:52: ... sie sind vielleicht auch da, ...

00:40:53: ... sind noch Dateien dazugekommen, weitere Test-Skripts.

00:40:56: Und dann möchte ich jedes Mal, ...

00:40:57: ... wenn dieser Pull-Request gemacht wird, ...

00:40:59: ... diese Tests ausführen ...

00:41:00: ... und erst, wenn das Ergebnis davon positiv war, ...

00:41:04: ... also keine Fehler oder keine ernst zu nehmenden Fehler ...

00:41:06: ... kommen, nur Warnings oder vielleicht sogar ...

00:41:08: ... keine Ausgaben, außer es ist alles in Ordnung.

00:41:11: Erst dann möchte ich, dass dieser Pull-Request ...

00:41:13: ... angenommen werden kann.

00:41:14: Da kann sich so eine Restriktion einsetzen.

00:41:16: Es kann erst dann angenommen werden, wenn das alles ...

00:41:19: ... grün ist.

00:41:19: Oder es kann einfach nur ein Hinweis für den ...

00:41:21: ... Reviewer sein, der sich dann gar nicht erst die ...

00:41:23: ... Arbeit machen muss, den Source Code per Hand ...

00:41:25: ... nochmal durchzugucken oder nochmal drüber zu ...

00:41:27: ... fliegen, ob die Änderungen alle so angenommen ...

00:41:29: ... werden können.

00:41:30: Da kann man schon direkt feststellen, ob es da ...

00:41:32: ... irgendwelche Konflikte gibt, ob es irgendwelche ...

00:41:34: ... Softwarekomponenten gibt, die nicht richtig ...

00:41:35: ... funktionieren.

00:41:36: Und dann wäre das schon mal einer von diesen Automatismen, die man wählen kann.

00:41:39: Das ist rein, dass das direkt zur Projektqualität bei und zur Fehlervermeidung.

00:41:45: Das kann noch einen Schritt weitergehen, dass man sagt, jeder Code, der in das Repository

00:41:50: committed wird, wird einmal im Gesamtprojekt integriert, dann zu einem Release gepackt und

00:41:56: dann werden generelle Tests für die Anwendung gebaut, dass man eine Gesamtqualitätaussage

00:42:01: über das Repository treffen kann, nachdem der Code eingeflossen ist und wie das Ganze

00:42:06: sich am Ende verhält. Man hat nicht nur die Feature-eigenen Tests, die ausgeführt werden,

00:42:10: sondern auch alle anderen und dann wird diese Integration in das Repository getestet. Das

00:42:14: ist der Fall, wie man dann mit solchen Tests umgehen würde oder was man da einbauen würde,

00:42:18: um solche Tests zu ermöglichen. Dann gibt es noch weitere Punkte, die sagen, wenn ich jetzt ein

00:42:23: Commitment in einem gewissen Keyboard drin habe, wird automatisch ein Release erzeugt. Also es werden

00:42:27: alle entwicklungsrelevanten Dateien sozusagen ignoriert und alle Source Code Files minifight

00:42:34: klein gemacht und sparsam oder obfiskated, nicht lesbar gemacht. Und dann werden diese ganzen

00:42:40: Files, die diesen Prozess durchlaufen haben, in ein Archiv gepackt als installierbarer Datei

00:42:45: oder als Source Code Ordner oder als komprimiertes ZIP-Archiv oder RAR-Archiv. Und dann wird das in

00:42:51: diesem Repository als Release angelegt und eine Change Lock erstellt beispielsweise. All diese

00:42:56: Schritte lassen sich mit solchen Automatismen vereinfachen. Da steckt man einmal Kraft rein,

00:43:01: einmal Arbeit einreihen, das zu machen, maintained und ...

00:43:04: ... entwickelte die natürlich kontinuierlich weiter. Aber ...

00:43:06: ... am Ende des Tages spart man super viel Zeit dadurch, ...

00:43:08: ... dass man diese ganzen Sachen nicht manuell triggern ...

00:43:10: ... muss und gegebenenfalls, dass ein Review oder ein ...

00:43:12: ... manuelles Paketieren am Ende notwendig ist.

00:43:15: Da könnte ich jetzt vermutlich tagelang darüber ...

00:43:18: ... weiter sprechen, weil das einfach das Geschäftsprozess, ...

00:43:20: ... der Geschäftssinn oder das gesamte, die Daseinsberechtigung ...

00:43:25: ... von GitHub und GitLab und Co. darstellt. Aber alleine ...

00:43:28: ... diese CICD-Features, die direkt an die Versionierungssoftware ...

00:43:30: ... die jetzt mittlerweile drangekoppelt sind, ...

00:43:32: ... krempeln praktisch die gesamte Art und Weise, ...

00:43:35: ... wie wir in Projekten arbeiten, echt auf links.

00:43:38: Aber sparen uns enorm Zeit ...

00:43:41: ... und minimieren da tatsächlich die Fehler, ...

00:43:43: ... wenn man das richtig angeht.

00:43:44: Und ...

00:43:45: ... ja, das finde ich, ist so ein Ausblick, ...

00:43:48: ... wenn man jetzt mal mit Visionierung starten will, ...

00:43:50: ... kann man das so als sein Ziel sehen, ...

00:43:51: ... dass man hinter einem vollautomatisiertes Repository hat, ...

00:43:54: ... wo alle im Team super miteinander arbeiten können, ...

00:43:56: ... wo viele Fehlerquellen sofort ausgeschaltet werden, ...

00:43:58: ... wo man auch am Ende des Tages ...

00:44:00: ... richtig professionell Releases ausliefern kann, ...

00:44:03: ... ohne dass wir jetzt schon in dieser oder in der letzten Folge ...

00:44:07: ... unheimlich tief in diese Features reingeht, ...

00:44:09: ... die es da noch gibt, da könnte man wirklich noch Tage füllen.

00:44:12: Sollten das jetzt die Sachen sein, die man im Hinterkopf hat, ...

00:44:15: ... um selber starten zu können.

00:44:16: Und ja, dann wäre es auch an der Stelle schon, ...

00:44:19: ... Caro, was ist dein Fazit dazu?

00:44:22: Ich meine, der Titel sagt es eigentlich schon, ...

00:44:23: ... aber wie würdest du das zusammenfassen?

00:44:26: Was ist dein Fazit zum Thema Versionierung ...

00:44:29: Bezogen auf die beiden Folgen jetzt hier und darüber hinaus.

00:44:31: Ja, Versenierung ist cool.

00:44:33: Ja, toll. Danke.

00:44:36: Nein, also nach wie vor, ich hab's ja schon öfter erwähnt, ich bin ein riesiger Fan.

00:44:42: Für mich hat das sehr viel verändert von manueller Arbeit hin zur halbautomatisierten Arbeit

00:44:50: und dann vielleicht auch irgendwann zur automatisierten Arbeit, wenn wir die Themen betrachten,

00:44:55: die du jetzt noch zuletzt erwähnt hast.

00:44:57: Und ich kann auf jeden Fall jedem raten, das auszuprobieren,

00:45:01: dass vielleicht auch ...

00:45:02: Keine Ahnung, wenn man das in einem Uni-Projekt zum Beispiel benutzt,

00:45:06: dann vielleicht auch mal auszuprobieren,

00:45:09: wie das ist, mit einem Kommiliton zusammenzuarbeiten,

00:45:11: einfach um dieses Ping-Pong so ein bisschen kennenzulernen,

00:45:15: so ein bisschen die Zusammenarbeit zu verstehen.

00:45:18: Weil es dann doch schon ein großer Unterschied ist,

00:45:20: ob man alleine was macht oder halt zusammen.

00:45:23: Und ... ja, also, mach ich.

00:45:25: (Lachen)

00:45:27: Versionierung ist cool, mache ich.

00:45:29: Ich bin auch dabei.

00:45:30: Das ist ein super Schlusswort für diese Folge diese Woche.

00:45:34: Ich bedanke mich fürs Zuhören.

00:45:36: Vielen Dank, Caro, für das tolle Gespräch und für dieses interessante Thema.

00:45:39: Ich hoffe, wir können so viele wie möglich dazu bewegen, Versionierung einzusetzen.

00:45:43: Das macht das Leben leichter und schließt viele Fehler aus.

00:45:46: Bis in zwei Wochen, Caro.

00:45:48: Ja, bis dann.

00:45:49: [Musik]