Ciągłe wdrażanie za pomocą gitignore


12

W jaki sposób radzisz sobie z ignorowanymi plikami w gitignore podczas ciągłego wdrażania w Git? Pliki te są ignorowane ze względu na prywatność (tj. Nie chcą, aby były wypychane do innych zdalnych repozytoriów, takich jak GitHub), ale przy ignorowaniu tych plików nie są wypychane do repozytorium ciągłego wdrażania, aplikacja nie uruchomiłaby się (ponieważ pliki ignorowane są wymagane do poprawnego działania oprogramowania).

Jak zwykle ludzie się tym zajmują? W takim przypadku, czy Git nie jest najlepszym kandydatem do ciągłego wdrażania z powodu ignorowanych plików?


2
Głosuję za zamknięciem tego pytania jako nie na temat, ponieważ nie pokazuje minimalnego podstawowego wysiłku badawczego.
Scant Roger

3
Nie widzę braku wysiłku badawczego. OP wydaje się rozumieć, co gitignore robi doskonale. To, co widzę, to problem XY, ale ponieważ zarówno X, jak i Y zostały wyjaśnione w pytaniu, Doc był w stanie napisać przyzwoitą odpowiedź, która, mam nadzieję, rozwiąże prawdziwy problem OP.
Ixrec

1
@ScantRoger: szczerze mówiąc, pytanie można napisać lepiej, ale wcale nie jest tak złe, że zasługuje na ścisłe głosowanie.
Doc Brown,

Odpowiedzi:


14

Jeśli Twoje oprogramowanie nie działa bez tych plików, będziesz mieć problem z jakimkolwiek wdrożeniem, ręcznym, automatycznym lub ciągłym, z dowolnym rodzajem VCS, a nawet bez VCS. Więc zmień oprogramowanie tak, aby mogło faktycznie działać bez tych plików (na przykład może przyjąć jakieś „domyślne parametry”, jeśli brakuje plików), lub podaj wersję tego pliku odpowiednią do wdrożenia, która jest kopiowana ( jako część etapu wdrażania) w środowisku docelowym, na wypadek gdyby nie istniała „prywatna” wersja tych plików.

Jeśli mówimy o czymś takim plikiem zawierającym poświadczenia bazy danych do logowania do serwera, który ze względów bezpieczeństwa, nie chcesz być w kontroli wersji, a następnie trzeba będzie umieścić ten plik w środowisku wdrażania raz , prawdopodobnie ręcznie , przez osobę, która ma wystarczające prawa lub zna hasło. Jest to jednak celowe i nie powinno powstrzymywać Cię przed wdrażaniem codziennych nowych wersji oprogramowania. Tylko upewnij się, że pliki poświadczeń w miejscu nie są zastępowane podczas wdrażania nowej wersji.


Zgadzam się, jeśli wyewidencjonowanie z vcs nie wystarczy do zbudowania i uruchomienia, choć w zmniejszonej pojemności, to drzewo źródłowe jest niekompletne.
Newtopian

@Newtopian: pamiętaj, że może to być celowe i prawidłowe (patrz mój przykład).
Doc Brown

2

Inną opcją jest przechowywanie poufnych informacji w narzędziu do wdrażania. I konfiguracja narzędzia do wdrażania w oddzielnym prywatnym repozytorium źródłowym.

Pozostawienie wrażliwych danych na maszynie docelowej działa, ale może ulec gniciu - ktoś to zmieni, nie wykonując procedur, maszyna hamuje i nikt nie pamięta prawidłowych ustawień itp.

Na przykład Saltstack ma https://docs.saltstack.com/en/latest/topics/pillar/index.html

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.