Versionskontrolle einer Website: Dev / Production-Frontend-Dateien

Ich versuche mir eine bessere Möglichkeit zur Versionskontrolle unserer Website-Projekte auszudenken. Denken Sie daran, ich bin nur ein Front-End-Entwickler, daher habe ich keine profunden Kenntnisse in VCS.

Workflows ändern sich und frühere Versionskontrollgewohnheiten sind veraltet. Das Hauptproblem besteht darin, dass für jede Website zwei Arrays von Front-End-Dateien vorhanden sind.

Die Entwicklungsumgebung (weniger Dateien, unkomprimierte JS, Bilder usw.). Die Build-Umgebung "verschluckt" (alles komprimiert und für Menschen nicht lesbar).

Sie können eine Website mit ihren Quelldateien jedoch nicht verkaufen. Nun, es fühlt sich nicht ganz richtig an.

Es gibt die Lösung, zwei Repos zu haben: einen Build, einen Dev, wobei gulp Dev-Dateien an das Build-Verzeichnis sendet. Aber es ist mühsam zu warten, bei kleinen Unternehmen finde ich es nicht so toll. Es entstehen viele Repos, und die Leute müssen mit mehreren Repos auskommen, manchmal sogar mit einem SVN-Repo. Es treten Probleme auf.

Es gibt also auch die Lösung, 1 Repo zu haben: die Quelldateien und die Produktdateien im selben SVN. Dann müssen jedoch die Quelldateien entfernt werden, wenn die Website vom lokalen Entwicklungsserver zum Produktionsserver wechselt (daher befinden sich je nach Speicherort, Entwickler oder Produktion unterschiedliche Dateien in einem einzelnen Repository). Nach allem, was ich gehört habe, ist es nicht gut

Was ist die richtige Art und Weise, einen Gulp-Front-End-Workflow in Bezug auf das Versionskontrollsystem zu verwalten?

Eine Grundregel der Quellcodeverwaltung ist, dass Sie nur manuell geschriebene Artefakte in das Repo (die ursprünglichen Quelldateien) einfügen müssen. Alles, was "kompiliert" oder "generiert" werden kann, muss dort nicht gespeichert werden, da dies zu Redundanz führt . Man kann (optional) Zwischenausgaben / Teile eines Erstellungsprozesses in einem Repo speichern (manchmal auch als Artefakte bezeichnet), wenn die Schritte zum Reproduzieren nicht vollautomatisch sind, oder zu Caching-Zwecken, wenn die Erstellungsschritte zum Reproduzieren der Ausgabe langsam sind .

Wenn Sie also einen vollautomatischen Prozess zum Generieren der Produktionsdateien aus Ihren Entwicklungsquelldateien haben, müssen Sie nur die Entwicklungsdateien in die Quellcodeverwaltung stellen (zusammen mit den Skripten zum Erstellen der Produktionsdateien). Wenn nicht, richten Sie einen solchen Prozess ein. Stellen Sie sicher, dass niemand manuell mit den Produktionsdateien herumspielen muss, nachdem sie aus der Quelle generiert wurden. Wenn Sie "direkt" von Ihrem VCS aus bereitstellen möchten, stellen Sie sicher, dass Sie über ein Bereitstellungsskript verfügen, das die Entwicklungsquelldateien aus der Quellcodeverwaltung entfernt, die "Verschluckung" durchführt und die resultierenden Dateien in einem Schritt an die Produktion überträgt.

Wenn Sie die Quellcodeverwaltung auch als "Poor Mans Backup" oder als Cache für Ihre Produktionsdateien verwenden möchten, können Sie zu diesem Zweck ein zweites Repo einrichten und nach der Generierung eine Kopie der Produktionsdateistruktur dort ablegen. Dieses Repo dient nicht zur Entwicklung, und nachdem es eingerichtet wurde, sollten Sie es nicht manuell warten müssen. Stellen Sie daher sicher , dass keine manuellen Schritte zum Erstellen von Sicherungen in diesem "Prod Repo" erforderlich sind. Fügen Sie die erforderlichen Schritte in das Bereitstellungsskript ein, mit dem die Sicherung automatisch durchgeführt wird. Überlegen Sie, ob Sie ein separates Sicherungsskript hinzufügen möchten, wenn Sie manuelle Änderungen an der Produktion nach der Bereitstellung nicht verhindern können. Auf diese Weise können Sie den Prozess auch dann beibehalten, wenn Sie nur über begrenzte Ressourcen verfügen.

Und ja, dies sollte ein streng getrenntes zweites Repo sein, da es einen völlig anderen Zweck und einen anderen Lebenszyklus hat als Ihr Entwickler-Repo. Sie verwenden es nur für Sicherungen, nicht für die Quellcodeverwaltung, was ein anderer Prozess ist.