Czy zminimalizowany CSS powinien być przechowywany w Git?

10

Korzystam z Gulp do generowania zminimalizowanego CSS z mojego kodu SASS dla projektu, nad którym pracuję.

Zastanawiałem się, czy uważa się za najlepszą praktykę zregenerowanie tego zminimalizowanego CSS, gdy wypychasz live z Git ...

lub

Czy przechowywać zminimalizowane pliki CSS w Git, aby były one automatycznie przesyłane na żywo do produkcji bez dalszej pracy ze strony serwera?

Doceniam ludzkie pomysły na ten temat. Dzięki!

Connor Gurney
źródło
Jest tylko jedno ograniczone miejsce css / js / etc. powinny być przechowywane: /dev/null.
R .. GitHub ZATRZYMAJ LÓD
(To dlatego, że twój serwer jest w pełni zdolny do korzystania z transportu gzip.)
R .. GitHub ZATRZYMAJ POMOC ICE
Przechowywanie zarówno skompresowanego, jak i nieskompresowanego CSS oznacza, że ​​masz teraz dwie wersje tego samego. Która jest wersją kanoniczną? Łatwo jest wyobrazić sobie scenariusz, w którym jeden programista aktualizuje skompresowany CSS, a inny aktualizuje nieskompresowany CSS. Twoje dwa aktywa się rozeszły. Oczywiście proces powinien temu zapobiec, ale jest to realistyczna perspektywa, na przykład z nowym deweloperem w zespole.
Qwerky,

Odpowiedzi:

13

"To zależy." Do normalnego śledzenia rozwoju, nie. W przypadku wdrożeń chmurowych i DevOps jest to jednak często wygodne, a nawet wymagane.

Przez większość czasu @ptyx jest poprawny . Rzeczywiście, jego „nie” można powiedzieć nieco bardziej zdecydowanie. Coś w stylu „Nie. Nie! OMG NIE!

Dlaczego nie przechowywać zminimalizowanych lub skompresowanych zasobów w systemie kontroli źródła, takim jak Git?

  1. Można je niemal w prosty sposób zregenerować w procesie kompilacji w locie z kodu źródłowego. Przechowywanie skompresowanych zasobów polega zasadniczo na dwukrotnym przechowywaniu tej samej logicznej zawartości. Narusza to zasadę „nie powtarzaj się” (inaczej DRY ).

  2. Mniej filozoficznym, ale bardziej praktycznym powodem jest to, że zminimalizowane / zoptymalizowane zasoby mają bardzo słabą ściśliwość, gdy są przechowywane w Git. Systemy kontroli źródła działają poprzez rozpoznawanie zmian („delt”) między różnymi wersjami każdego przechowywanego pliku. Aby to zrobić, „różnicują” najnowszy plik z poprzednią wersją i używają tych delt, aby uniknąć przechowywania pełnej kopii każdej wersji pliku. Ale transformacje dokonane w kroku minimalizacji / optymalizacji często usuwają podobieństwa i punkty trasy wykorzystywane przez algorytmy różnicowe / różnicowe . Najbardziej trywialnym przykładem jest usuwanie podziałów linii i innych białych znaków; wynikowy zasób to często tylko jedna długa linia. Wiele części procesu budowania sieci - narzędzia takie jak Babel , UglifyJS , Browserify ,Mniej , a Sass / SCSS - agresywnie przekształcają aktywa. Ich produkcja jest zaburzona; niewielkie zmiany danych wejściowych mogą prowadzić do poważnych zmian produkcji. W rezultacie algorytm różnicowy często wierzy, że za każdym razem widzi prawie zupełnie inny plik. W rezultacie Twoje repozytoria będą rosły szybciej. Twoje dyski mogą być wystarczająco duże, a sieci wystarczająco szybkie, co nie stanowi poważnego problemu, szczególnie jeśli wartość podwójnego przechowywania zminimalizowanych / zoptymalizowanych zasobów była warta - chociaż w oparciu o punkt 1, dodatkowe kopie mogą być w 100% bezcelowe nadąć.

Istnieje jednak poważny wyjątek: wdrożenia DevOps / w chmurze. Wielu dostawców chmury i zespoły DevOps używają Git i podobnych nie tylko do śledzenia aktualizacji programistycznych, ale także do aktywnego wdrażania swoich aplikacji i zasobów na serwerach testowych i produkcyjnych. W tej roli zdolność Gita do skutecznego określania „jakie pliki się zmieniły?” jest równie ważne, jak jego bardziej szczegółowa zdolność do określania „co zmieniło się w każdym pliku?” Jeśli Git musi wykonać prawie pełną kopię pliku dla zminimalizowanych / zoptymalizowanych zasobów, zajmuje to trochę dłużej niż w innym przypadku, ale to nic wielkiego, ponieważ nadal wykonuje doskonałą pracę, pomagając uniknąć kopii „każdego pliku w projekcie” na każdym cykl wdrażania.

