Von HTML-Datei zu Produktionssystem: Wie ich eine kostenlose CI/CD-Pipeline an einem Wochenende gebaut habe

Letzten Monat hatte ich eine einfache persönliche Website. Eine HTML-Datei. Etwas CSS. Nichts Besonderes. Wenn ich sie aktualisieren wollte, hab ich die Datei geöffnet, Änderungen gemacht, gespeichert und manuell per FTP hochgeladen.

Es hat funktioniert. Aber es hat nicht wirklich funktioniert .

Keine Versionierung. Kein Collaboration-Workflow. Keine Deployment-Automatisierung. Nur ich, ein Texteditor und viele manuelle Schritte, die sich 2025 zunehmend veraltet anfühlten.

Also hab ich ein Wochenende damit verbracht, das zu bauen, worauf jedes Tech-Produkt läuft: eine ordentliche CI/CD-Pipeline. Hier ist, was ich gelernt habe, und warum du diesen Stack verstehen solltest, auch wenn du kein Engineer bist.

Share

Das Problem: Technical Debt in Verkleidung

Die meisten Nebenprojekte fangen einfach an. Eine Landing Page. Ein Portfolio. Ein Blog. Du wirfst eine einzelne HTML-Datei online und nennst es fertig.

Aber das, was du tatsächlich baust:

• Keine Versionskontrolle — Was kaputt gemacht? Hoffentlich hast du ein Backup.
• Manuelles Deployment — Jedes Update erfordert, dass du dich an die Schritte erinnerst.
• Keine Test-Umgebung — Änderungen gehen direkt in Production.
• Collaboration-Barriere — Willst du Hilfe? Schick jemandem die Datei per E-Mail?

Das ist nicht nur unbequem. Es ist Technical Debt, die sich mit der Zeit potenziert.

Die Lösung: Moderne Infrastructure ohne Enterprise-Budget

Ich hab meine Site mit einem Stack neu gebaut, der 0€/Monat kostet und mir Enterprise-Grade-Tooling gibt:

GitHub → Versionskontrolle + Collaboration Cloudflare Pages → Automatisiertes Deployment + globales CDN VS Code → Professionelle Entwicklungsumgebung

Das Ergebnis? Jedes Mal, wenn ich Code committe, aktualisiert sich meine Site automatisch. Keine manuellen Schritte. Keine Deployment-Ängste. Einfach pushen und deployen.

Die technische Reise: 7 Phasen

Lass mich dir genau zeigen, was ich gebaut habe und warum jede Phase wichtig war.

Phase 1: Versionskontrolle mit Git

Was ich gemacht habe: Ein Git-Repository initialisiert und mit GitHub verbunden.

Warum es wichtig ist: Versionskontrolle ist die Grundlage aller modernen Software-Entwicklung. Es geht nicht nur ums Tracking von Änderungen — es geht darum, Collaboration, Experimente und Recovery zu ermöglichen.

Commands, die ich verwendet habe:

git init git add . git commit -m "Initial commit" git remote add origin https://github.com/username/sonntagplatz.git git push -u origin main Die PM-Lektion: Jede Produktentscheidung sollte reversibel sein. Git macht das für Code möglich. Überleg dir, wie du dasselbe Prinzip auf Product Features anwendest.

Phase 2: CI/CD-Pipeline mit Cloudflare Pages

Was ich gemacht habe: Mein GitHub-Repository mit Cloudflare Pages verbunden. Automatische Deployments bei jedem Push auf den main-Branch konfiguriert.

Warum es wichtig ist: Continuous Deployment bedeutet, dein Code erreicht User sofort. Kein Warten. Keine manuelle Intervention. Keine “Deployment-Tage”.

Konfiguration:

• Framework Preset: None (statisches HTML)
• Build Command: Nicht erforderlich
• Build Output Directory: / (Root)
• Branch: main

Die PM-Lektion: Deployment-Frequenz ist ein Prädiktor für Team Velocity. Je einfacher das Shippen, desto schneller iterierst du.

Phase 3: Architektonisches Refactoring

