In diesem Teil erklärt: CI/CD · Deployment · Staging

In Teil 2 haben wir gesehen, wie neue Zutaten sicher auf die Pizza kommen. Jetzt die letzte Frage: Wie kommt die fertige Pizza eigentlich sicher zum Gast? Denn zwischen „in der Küche fertig“ und „der Gast isst“ liegt ein Weg, und genau der macht den Unterschied zwischen Profi und Chaos.

Der Weg der Pizza: Küche, Ausgabe, Gast

Eine Pizza geht nicht direkt vom Herd auf den Tisch. Sie nimmt drei Stationen:

1. Die Küche. Hier wird gekocht und probiert. Alles darf schiefgehen, kein Gast merkt davon etwas. Bei Software: die Entwicklung (oft „dev“ genannt).
2. Die Ausgabe. Die Pizza steht fertig unter der Wärmelampe, und es gibt einen letzten prüfenden Blick, bevor sie rausgeht. Bei Software: Staging (kurz „stage“), eine originalgetreue Kopie des echten Systems zum letzten Test.
3. Der Gast. Die Pizza kommt auf den Tisch, jetzt zählt es. Bei Software: Produktion (live), das, was deine Besucher sehen.

Küche, Ausgabe, Gast. Dev, Stage, Produktion. Das ist der Weg von der Idee bis live.

Die Frage an der Ausgabe: ist die Pizza gut?

Bei einer guten Pizzeria läuft dieser Weg nicht auf Zuruf. An der Ausgabe wird jede Pizza geprüft, bevor sie zum Gast geht: richtig belegt, durchgebacken, nichts vergessen? Nur wenn sie besteht, geht sie raus.

Genau diese eingebaute, automatische Prüfung ist der Kern von CI/CD:

• CI (Continuous Integration), fortlaufendes Zusammenführen. Jede kleine Änderung wird sofort mit dem Rest zusammengefügt und automatisch getestet. So fällt ein Fehler auf, solange er noch klein und billig zu beheben ist, nicht erst beim Gast.
• CD (Continuous Deployment), fortlaufendes Ausliefern. Besteht eine Änderung alle Tests, wird sie automatisch und sicher live gestellt. Kein manuelles Herumkopieren, bei dem nachts jemand das Falsche hochlädt.

Das Ausliefern selbst, also die fertige Pizza auf den Tisch bringen, heißt Deployment (englisch für Ausbringen). „Deployen“ ist einfach: live stellen.

Der Nutzen, in einem Satz

Für dich als Auftraggeber lässt sich der ganze Aufwand in einem Satz zusammenfassen: Nichts geht ungetestet auf deine Seite. Kein „nach dem Update ist plötzlich alles kaputt“, kein Bangen bei jeder Änderung. Das ist kein Luxus, sondern der Unterschied zwischen einem Profi-Setup und Gebastel.

Was das für dein Projekt heißt

Ob dein Projekt so ausgeliefert wird oder ob jemand Änderungen direkt und ungetestet ins Live-System schiebt, merkst du erst, wenn es kracht. Mit einem sauberen Weg über Küche, Ausgabe und Gast passiert genau das nicht: Jede Änderung wird geprüft, bevor sie deine Besucher erreicht. Und geht doch mal was daneben, kommt man dank Versionierung (siehe Teil 1) einfach auf den letzten funktionierenden Stand zurück.

Genau so bauen wir bei isarcode: versioniert, über eine saubere Pipeline, mit automatischer Prüfung. Nicht weil es schick klingt, sondern weil es dein Projekt vor den Pannen schützt, die sonst richtig teuer werden.

Häufige Fragen

Was ist CI/CD? Ein automatischer Ablauf, der jede Änderung an einer Software erst testet und dann, wenn sie besteht, sicher live stellt. CI steht fürs fortlaufende Testen, CD fürs fortlaufende Ausliefern.

