Jak przenieść pliki do produkcji?

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?

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).

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.

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.