Sollte minimiertes CSS in Git gespeichert werden?

10

Ich verwende Gulp, um aus meinem SASS-Code für ein Projekt, an dem ich arbeite, minimiertes CSS zu generieren.

Ich habe mich gefragt, ob es als bewährte Methode angesehen wird, dieses minimierte CSS zu regenerieren, wenn Live von Git übertragen wird ...

oder

Um die minimierten CSS-Dateien in Git zu speichern, damit sie ohne weitere Arbeit des Servers automatisch live in die Produktion übertragen werden?

Ich würde die Ideen der Leute dazu schätzen. Vielen Dank!

Connor Gurney
quelle
Es gibt nur einen Ort, an dem css / js / etc. Minimiert wurde. sollte gespeichert werden : /dev/null.
R .. GitHub STOP HELPING ICE
(Das liegt daran, dass Ihr Webserver perfekt in der Lage ist, GZIP-Transport zu verwenden.)
R .. GitHub STOP HELPING ICE
Wenn Sie sowohl komprimiertes als auch unkomprimiertes CSS speichern, haben Sie jetzt zwei Versionen derselben Sache. Welches ist die kanonische Version? Es ist einfach, sich das Szenario vorzustellen, in dem ein Entwickler das komprimierte CSS und ein anderer das unkomprimierte CSS aktualisiert. Ihre beiden Vermögenswerte sind jetzt auseinander gegangen. Natürlich sollte der Prozess dies verhindern, aber es ist eine realistische Perspektive, zum Beispiel mit einem neuen Entwickler im Team.
Qwerky

Antworten:

13

"Es hängt davon ab, ob." Für normales Entwicklungs-Tracking, nein. Für Cloud- und DevOps-Bereitstellungen ist dies jedoch häufig praktisch oder sogar erforderlich.

Meistens ist @ptyx korrekt . In der Tat könnte sein "Nein" etwas nachdrücklicher ausgedrückt werden. So etwas wie "Nein, nein! OMG NEIN! "

Warum nicht minimierte oder komprimierte Assets in einem Quellcodeverwaltungssystem wie Git speichern?

  1. Sie können durch Ihren Build-Prozess im laufenden Betrieb aus dem Quellcode fast trivial neu generiert werden. Beim Speichern komprimierter Assets wird im Grunde derselbe logische Inhalt zweimal gespeichert. Es verstößt gegen das Prinzip "Wiederhole dich nicht" (auch bekannt als DRY ).

  2. Ein weniger philosophischer, aber praktischerer Grund ist, dass minimierte / optimierte Assets beim Speichern in Git eine sehr schlechte Komprimierbarkeit aufweisen. Versionsverwaltungssysteme erkennen die Änderungen ("Deltas") zwischen verschiedenen Versionen jeder gespeicherten Datei. Dazu "unterscheiden" sie die neueste Datei von der vorherigen Version und verwenden diese Deltas, um zu vermeiden, dass eine vollständige Kopie jeder Version der Datei gespeichert wird. Die im Schritt Minimieren / Optimieren vorgenommenen Transformationen entfernen jedoch häufig die Ähnlichkeiten und Wegpunkte, die die Diff / Delta-Algorithmen verwenden. Das trivialste Beispiel ist das Entfernen von Zeilenumbrüchen und anderen Leerzeichen. Der resultierende Vermögenswert ist oft nur eine lange Schlange. Viele Teile des Web-Build-Prozesses - Tools wie Babel , UglifyJS , Browserify ,Less und Sass / SCSS - transformieren Assets aggressiv. Ihre Ausgabe ist störend; Kleine Eingangsänderungen können zu großen Änderungen der Ausgabe führen. Infolgedessen glaubt der Diff-Algorithmus oft, dass er jedes Mal fast eine völlig andere Datei sieht. Ihre Repositories wachsen dadurch schneller. Ihre Festplatten sind möglicherweise groß genug und Ihre Netzwerke schnell genug, was kein großes Problem darstellt, insbesondere wenn die zweimalige Speicherung der minimierten / optimierten Assets einen Wert hat. Basierend auf Punkt 1 sind die zusätzlichen Kopien möglicherweise nur zu 100% sinnlos aufblähen.

Es gibt jedoch eine große Ausnahme: DevOps / Cloud-Bereitstellungen. Eine Reihe von Cloud-Anbietern und DevOps-Teams verwenden Git und ähnliches nicht nur, um Entwicklungsupdates zu verfolgen, sondern auch, um ihre Anwendungen und Assets aktiv auf Test- und Produktionsservern bereitzustellen. In dieser Rolle kann Git effizient feststellen, "welche Dateien geändert wurden?" ist ebenso wichtig wie seine detailliertere Fähigkeit zu bestimmen, "was sich in jeder Datei geändert hat?" Wenn Git eine fast vollständige Dateikopie für minimierte / optimierte Assets erstellen muss, dauert dies etwas länger als sonst, aber keine große Sache, da es immer noch hervorragende Arbeit leistet, um eine Kopie von "jeder Datei im Projekt" auf jeder zu vermeiden Bereitstellungszyklus.

