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 pull
z BitBucket wprowadzamy zmiany, a następnie hg push
do 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)?
źródło
Odpowiedzi:
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.
źródło
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ąć.
źródło
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.
źródło
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.
źródło
To świetny pomysł, należy jednak pamiętać o następujących kwestiach:
hg update -C
nie wpływa to na produkcję (tzn. Usuwaj ważne pliki)hg status
dane wyjściowe na serwerze (pomoże to upewnić się, że ignorujesz rzeczy jako pamięć podręczną)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 -C
na serwerze (oczywiście możesz to zrobićhg status
i pobrać pliki, których dotyczy problem, do późniejszej analizy).źródło