Was ist der Unterschied zwischen Dev, Stage und Production? Dev ist die Entwicklung (die Küche), Stage der letzte Test auf einer Kopie des echten Systems (die Ausgabe), Production das Live-System, das die Nutzer sehen (der Gast).

Was bedeutet deployen? Software live stellen, also den fertigen, getesteten Stand für die Nutzer verfügbar machen. In der Pizza-Analogie: die geprüfte Pizza zum Gast bringen.

Ist CI/CD Overkill für kleine Projekte? Nein. Gerade kleine Projekte profitieren, weil ein Ausfall dort oft niemand auffängt. Der Ablauf lässt sich schlank halten, weglassen sollte man ihn nicht.

Und jetzt?

Du willst wissen, wie sauber dein aktuelles Projekt ausgeliefert wird, oder von Anfang an ein Setup ohne böse Überraschungen? Lass uns reden. Wir schauen es uns an und sagen dir ehrlich, wo es steht.

In diesem Teil erklärt: Branch · Feature-Branch · Merge · Fork · Main / Master

In Teil 1 haben wir geklärt, was Versionierung, Git und ein Repo sind. Jetzt geht es um die Frage, die im Alltag am häufigsten aufkommt: Wie kommen neue Ideen in ein Projekt, ohne dass das, was gerade funktioniert, kaputtgeht? Und wieder hilft die Pizza.

Die Margherita ist der offizielle Stand: main

Stell dir deine Pizza als das fertige Produkt vor. Die Margherita ist die Standard-Pizza, die auf der Karte steht und die jeder Gast bekommt. In der Git-Welt ist das der main (früher meist master genannt, dazu gleich mehr): der offizielle, ausgelieferte Stand. Was in main steht, ist das, was zählt. Deshalb baut man daran nicht mal eben leichtfertig herum.

Etwas Neues ausprobieren, ohne die Margherita zu ruinieren: der Branch

Jetzt kommt ein Wunsch rein: „Ich hätte gern eine Salami-Variante.“ So ein Wunsch heißt im Fachjargon Feature Request, auf Deutsch schlicht die Anforderung, etwas Neues zu bauen.

Du wärst verrückt, dafür die Margherita der wartenden Gäste umzubauen. Stattdessen fängst du daneben an: Du nimmst die Margherita als Ausgangspunkt und baust in Ruhe deine Salami-Version auf. Die Original-Pizza bleibt völlig unberührt.

Genau das ist ein Branch (englisch für Zweig, gesprochen „Bräntsch“). Auf Deutsch: eine Abzweigung, an der man gefahrlos werkeln kann. Weil es hier um genau eine neue Sache geht (die Salami), nennt man das eine Feature-Branch, den Zweig für ein bestimmtes neues Feature.

Die Salami kommt auf die Pizza: der Merge

Deine Salami-Variante ist fertig und gut. Jetzt soll sie offiziell werden, also Teil der echten Pizza. Dieses Zusammenführen heißt Merge (englisch für verschmelzen, gesprochen „Mördsch“). Aus Margherita plus erprobter Salami wird jetzt offiziell die Pizza Salami. Die neue Zutat ist eingearbeitet, sauber und bewusst.

Meistens klappt das reibungslos. Manchmal haben zwei Köche gleichzeitig an derselben Stelle geschraubt, der eine will Basilikum, der andere Oregano. Dann gibt es einen Merge-Konflikt: Das System sagt „hier widersprechen sich zwei Änderungen, das kann ich nicht allein entscheiden“, und ein Mensch legt fest, was draufkommt. Kein Drama, nur eine bewusste Entscheidung an der richtigen Stelle.

Eine ganz eigene Pizza-Linie: der Fork

Ein Branch ist eine Zutat mehr auf derselben Pizza. Ein Fork ist etwas anderes: Du nimmst die ganze Pizza und machst daraus deine eigene, unabhängige Linie.

