Np powiedzmy, ze mamy spory plik excel i napisalismy program w Python do parsowania i generowania insertow co sa potrzebne, albo jakies mapowanie czegostam. I caly serwis to jest powiedzmy jakis mikroserwis w springboot korzystajacy posrednio z tych danych - ale nie ze skryptu, ktory jest pomocny tylko lokalnie dla developera.
Czy jest sens pushowac taki skrypt na "dev" branch i czy w takim wypadku jest sens pushowac go dalej na "qat"? Nie ma sensu zasmiecac wyzszych env typu PROD/UAT jak nie bedzie to tam wykorzystywane. Jak ktos automatycznie sprawdza roznice dev-qat, to taki plik moze przeszkadzac, bo sie bedzie platac, pokazywac roznice gdzie jej nie ma.
Z drugiej strony nie spushowac, to plik sie zgubi, albo strata czasu, szukac tego lokalnie.
Robic inne repo specjalnie, tez moze byc strata czasu i biurokracja. Mozna zrobic oddzielnego brancha, ale ktors moze zrobic purge przy migracji i usunac. To co w koncu robic z takimi skryptami?
- Rejestracja:ponad 6 lat
- Ostatnio:około 7 godzin
- Postów:442
Git 
- Rejestracja:około rok
- Ostatnio:4 miesiące
- Lokalizacja:Zug, Szwajcaria
- Postów:67
Companion repo brzmi sensownie 
- Rejestracja:około 6 lat
- Ostatnio:około 3 godziny
- Postów:659
Ciekawe pytanie, sam nie jestem przekonany, bo oba rozwiązania (to samo repo i inne repo) mają wady i zalety, ale chyba wolałbym, żeby cały kod powiązany z daną aplikacją był jednak w jednym repo. Tak, będzie trzeba pewnie formalnie przepchnąć "pustą" zmianę na wyższe branche/środowiska (bo zakładam że ten skrypt po prostu sobie leży w katalogu gdzieś, gdzie nie jest brany pod uwagę przy budowaniu), ale to jest (przynajmniej dla mnie) akceptowalny narzut.
EDIT: czyli w praktyce, masz projekt typu Maven, i po prostu robisz katalog /tools czy /utils czy cokolwiek, i wpieprzasz tam cały ten majdan. Jak ktoś przegląda PR to wie po nazwie folderu, że to nie jest używane na produkcji (przynajmniej w zamyśle). Tak samo jakieś dane przykładowe ale nieużywane w testach.
- Rejestracja:11 miesięcy
- Ostatnio:21 minut
- Postów:356
lambdadziara napisał(a):
Czy jest sens pushowac taki skrypt na "dev" branch i czy w takim wypadku jest sens pushowac go dalej na "qat"?
Ja bym się zastanowił czy w ogólności jest sens posiadania brancha per środowisko, bo z opisu rozumiem, że tak macie.
- Rejestracja:11 miesięcy
- Ostatnio:10 miesięcy
- Postów:7
lambdadziara napisał(a):
Nie ma sensu zasmiecac wyzszych env typu PROD/UAT jak nie bedzie to tam wykorzystywane.
W jaki sposób doszedłeś do tego że będzie to zaśmiecać PROD? O ile ten Spring mikro serwis nie wystawia wszystkich plików które są w repo do internetu to jest dobrze 
Ja preferuję mieć wszystko w jednym repo. Aczkolwiek wydaje mi się że pytasz o gusta, a więc to zależy.
- Rejestracja:około 6 lat
- Ostatnio:około 3 godziny
- Postów:659
W jaki sposób doszedłeś do tego że będzie to zaśmiecać PROD
Zwróciłeś mi na jedną rzecz uwagę - w przypadku chorych korpo, w których mamy drakońskie skany i statyczną analizę kodu -> zdecydowanie osobne repo. Tłumaczenie się, że w repo javowym masz skrypt w JS i tak naprawdę jest tylko odpalany lokalnie, a 1337 przestarzałych zależności to nie jest istotny problem do rozwiązania, to raczej strata czasu.
- Rejestracja:11 miesięcy
- Ostatnio:11 miesięcy
- Postów:5
Ma sens zaśmiecać to można traktować jako kopie zapasową za jakiś czas będziesz czegoś szukać to sobie pomyślisz, a na gicie to było i może przetrwało.
Git też nie zapisuje wszystkiego, a różnice, czyli w miarę jest optymalnie im więcej kopii tym lepiej kiedyś coś się spiepszy jakiś dysk czy coś i będziesz szukać jak problem rozwiązać, a na szczęście będzie kopia na githubie czy gdzieś.
main, buildem który buduje gotowy do deployu artefakt (najlepiej automatycznie z każdym pushem do maina) i później tylko robisz deploy zbudowanego wcześniej artefaktu na kolejne środowiska?