Wenn Sie Git als Deployment-Engine verwenden, kann das Speichern minimierter / optimierter Assets in Git von "Nein!" zu wünschenswert. In der Tat kann dies erforderlich sein, beispielsweise wenn Sie auf den Servern / Diensten, auf denen Sie bereitstellen, keine soliden Build- / Nachbearbeitungsmöglichkeiten haben. (Das Segmentieren von Entwicklungs- und Bereitstellungsressourcen in diesem Fall ist eine separate Dose von Würmern. Derzeit reicht es aus zu wissen, dass sie auf verschiedene Arten verwaltet werden können, einschließlich mit einem einzigen einheitlichen Repository, mehreren Zweigen, Unterrepositorys oder sogar mehreren überlappenden Repositorys. )

Jonathan Eunice
quelle
1
Danke dafür! Sehr geschätzt. Ich habe dies stattdessen als Antwort markiert, da es viel besser erklärt zu sein scheint.
Connor Gurney
1
Git speichert nicht nur Deltas. SVN tut dies, aber Git verwendet einen viel komplexeren Mechanismus zum Speichern von Dateien. Einige Leute sagen Ihnen, dass es eine vollständige Kopie jeder Datei speichert, aber soweit ich weiß, ist dies auch falsch. Ich werde nicht versuchen, mich auf das einzulassen, was es tut, da ich selbst nicht ganz klar bin.
jpmc26
Ich denke, Sie könnten die Nuance erreichen, indem Sie einfach "und nur die neuen Deltas speichern" in etwas nach dem Vorbild von "und diese Deltas verwenden, um zu vermeiden, dass eine vollständige Kopie jeder Version der Datei gespeichert wird." Das würde Ihren Standpunkt klarstellen, sachlich korrekt sein und vermeiden, sich mit der Frage zu befassen, wie es für ein bestimmtes Versionsverwaltungssystem gemacht wird.
jpmc26
Könnte DevOps nur Git-Hooks verwenden, um automatisch eine Minifizierung auf dem bereitgestellten Server auszulösen und das Beste aus beiden Welten zu erhalten?
Buttle Butkus
@ButtleButkus Hängt vom bereitgestellten Server ab. Um von Post-Hooks abhängig zu sein, müssen Sie entweder 1 / davon ausgehen, dass die entsprechenden Transpiler, Minifier und Optimierer auf dem Ziel vorhanden sind, oder 2 / sie laden, bevor Sie die Post-Hooks ausführen. 1 / ist heikel. 2 / legt bei jeder Bereitstellung Ladekosten / Latenz fest. Außerdem werden neue mögliche Fehlermodi und die Anforderung eingeführt, Post-Hooks in einer entfernten, undurchsichtigen, vorübergehenden Umgebung zu debuggen. Nicht ideal. Haken sind also keine Silberkugel. Das Vorkonvertieren / Optimieren von Assets ist zwar unelegant, aber robust und pragmatisch.
Jonathan Eunice
17

Nein.

Die Quellcodeverwaltung sollte nur die Quelle enthalten. Wenn es aus dem Quellcode generiert wird, gehört es nicht dorthin - und sollte von Ihrem Erstellungsprozess generiert werden.

Der grundlegende Grund, warum Sie keine Artefakte für die Zwischensteuerung erstellen möchten, besteht darin, dass es in diesem Fall sehr schwierig wird, zu vertrauen, ob das, was Sie ausführen, von der Quelle stammt, die Sie gerade geändert haben, oder von einem Zwischenprodukt, das Sie nicht neu erstellt haben .

ptyx
quelle
3
Stellen Sie sich generierten Code so vor, wie Sie sich ausführbaren Code vorstellen.
candied_orange
3
Dieses Prinzip ist nicht immer wahr. Wenn Sie Dateien haben, die mit schwergewichtigen Tools generiert wurden, die ein Benutzer nicht erwarten kann, ist es möglicherweise sinnvoll, die generierten Dateien in git zu speichern. Viele Leute haben configureaus diesem Grund sogar generierte Autoconf- Skripte in Git eingefügt.
R .. GitHub STOP HELPING ICE
@R ..: Idealerweise unterhalten Sie ein separates Artefakt-Repository für diese Dinge, aber die Realität ist selten ideal.
Kevin
@R können Sie Kompromisse eingehen - aber es ist nur das. Und im Fall der CSS-Minimierung sind die Tools meiner Meinung nach nicht als "schwergewichtig" oder "langsam" oder "unpraktisch" zu qualifizieren. Es gibt auch alternative Abhängigkeitsinjektionsmechanismen (Maven, Ivy ...), die gut funktionieren und nicht erfordern, dass Sie generierten Code in Ihre Quellcodeverwaltung einfügen.
Ptyx
1
@ ButtleButkus Ich habe nicht viel Fachwissen über den Devops-Fall. Was ich gesehen habe, ist Git, das als (sehr praktischer und flexibler) Transport- / Freigabe- / Bereitstellungsmechanismus verwendet wird und nicht nur als Quellcodeverwaltung. Sofern das 'Quell'-Git und das' Delivery'-Git nicht getrennt sind (separate Repos oder separate Zweige), bedeutet dies, dass Sie die Quell-> Build-> Lieferkette etwas gefährden müssen - z. B. wird die Produktion Quellcode haben und zusätzliche herumliegende Zweige und Entwicklung mit nicht verwendeten binären Produkten. Es ist ein pragmatischer Kompromiss, aber ich ziehe es vor, Bedenken zu trennen, wenn ich kann.
Ptyx