Beispiele: Du nimmst die Margherita, wirfst die Tomatensauce raus und machst eine weiße Pizza. Oder du nimmst nur den Teig und machst daraus Pizzabrot. Ab diesem Moment lebt deine Version ihr eigenes Leben, mit ihrem eigenen offiziellen Stand, ihrem eigenen main. Sie hat mit dem Original nichts mehr zu tun.

Das ist ein Fork (englisch für Gabelung): eine eigenständige Kopie des ganzen Projekts, die einen eigenen Weg geht. In der Open-Source-Welt entstehen so aus einem Projekt viele.

Main oder Master? Nur ein Namenswechsel

Kurz zur häufigsten Verwirrung: Mal heißt der offizielle Stand main, mal master. Das ist dieselbe Sache, nur ein neuerer Name. Früher war „master“ üblich, heute nennen die meisten Projekte und Plattformen wie GitLab und GitHub ihn „main“. Inhaltlich ändert sich nichts, es ist und bleibt die Pizza auf der Karte.

Was das für dein Projekt heißt

Der Grund, warum das existiert, ist einfach: So kann ein Team an vielen neuen Dingen gleichzeitig arbeiten, ohne sich gegenseitig das Funktionierende kaputtzumachen. Jede neue Idee wächst sicher in ihrem eigenen Zweig heran und kommt erst dann in die offizielle Version, wenn sie fertig und geprüft ist.

Wie diese Prüfung automatisch abläuft und wie die fertige Pizza dann sicher zum Gast kommt, schauen wir uns in Teil 3 an.

Häufige Fragen

Was ist ein Branch in Git? Eine Abzweigung, an der man etwas Neues bauen kann, ohne den offiziellen Stand (main) anzufassen. Ist das Neue fertig, wird es zusammengeführt.

Was ist ein Merge? Das Zusammenführen einer fertigen Änderung mit dem offiziellen Stand. Aus der Margherita plus erprobter Salami wird die offizielle Pizza Salami.

Was ist der Unterschied zwischen Branch und Fork? Ein Branch ist eine Variante innerhalb desselben Projekts. Ein Fork ist eine komplett eigene, unabhängige Kopie mit eigenem offiziellen Stand.

Was bedeutet main bzw. master? Beides bezeichnet den offiziellen, ausgelieferten Stand eines Projekts. „main“ ist die modernere Bezeichnung für dasselbe.

Und jetzt?

Du willst, dass neue Features in deinem Projekt sauber und ohne Risiko fürs Laufende entstehen? Genau so arbeiten wir. Lass uns reden, wir zeigen dir, wie das in der Praxis aussieht.

In diesem Teil erklärt: Versionierung · Git · GitLab · GitHub · Repository

Wenn du mit Software-Leuten zu tun hast, fallen dauernd dieselben Wörter: Git, Repo, GitLab, versioniert. Und selbst wenn man es selbst benutzt, ist es gar nicht so leicht, das jemandem zu erklären, der nicht täglich damit arbeitet.

Also machen wir es an etwas fest, das jeder kennt: einer Pizza. Stell dir dein Projekt wie eine Pizza vor, die nach und nach belegt wird. In Teil 1 klären wir die Grundbegriffe. In den nächsten Teilen kommen dann Branch, Merge und der Weg live dazu.

Warum überhaupt Versionierung?

Stell dir vor, du belegst deine Pizza Schritt für Schritt: erst Tomatensauce, dann Käse, dann Basilikum. Und bei jedem Schritt machst du ein Foto. Wenn dir am Ende der Basilikum doch nicht passt, ist das kein Problem, du schaust auf das Foto von vorher und weißt genau, wie die Pizza ohne Basilikum aussah. Du kannst jederzeit zurück.

Genau das ist Versionierung: Bei jeder Änderung wird der aktuelle Stand festgehalten. Nichts geht verloren, jeder Schritt ist nachvollziehbar, und du kannst zu jedem früheren Stand zurückspringen. Bei Software ist das Gold wert: Geht nach einer Änderung etwas kaputt, holt man einfach den letzten funktionierenden Stand zurück, statt in Panik zu suchen.

