Jak przenieść pliki do produkcji?

9

Jesteśmy grupą, która rozpoczęła pracę nad dość dużą witryną z istniejącą bazą kodów. Mamy serwer testowy i produkcyjny.

Naszym pomysłem jest posiadanie repozytorium testowego z wieloma programistami mającymi dostęp push; i błogosławione repozytorium, do którego tylko nieliczni mogą pchać. Błogosławione repo ma być zawsze stabilne i reprezentować najnowszą wersję produkcyjną.

Jak mogę zautomatyzować proces przesyłania plików do produkcji? Czy źle jest mieć pliki produkcyjne pod kontrolą wersji? W ten sposób wypychanie do błogosławionego repozytorium oznaczałoby wdrożenie. Ale co się dzieje, gdy dochodzi do konfliktów scalania? Czy serwer produkcyjny przestanie działać, dopóki nie zostanie rozwiązany?

Tamás Szelei
źródło

Odpowiedzi:

7

Mówiąc prosto:
sam proces wypychania powinien być w pełni automatyczny. Niezależnie od tego, czy masz niestandardowy skrypt, czy po prostu wyciągasz „błogosławione” repozytorium do środowiska produkcyjnego. To zależy od Ciebie. Powinieneś po prostu mieć coś zautomatyzowanego, ponieważ zautomatyzowane procesy mogą być niezawodne (w przeciwieństwie do ręcznego przesyłania plików i tak dalej).

Proces wypychania powinien być jednak uruchamiany ręcznie. Przekazujesz swoje aktualizacje, a kiedy poczujesz się pewnie, oznaczasz go jako kandydata do wydania i przenosisz do środowiska testowego (idealnie byłoby możliwie jak najbardziej zbliżone do środowiska produkcyjnego). Po przetestowaniu RC można rozpocząć inicjowanie.
Na dzień dzisiejszy nic innego nie da ci tego, co mogą testować ludzie.

Brzmi to trochę wolno, w tym sensie, że pętla sprzężenia zwrotnego jest stosunkowo duża. Ale w celu prawidłowego przetestowania ważne jest, aby zrobić stałą migawkę, która jest następnie badana przez 24-48 godzin (lub może dłużej, w zależności od wielkości projektu). Przeciwnie jest scenariusz, w którym znajdziesz wiele błędów zaraz po wypchnięciu i próbujesz je załatać za pomocą szybkich poprawek, które wprowadzają nowe błędy.
Lepiej wydaj wydanie ze znanymi błędami (o dopuszczalnym poziomie ważności), niż z nieznanymi błędami (o nieznanym poziomie ważności).

back2dos
źródło
Czy posiadanie repozytorium na serwerze produkcyjnym jest w porządku? Kiedy mówiłem o automatyzacji, miałem na myśli to, że w przypadku braku repozytorium na serwerze produkcyjnym (innymi słowy, będą testy i błogosławione repo, ale nie produkcja ). Oczywiście testów na ludziach nie można zautomatyzować, nie o to mi chodzi.
Tamás Szelei
1
@ Tamás: Lokalne pobieranie błogosławionej repozytorium na twoim serwerze może być w porządku, jeśli to właśnie masz na myśli (apache (lub inny porządny serwer WWW) ułatwia, aby pliki powiązane z git były niedostępne z zewnątrz). Możesz jednak łatwo dokonać jego „eksportu” . Nie ma sensu mieć plików w twoim katalogu głównym, które tam nie należą.
back2dos
Err -... Więc skąd miałbyś wiedzieć, jakie dokładnie są nieznane błędy o nieznanej sile, jeśli są ... nieznane ?
Spoike,
@Spoike Myślę, że back2dos po prostu zaleca dokładne testowanie, używając poprawionych wydań, które nie mają poprawek „szybkie i brudne”, które nie zostały przetestowane.
Max
@Spoike: W ciągu 24-48 godzin możesz przekształcić wiele nieznanych błędów w znane błędy. Również w 5 minut możesz zmienić znany błąd w wiele nieznanych błędów. Nazywa się to szybką poprawką.
back2dos
2

Nauczyłem się wiele o wdrażaniu, patrząc na działanie Capistrano. W tym czasie pracowałem z RoR, więc był to logiczny wybór i chociaż nigdy nie udało mi się zachowywać w przypadku projektu, nad którym pracowałem, sposób, w jaki wykonuje automatyczne aktualizacje, był bardzo przydatny.

Możesz znajdować się w sytuacji, w której możesz używać go nawet bezpośrednio - niekoniecznie jest to związane z Railsami - ale jeśli nie, to sposób, w jaki się zachowuje, jest z pewnością pomocny.

glenatron
źródło
1

W zależności od używanej platformy istnieje wiele narzędzi, które mogą być przydatne do automatyzacji wydań produkcyjnych. Pracuję w sklepie .NET, więc używamy NAnt (chociaż MSBuild jest obecnie lepszą opcją). Java ma Anta i prawdopodobnie inne rzeczy. Ruby ma takie rzeczy jak Rake. Są też platformy ciągłej integracji, takie jak TeamCity i Hudson, które mogą być również używane do zarządzania wydaniami.

Nigdy nie widziałem ani nie słyszałem o posiadaniu kodu prod bezpośrednio w osobnym repozytorium kontroli źródła, ale to z pewnością może działać. Jak powiedział back2dos, kluczem jest automatyzacja. Mamy skrypty budowania zaprojektowane do sprawdzania kontroli źródła, kompilacji i wypychania do środowiska testowego. Następnie, gdy podoba nam się sposób działania inscenizacji, skrypty są kopiowane z QA do Prod.

Moje zalecenie to przejrzenie dostępnych narzędzi i wybranie jednego z nich, a następnie zaprojektowanie procesu, który będzie działał dobrze z wybranym narzędziem. Nie próbuj zbyt często wymyślać koła - to bardzo rozwiązany problem.

RationalGeek
źródło