Kontrola wersji strony: pliki front-end deweloperskie / produkcyjne

Próbuję wymyślić lepszy sposób kontroli wersji naszych projektów witryn. Pamiętaj, że jestem tylko programistą front-end, więc nie mam głębokiej wiedzy o VCS.

Przepływy pracy zmieniają się, a nawyki kontroli wersji w przeszłości stają się przestarzałe. Główny problem polega na tym, że dla każdej witryny istnieją 2 tablice plików frontonu.

Środowisko deweloperskie (mniej plików, nieskompresowane pliki J, obrazy itp.). Środowisko kompilacji „gulpified” (wszystko skompresowane i nieczytelne dla ludzi).

Ale nie możesz sprzedawać witryny z plikami źródłowymi. Cóż, to nie jest w porządku.

Istnieje rozwiązanie polegające na posiadaniu 2 repozytoriów: jednej kompilacji, jednego programisty, z gulp wysyłającym pliki programistów do katalogu kompilacji. Ale jest to trudność do utrzymania, w małych firmach nie sądzę, że jest tak wspaniale. Tworzy wiele repozytoriów, a ludzie muszą radzić sobie z kilkoma repozytoriami, czasem nawet z jednym repozytorium svn, pojawiają się problemy.

Istnieje również rozwiązanie polegające na posiadaniu 1 repozytorium: plików źródłowych i plików prod w tej samej svn. Ale wtedy konieczne jest usunięcie plików źródłowych, gdy strona przechodzi z lokalnego serwera deweloperskiego na serwer produkcyjny (więc w jednym repozytorium znajdują się różne pliki, w zależności od lokalizacji, dewelopera lub produkcji ...). Z tego, co słyszałem, nie jest dobrze

Jaki jest prawidłowy sposób zarządzania przepływem pracy front-end w systemie kontroli wersji?

Jedną podstawową zasadą kontroli źródła jest to, że do repozytorium trzeba jedynie wkładać ręcznie pisane artefakty (oryginalne pliki źródłowe), nie trzeba tam przechowywać wszystkiego, co można „skompilować” lub „wygenerować”, ponieważ spowoduje to nadmiarowość . Jeden może (opcjonalnie) przechowywania wyjścia pośredniej / części procesu budowy na repo (czasami zwane również artefaktów), w którym etapy odtworzyć nich nie są w pełni zautomatyzowane, lub do celów buforowania przy etapy budowania odtworzyć wyjście jest powolny .

Więc jeśli masz w pełni zautomatyzowany proces generowania plików produkcyjnych z plików źródłowych deweloperów, wystarczy tylko poddać pliki deweloperskie kontroli źródła (wraz ze skryptami do tworzenia plików produkcyjnych). Jeśli nie, ustal taki proces. Upewnij się, że nikt nie musi ręcznie manipulować plikami produkcyjnymi po ich wygenerowaniu ze źródła. Jeśli chcesz wdrożyć „bezpośrednio” z VCS, upewnij się, że masz skrypt wdrażania, który wyciąga pliki źródłowe deweloperów spod kontroli źródła, wykonuje „gulpification” i przenosi powstałe pliki do produkcji w jednym kroku.

Oczywiście, jeśli chcesz używać kontroli źródła jako „słabej kopii zapasowej” lub pamięci podręcznej dla plików produkcyjnych, możesz w tym celu skonfigurować drugie repozytorium i umieścić kopię struktury pliku produkcyjnego po wygenerowaniu. To repozytorium nie będzie służyło do opracowywania, a po jego skonfigurowaniu nie trzeba ręcznie go obsługiwać. Upewnij się więc, że nie będziesz musiał podejmować żadnych ręcznych kroków w celu wykonania kopii zapasowych w tym „prod repo” - dołącz niezbędne kroki do skryptu wdrażania, który automatycznie tworzy kopię zapasową. Pomyśl o dodaniu osobnego skryptu kopii zapasowej, jeśli nie możesz zabronić ręcznych zmian w produkcji po wdrożeniu. W ten sposób możesz utrzymać proces, który można utrzymać, nawet jeśli masz ograniczone zasoby.

I tak, powinno to być ściśle oddzielone drugie repozytorium, ponieważ ma ono zupełnie inny cel i inny cykl życia niż repo deweloperów. Używasz go tylko do tworzenia kopii zapasowych, a nie do kontroli źródła, co jest innym procesem.