Git: das Werkzeug dafür

Diese Fotos macht bei Software nicht ein Mensch, sondern ein Werkzeug. Das gängigste heißt Git. Git hält jeden Zwischenstand deines Projekts fest, merkt sich, wer wann was geändert hat und warum, und lässt dich jederzeit zwischen den Ständen hin und her springen.

Git ist der De-facto-Standard, also das, was praktisch alle in der Software-Welt benutzen. Du musst es nicht selbst bedienen können. Aber es hilft zu wissen: Wenn dein Dienstleister „mit Git arbeitet“, heißt das, dein Projekt ist sauber versioniert und nichts geht unkontrolliert verloren.

Git, GitLab, GitHub: was ist der Unterschied?

Hier verwechseln viele etwas, und die Auflösung ist simpel:

• Git ist das Prinzip, das Werkzeug.
• GitLab und GitHub sind Anbieter, bei denen dein Projekt online liegt und wo das Team zusammenarbeitet.

Auf Deutsch wie bei der Post: E-Mail ist das Prinzip, Gmail oder Outlook sind Anbieter, die E-Mail für dich bereitstellen. Genauso ist Git das Prinzip, GitLab und GitHub sind zwei bekannte Anbieter dafür. Wir bei isarcode arbeiten mit GitLab, funktional nehmen die beiden sich wenig.

Das Repo: wo dein Projekt lebt

Bleibt ein Wort: Repository, kurz Repo. Das ist schlicht der Ort, an dem ein Projekt mit seiner kompletten Geschichte liegt. In unserem Bild: der Ordner, in dem deine Pizza und alle Fotos von jedem Belegungs-Schritt aufbewahrt werden.

Ein Projekt, ein Repo. Darin steckt alles: der aktuelle Stand und die ganze Historie. Liegt das Repo bei GitLab, kann das ganze Team darauf zugreifen, gemeinsam daran arbeiten und trotzdem den Überblick behalten, wer was gemacht hat.

Was das für dein Projekt heißt

Du musst nichts davon selbst können. Aber wenn du die vier Wörter einordnen kannst, verstehst du, was hinter „wir arbeiten sauber und versioniert“ steckt, und das ist kein Nice-to-have:

• Nichts geht unkontrolliert verloren.
• Jede Änderung ist nachvollziehbar.
• Geht was schief, gibt es immer einen Weg zurück.

Das ist der Unterschied zwischen einem Profi-Setup und „wir haben da mal was hochgeladen und hoffen, dass es hält“. Wie aus diesen Grundlagen ein sicherer Weg bis zur fertigen, live geschalteten Software wird, schauen wir uns in den nächsten Teilen an.

Häufige Fragen

Was ist der Unterschied zwischen Git und GitHub? Git ist das Werkzeug zum Versionieren, GitHub ist ein Anbieter, bei dem Git-Projekte online liegen. Wie E-Mail (das Prinzip) und Gmail (ein Anbieter). GitLab ist ein weiterer solcher Anbieter.

Was ist ein Repository? Der Ort, an dem ein Projekt samt seiner kompletten Änderungs-Geschichte gespeichert ist. Meist kurz „Repo“ genannt.

Brauche ich als Auftraggeber Git-Kenntnisse? Nein. Es reicht zu wissen, dass es Versionierung gibt und dass ein guter Dienstleister sie nutzt. Genau das schützt dein Projekt vor Datenverlust und Chaos.

Ist Versionierung nur was für große Projekte? Nein. Gerade kleine Projekte profitieren, weil ein verlorener Stand dort oft niemand auffängt. Der Aufwand ist minimal, der Schutz groß.

Und jetzt?

Du willst wissen, ob dein aktuelles Projekt eigentlich sauber versioniert ist, oder von Anfang an auf ein Setup ohne böse Überraschungen? Lass uns reden. Wir schauen es uns an und sagen dir ehrlich, wo es steht.