Jeśli używasz Git jako mechanizmu wdrażania, przechowywanie zminimalizowanych / zoptymalizowanych zasobów w Git może zmienić się z „nie!” pożądane. Rzeczywiście może to być wymagane, powiedzmy, jeśli brakuje solidnych możliwości kompilacji / przetwarzania końcowego na serwerach / usługach, na których wdrażasz. (Jak podzielić segmenty zasobów programistycznych i wdrożeniowych w tym przypadku, jest osobną puszką robaków. Na razie wystarczy wiedzieć, że można nimi zarządzać na kilka sposobów, w tym za pomocą jednego zunifikowanego repozytorium, wielu gałęzi, podrepozytorów, a nawet wielu nakładających się repozytoriów. )

Jonathan Eunice
źródło
1
Dziękuję Ci za to! Bardzo mile widziane. Zaznaczyłem to jako odpowiedź, ponieważ wydaje się, że jest znacznie lepiej wyjaśnione.
Connor Gurney,
1
git nie przechowuje tylko delt. SVN tak, ale git używa znacznie bardziej złożonego mechanizmu do przechowywania plików. Niektórzy twierdzą, że przechowuje pełną kopię każdego pliku, ale z tego, co rozumiem, jest to również niepoprawne. Nie będę próbował wdawać się w to, co robi, ponieważ sam nie jestem do końca tego pewien.
jpmc26,
Myślę, że niuans można osiągnąć, zmieniając „i przechowując tylko nowe delty„ do czegoś podobnego do ”i używaj tych delt, aby uniknąć przechowywania pełnej kopii każdej wersji pliku”. To by sprawiło, że miałeś rację, byłby poprawny pod względem faktycznym i nie zagłębiał się w kwestię tego, jak to jest zrobione dla dowolnego systemu kontroli źródła.
jpmc26,
Czy DevOps może po prostu użyć haczyków git, aby automatycznie uruchomić minimalizację na wdrożonym serwerze, uzyskując to, co najlepsze z obu światów?
Buttle Butkus,
@ButtleButkus Zależy od wdrożonego serwera. Aby polegać na zaczepach słupkowych, musisz 1 / założyć, że odpowiednie transpilatory, minizatory i optymalizatory są obecne na celu, lub 2 / załadować je przed uruchomieniem zaczepów słupkowych. 1 / jest dicey. 2 / nakłada koszt obciążenia / opóźnienie przy każdym wdrożeniu. Wprowadza także nowe możliwe tryby awarii oraz wymóg debugowania słupków w zdalnym, nieprzezroczystym, przejściowym środowisku. Nieidealny. Więc haki nie są srebrną kulą. Wstępna konwersja / optymalizacja zasobów może być nieelegancka, ale jest solidna i pragmatyczna.
Jonathan Eunice,
17

Nie.

Kontrola źródła powinna zawierać tylko źródło. Jeśli jest generowany ze źródła, nie należy do niego - i powinien zostać wygenerowany przez proces kompilacji.

Podstawowym powodem, dla którego nie chcesz kontrolować źródła artefaktów kompilacji pośredniej, jest to, że jeśli tak zrobisz, naprawdę trudno jest zaufać, czy to, co uruchamiasz, pochodzi z właśnie zmodyfikowanego źródła lub z produktu pośredniego, którego nie udało się odbudować .

ptyx
źródło
3
Pomyśl o wygenerowanym kodzie tak, jak myślisz o kodzie wykonywalnym.
candied_orange 30.08.16
3
Ta zasada nie zawsze jest prawdziwa. Jeśli masz pliki generowane za pomocą ciężkich narzędzi, których nie możesz oczekiwać od użytkownika, warto umieścić wygenerowane pliki w git. Z configuretego powodu wiele osób umieściło w git wygenerowane skrypty autoconf .
R .. GitHub ZATRZYMAJ LÓD
@R ..: Idealnie, masz osobne repozytorium artefaktów dla tych rzeczy, ale rzeczywistość rzadko jest idealna.
Kevin
@R możesz iść na kompromis - ale to po prostu to. W przypadku minimalizacji CSS nie sądzę, aby narzędzia kwalifikowały się jako „ciężkie”, „wolne” lub „niewygodne”. Istnieją również alternatywne mechanizmy wstrzykiwania zależności (maven, bluszcz ...), które działają dobrze i nie wymagają od Ciebie generowania kodu w kontroli źródła.
ptyx
1
@ButtleButkus Nie mam dużego doświadczenia w sprawie devops. To, co widziałem, jest używane jako git (bardzo wygodny i elastyczny) mechanizm transportu / wydania / wdrażania, a nie wyłącznie jako kontrola źródła. O ile git „źródłowy” i git „dostarczający” nie są oddzielne (oddzielne repozytorium lub oddzielne gałęzie), oznacza to, że musisz nieco narazić łańcuch źródłowy-> kompilacja-> dostarczalny - np. Skończysz na produkcji z kodem źródłowym i dodatkowe gałęzie leżące wokół i rozwój z nieużywanymi produktami binarnymi. To pragmatyczny kompromis, ale wolę rozdzielać obawy, kiedy mogę.
ptyx