Was ich gemacht habe: Alle Inline-Styles aus meinem HTML in eine separate style.css -Datei verschoben. Eine modulare Struktur geschaffen, die Content von Präsentation trennt.

Warum es wichtig ist: Skalierbarkeit erfordert Separation of Concerns. Wenn dein Design System an einem Ort lebt, kannst du die gesamte Site mit einer einzigen Änderung updaten.

Vorher:

<div style="display: grid; grid-template-columns: repeat(4, 1fr);"> <!-- Content gemischt mit Styling --> </div> Nachher:

<!-- index.html --> <div class="four-column-grid"> <!-- Sauberes, semantisches HTML --> </div> /* style.css */ .four-column-grid { display: grid; grid-template-columns: repeat(4, 1fr); gap: 2rem; } Die PM-Lektion: Technische Architektur spiegelt Produkt-Architektur. Modulare Systeme skalieren. Monolithische Systeme brechen.

Phase 4: Multi-Page-Architektur

Was ich gemacht habe: Eine zweite Page ( und.html ) für ein spezifisches Content-Vertical erstellt, um zu beweisen, dass das System über eine einzelne Page hinaus skalieren kann.

Warum es wichtig ist: Ein skalierbares System ist nicht theoretisch — es wird bewiesen, indem man es tatsächlich skaliert. Diese Phase hat validiert, dass die Architektur mehrere Produkte/Pages unterstützen kann.

Die PM-Lektion: Bau für heute, aber validiere für morgen. One-Page-Solutions sehen einfach aus, bis du wachsen musst.

Phase 5: Responsive Design

Was ich gemacht habe: CSS Media Queries implementiert, um die Site mobile-responsive zu machen. Das 4-Spalten-Desktop-Grid stackt sich auf Mobile in eine vertikale Liste.

Warum es wichtig ist: 2025 übersteigt Mobile Traffic oft Desktop. Responsive Design ist kein Nice-to-have — es sind Table Stakes.

Code:

@media (max-width: 768px) { .four-column-grid { grid-template-columns: 1fr; } } Die PM-Lektion: Versteh den Kontext deiner User. Design-Entscheidungen sollten datenbasiert sein, nicht annahmenbasiert.

Phase 6: Professionelle E-Mail-Infrastructure

Was ich gemacht habe: Cloudflare Email Routing konfiguriert, um eine Custom-Domain-E-Mail ( reuven@sonntagplatz.com ) zu erstellen, die zu meinem persönlichen Gmail weiterleitet.

Warum es wichtig ist: Professionalität steckt im Detail. reuven@sonntagplatz.com signalisiert Legitimität auf eine Art, wie reuven.random123@gmail.com es nie tun wird.

Setup-Schritte:

• MX Records in Cloudflare DNS hinzugefügt
• E-Mail-Weiterleitungsregeln konfiguriert
• “Send Mail As” in Gmail eingerichtet
• SPF- und DKIM-Records verifiziert

Die PM-Lektion: Brand Consistency geht über dein Produkt hinaus. Jeder Touchpoint zählt.

Phase 7: Analytics und Monitoring

Was ich gemacht habe: Cloudflare Web Analytics mit einem einfachen JavaScript-Beacon integriert, um Page Views und User-Verhalten zu tracken.

Warum es wichtig ist: Du kannst nicht verbessern, was du nicht misst. Analytics verwandeln Annahmen in Daten.

Code:

<script defer src='https://static.cloudflareinsights.com/beacon.min.js' data-cf-beacon='{"token": "your-token-here"}'></script> Die PM-Lektion: Instrumentation sollte von Tag eins an eingebaut sein, nicht später angebaut werden.

Das Vorher/Nachher

Vorher Nachher Einzelne HTML-Datei Multi-Page Git-tracked Repository Manuelles “Edit & Save” Automatisierte CI/CD-Pipeline Hardcoded Standard-Fonts High-End-Typografie (Inter 300/Source Serif) Keine Kontaktmethode Professionelle Domain-E-Mail Null Traffic-Daten Live Analytics Dashboard Nur-lokal Editing Cloud-basierter Collaboration-Workflow

