Czy dobrym pomysłem jest zainstalowanie Mercurial na serwerze i ściągnięcie hg w celu wdrożenia?


13

Właśnie rozpocząłem nową pracę w zeszłym miesiącu i wygląda na to, że NIE mają kontroli źródła kodu. Opierają się na kopiach zapasowych, które przyjmuje ich dostawca hostingu.

Po krótkiej rozmowie przekonałem mojego szefa, że ​​zdecydowanie powinniśmy korzystać z kontroli źródła, a po krótkim seminarium na ten temat cały zespół jest na pokładzie; kochali Mercurial.

W tej chwili działamy w ten sposób:

º----------BitBucket
º---------/
º--------/

Ja i trzej inni programiści hg pullz BitBucket wprowadzamy zmiany, a następnie hg pushdo BitBucket.

Teraz do wdrożenia ktoś musiałby przesłać najnowsze pliki FTP do serwera produkcyjnego.

Zastanawiałem się nad zainstalowaniem Mercurial na naszym serwerze i wykorzystaniem hg clone(później hg pull) aktualizacji wersji na produkcji.

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

Czy to dobry pomysł? Jakieś potencjalne pułapki, których mogę nie widzieć? Czy ktoś tutaj zrobił coś podobnego? Jak wdrażasz dużą aplikację frameworkową PHP (używamy Moodle)?


To świetny pomysł. Dlaczego masz wątpliwości?
Nikolay Fominyh

Jest to proces, który wielu robi i faktycznie uważa za „normalny” na tyle, że Microsoft ma teraz wbudowaną obsługę Git (z możliwą obsługą hg w przyszłości) wdrożeń opartych na usłudze Azure.
Alan Barber

Odpowiedzi:


12

Jest to z pewnością dobry pomysł i jest to powszechnie stosowana metoda wdrażania. Możesz użyć stabilnej gałęzi do celów wdrażania, zachowując jednocześnie pień do ciągłego rozwoju, aby przetestować stabilną gałąź przed wdrożeniem jej do produkcji.

Jedyny problem może pojawić się, gdy masz w bazie kodu wrażliwe informacje (takie jak klucze API itp.), Których nie chcesz przesyłać na serwery stron trzecich (w twoim przypadku byłby to Bitbucket). W takim przypadku prosty skrypt uruchamiany po wyciągnięciu danych z repozytorium w celu przywrócenia poufnych danych we właściwym miejscu rozwiąże ten problem.


10

Pamiętaj, że ta strategia wdrażania nie jest atomowa. Może się zdarzyć, że niektóre pliki są już aktualizowane, podczas gdy inne mogą nadal być w starym stanie podczas działania aplikacji. Może to powodować nieoczekiwane skutki uboczne.

Sposobem na wdrożenie atomowe jest np. Użycie dowiązań symbolicznych. Utwórz katalog zawierający nowe pliki. kiedy wszystko będzie gotowe, zmień dowiązanie symboliczne dla używanego katalogu. Jeśli zachowasz starą wersję, możesz również łatwo cofnąć.


3
W każdym razie możesz łatwo wycofać, o to właśnie chodzi w VCS.
Rob

1
niekoniecznie - musisz zachować konfigurację lub niektóre wygenerowane pliki, które mogą być zależne od wersji i systemu w VCS. Dodatkowo musisz użyć tagów (o których nie wspomniano w procesie opisanym w pytaniu), aby wrócić do znanej działającej wersji.
johannes

2

Inna (moim zdaniem lepsza) możliwość: użyj serwera kompilacji / serwera ciągłej integracji.

Krótkie krótkie wyjaśnienie: jest to serwer (może być wewnętrzny, nie musi być w Internecie) skonfigurowany do monitorowania repozytoriów, a ilekroć w repozytoriach pojawiają się nowe zestawy zmian, serwer tworzy kod ( AFAIK, nie jest to konieczne w PHP) , przeprowadza testy jednostkowe i wdraża kod na serwerze WWW.

Aby uzyskać więcej informacji, sprawdź te linki:

Istnieje wiele różnych produktów dla CI , ale jedynym, z którego dotychczas korzystałem, jest TeamCity . Bardzo łatwy do skonfigurowania ... w rzeczywistości jest to pierwszy, który wypróbowałem i tak mi się podobało, że się go trzymałem.


Alternatywne tanie rozwiązanie:

Jeśli konfiguracja serwera kompilacji jest zbyt pracochłonna lub chcesz mieć większą kontrolę nad tym, kiedy dokładnie twoja witryna jest wdrażana, po prostu skonfiguruj plik skryptu (Batch / Powershell w systemie Windows lub coś podobnego w systemie Linux / Mac), który pobiera najnowsza wersja z repozytorium i przesyłana przez FTP na serwerze produkcyjnym.

Zasadniczo jest taki sam jak serwer kompilacji, tylko prostszy.


Bez względu na to, jak dokładnie to rozwiązujesz, pamiętaj, aby jakoś zautomatyzować!

Chcesz móc wdrożyć za pomocą jednego kliknięcia / wpisując jedno polecenie, aby KAŻDY mógł to zrobić bez konieczności posiadania wiedzy o czymkolwiek specjalnym i bez popełniania błędów - nawet w przypadku katastrofy lub stresu.


1

Robimy to lub coś podobnego do tego. Nonatomic @ johannes wspomina o jednym zagadnieniu, choć w realnych warunkach dzieje się to tak szybko, że powinno być OK i są na to sposoby, jak wskazuje.

Prawdopodobnie ważniejsze od tego braku atomowości byłoby „jak zarządzać aktualizacjami schematu bazy danych” - wdrożenie złego kodu w ten sposób ułatwia naprawę. Dużym problemem jest wdrożenie aktualizacji, która zmienia bazę danych, którą chcesz przywrócić. Lub jeśli robisz złe aktualizacje i uszkadzasz dane.

Innym problemem, jaki mieliśmy z narzędziami DCVS (w przeciwieństwie do używania SVN) jest to, że masz teraz kopię całej bazy kodu na komputerze w miejscu, które potencjalnie może złapać atakujący. A także, że podstawa kodu DCVS może być dość duża, co może mieć znaczenie, jeśli płacisz za przechowywanie i / lub tworzenie kopii zapasowych. Z tych powodów nadal używamy SVN do ostatecznego wdrożenia.


1

To świetny pomysł, należy jednak pamiętać o następujących kwestiach:

  • Staraj się nie zatwierdzać na serwerze (chociaż w niektórych rzadkich przypadkach warto to zrobić, np. Instalując wtyczkę lub dodając zasoby treści)
  • Do testowania użyj serwera pomostowego lub wdrożenia repozytorium dodatkowego
  • Zawsze bądź ostrożny, hg update -Cnie wpływa to na produkcję (tzn. Usuwaj ważne pliki)
  • Posiadaj dział produkcyjny i programistyczny, wdrażaj tylko oddział produkcyjny
  • Traktuj zasoby jako kopie zapasowe (np. Obrazy zawartości) i ignoruj ​​dane użytkownika (np. Załączniki / przesłane pliki, pamięć podręczna itp.)
  • Zawsze miej czyste hg statusdane wyjściowe na serwerze (pomoże to upewnić się, że ignorujesz rzeczy jako pamięć podręczną)
  • Nie wdrażaj repozytorium w folderze internetowym. Używaj dowiązań symbolicznych spoza przestrzeni publicznej (np. Ln -s / myrepo / src / web / public_html / myapp)
  • Uważaj, aby nie zmieniać wersji plików konfiguracyjnych (szczególnie z hasłami do baz danych lub innymi)
  • Nie używaj zamiast produkcyjnej kopii zapasowej, jest to programistyczna kopia zapasowa kodu produkcyjnego , a nie danych produkcyjnych

Wreszcie, myślę, że najcenniejszą rzeczą dla dodania DVCS do procesu wdrażania jest to, że zwiększy to bezpieczeństwo twojego wdrożenia, czasami hakerzy wstrzykują złośliwy kod do twoich rzeczy i naprawdę nie masz możliwości łatwego wykrycia go bez kontroli wersji ( specjalnie rozpowszechniane, ponieważ aspekt dystrybuowany do VCS ułatwia sprawdzenie integralności plików).

Kilka razy włamano się do niektórych witryn, ponieważ Mercurial pomaga mi dosłownie cofnąć te włamania, po prostu wydając polecenie hg update -Cna serwerze (oczywiście możesz to zrobić hg statusi pobrać pliki, których dotyczy problem, do późniejszej analizy).

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.