Warum Product Manager sich kümmern sollten

Hier ist die unbequeme Wahrheit: Die meisten PMs verstehen die Infrastructure, auf der ihre Produkte laufen, nicht tiefgehend.

Sie wissen was deployed wird. Aber nicht wie .

CI/CD zu verstehen ist nicht nur technisches Wissen — es ist strategischer Vorteil:

• Bessere technische Gespräche: Wenn Engineers sagen “Deployment ist riskant”, wirst du verstehen warum und wie man es derisked.
• Smartere Trade-offs: Du wirst wissen, wann “just add a feature flag” eine vernünftige Frage ist vs. eine Woche Infrastructure-Arbeit.
• Schnelleres Shipping: Du wirst für Deployment-Automatisierung eintreten, weil du die Produktivitätsgewinne selbst gespürt hast.
• Credibility bei Engineers: Hands-on technische Erfahrung baut Vertrauen zu deinem Engineering-Team auf.
• Kostenbewusstsein: Du wirst erkennen, wann ein 50.000€-Enterprise-Tool Overkill für ein Problem ist, das eine 0€-Open-Source-Lösung besser handhabt.

Ich schlage nicht vor, dass jeder PM ein Engineer werden muss. Aber die Deployment-Pipeline zu verstehen — von Commit bis Production — macht dich zu einem besseren Product Leader.

Was dieser Stack beweist

Du brauchst nicht:

• Ein Engineering-Team
• Ein DevOps-Budget
• Enterprise-Tooling
• Monate der Planung

Du brauchst:

• Bereitschaft zu lernen
• Ein Wochenende fokussierte Arbeit
• Moderne, kostenlose Tools
• Grundverständnis von Web-Fundamentals

Die Einschränkung ist nicht Geld oder Ressourcen. Es ist das Verständnis der Tools, die dir zur Verfügung stehen.

Die Einladung

Ich hab das an einem Wochenende gebaut. Du könntest es auch.

Falls Interesse besteht, überlege ich, einen kurzen, praktischen Guide zu erstellen, der genau dieses Setup Schritt-für-Schritt durchgeht:

• Teil 1: GitHub und Git-Workflows einrichten
• Teil 2: Cloudflare Pages für automatisierte Deployments verbinden
• Teil 3: Für Scale architektieren (CSS-Refactoring, Multi-Page-Sites)
• Teil 4: Professionelle Touches (Custom E-Mail, Analytics, Responsive Design)
• Teil 5: Advanced Workflows (Staging-Umgebungen, Custom Domains, Performance-Optimierung)

Jeder Teil würde beinhalten:

• Exakte Commands und Code-Samples
• Screenshots von jedem Konfigurationsschritt
• Häufige Fallstricke und wie man sie vermeidet
• Product-Management-Insights aus jeder Phase
• Kosten-Breakdown (Spoiler: alles ist kostenlos)

Würdest du diesen Guide lesen?

Falls ja, lass es mich in den Kommentaren wissen oder antworte auf diese E-Mail. Wenn ich genug Interesse bekomme, erstelle ich ihn als kostenlose Ressource für Product Manager, die ihr technisches Verständnis leveln wollen.

Du bist dran

Hast du deine eigene CI/CD-Pipeline gebaut? Was war dein größter “Aha”-Moment?

Arbeitest du noch mit manuellen Deployments? Was hält dich davon ab zu automatisieren?

Schreib einen Kommentar. Ich lese und beantworte jeden.

Und wenn du das wertvoll fandest, teile es mit einem PM, der neugierig auf die technische Seite von Product Development ist.

Abonniere, um zukünftige Posts über Product Management, technische Workflows und Building in Public zu bekommen.

Subscribe now

Über den Autor: Ich bin ein Product Manager, der glaubt, dass die besten PMs die technische Foundation ihres Produkts verstehen. Ich schreibe über moderne Infrastructure, Deployment-Workflows und die Schnittstelle von Product und Engineering. Folge mir auf sonntagplatz.com .