Rozmieszczanie projektu Symfony z Jenkins: Najlepsze praktyki

Question

Zarządzam kilkoma projektami Symfony 2/3 na moim serwerze Jenkins, które wdrażam na serwerze na żywo. To jest moja obecna konfiguracja:

Build

• kasa za pomocą wtyczki git
• bazy danych usuń, jeśli istnieje
• wykonującemu composer install (tryb prod, optymalizacji autoloader)
• wykonywania bower install sprowadzić mój asset
• wykonanie kompilacji gulp, która minimalizuje i łączy css/javascript (nie używamy aktywów)
• wykonywania mój tworzenie rzeczy bazie
• wykonującemu jednostkę testuje

Archiwizacja

Po kompilacji, archiwizować artefakty kompilacji bez vendor, node_modules i bower_components folderach jako zip plik za pomocą wtyczki "Compress Artifacts".

Wdrożenie

Używam „Promoted builds” wtyczki i „Publish over SSH” wtyczki w kombinacji: Jeśli chcę „iść na żywo” z kompilacji, opublikować artefakty (mój plik ZIP) przez SSH do mój system na żywo w katalogu o nazwie staging_dir. Po przesłaniu pliku, mogę wykonać kilka poleceń ssh:

• Ustaw system dożyć trybie konserwacji
• rozpakować artefakty zip w moim staging_dir
• wykonać composer install na żywo systemu (ta sama konfiguracja jak w czasie kompilacji)
• (bower install i kompilacja gulp nie jest konieczne, ponieważ używamy aktywa mamy utworzone podczas kompilacji)
• migrate database
• przenieść aktualnych plików systemu Live na backup folderze
• kopii na plikach z staging_dir
• ustawić system live do trybu „produkcja” (wyłączyć tryb konserwacji)

najlepsze praktyki?

Chciałbym teraz zebrać kilka najlepszych praktyk dla wdrażania:

• Wolisz przenieść folder vendor do systemu żywo zamiast wykonania composer install tam znowu?
• Co z aktywami? Czy ponownie tworzysz na żywo system lub korzystasz z opublikowanych zasobów?
• W jaki sposób obchodzić się z hasłami podczas wykonywania promocji na żywo?
• ... o innych rzeczach, o których zapomniałem.

Answer 1

Ja i kilku kolegów zajmujemy się tym od dłuższego czasu. Kiedy zaczynaliśmy, trudno było znaleźć dobre posty dotyczące tego tematu. Dlatego chciałbym podzielić się z nami tym, co według nas działa "najlepiej".

Szczegóły projektu

Jeden z naszych klientów ma duży i ciężki platformę używaną do zarządzania jego procesu biznesowego (coś jak ERP & CRM). Platforma została pierwotnie opracowana przy użyciu Symfony 2, a teraz mamy zaktualizowaną wersję Symfony 3. Aby mieć pewność, że wszystko działa poprawnie, projekt zawiera mnóstwo przypadków testowych. Używamy również:

1. Doctrine Migrations dzięki czemu mogliśmy bezpiecznie aktualizować bazę danych na serwerach produkcyjnych, gdy jest to konieczne.
2. Phing
3. Bower
4. Assetic
5. PHPUnit
6. Git
7. Jenkins

Testowanie

Gdy ktoś zobowiązuje się do naszego serwera git, hak pozwala Jenkins wiedzieć i kompilacja jest uruchamiana. Gdy zadanie zakończy się pomyślnie, ręcznie uruchomimy wdrożenie. Odbywa się to poprzez zalogowanie się na komputerze klienta i uruchomienie skryptu, który opracowaliśmy.

Wdrożenie

Użyliśmy podejść do tego tak samo jak ty - Prześlij archiwum Jenkins po zakończeniu pracy. To jednak okazało się dość problematyczne, ponieważ w niektórych przypadkach archiwum mogło zostać zerwane (tj. Z powodu problemów z połączeniem sieci między instancją Janiki a serwerem produkcyjnym). Również przesłanie pliku z naszego serwera na serwer klienta zajęło znacznie więcej czasu. Dlatego zdecydowaliśmy się użyć gita i pobrać z niego niezbędną wersję. Korzystanie z git okazało się bardziej niezawodne i zapewnia absolutną kopię projektu po stronie klienta. Również cofnięcia do poprzedniej wersji to tylko jedna git checkout dala :)

Ponieważ większość z nas już doświadczenie z ant i php zdecydowaliśmy się użyć Phing i utworzyć skrypt kompilacji i automatyzację większości zwykłych zadań. W skrypcie kompilacji dodaliśmy większość typowych zadań uruchamianych przez cały czas, takich jak instalowanie, aktualizowanie, czyszczenie pamięci podręcznej, instalowanie zasobów itd. Następnie udostępniliśmy ten skrypt na każdym serwerze produkcyjnym.

Gdy Jenkins budować zadaniem jest udany, a my ręcznie zwolniony & oznaczone wersję produktu, chcielibyśmy uruchomić phing update na komputerze klienta SSH (krok ten mógł zostać zautomatyzowane, ale był celowo nie należytej do niektórych wymagań projektu).Co to polecenie zrobi to:

1. Pobierz najnowszą wersję znakowany z naszego serwera git
2. Jeśli prąd wersja < najnowszy wersji oznaczonych (z hash 19a6d9) przechodzi do następnego etapu
3. phing maintenance:on (ustawia platformę w trybie offline)
4. git fetch origin 19a6d9
5. git checkout 19a6d9
6. phing composer:install
7. phing database:upgrade (która biegnie kilka poleceń, w tym tworzenie kopii zapasowych bazy danych i doctrine:migrations:migrate)
8. phing assets (biegnie bower install, assetic poleceń i kompiluje wszystkie js/css do one.css i one.js)
9. phing cache:clean
10. phing maintenance:off (włącza platformę)

Nasze zadanie phing update jest również otoczone przez trycatch, a w przypadku, gdy faza aktualizacji trafi w cegłę, automatycznie przejdzie do fazy przywracania. Odbywa się to poprzez phing rollback PREVIOUS_VERSION polecenia która robi:

1. git checkout PREVIOUS_VERSION - przywraca fs do poprzedniego git wersji
2. phing composer:install
3. phing database:rollback PREVIOUS_VERSION
4. phing assets
5. phing report (ta informuje wystąpił problem z aktualizację do naszego narzędzia do śledzenia problemów z załączonym plikiem dziennika)

Odpowiedzi na pytania

1. Wolisz przenieść folder z bower_components i vendor do systemu żywo zamiast wykonania bower install i composer install tam znowu?

   • pójdę z bower install i composer install, ponieważ po raz pierwszy będziesz już wszystko w pamięci podręcznej. Każde kolejne uruchomienie byłoby niemal natychmiastowe lub co najmniej znacznie szybsze niż ponowne przesyłanie wszystkich zasobów raz za razem za pośrednictwem ftp. To może zaoszczędzić ci nieco przepustowości i, co najważniejsze, czasu. Jeśli zdecydujesz się na podobną konfigurację do mojej, możesz chcieć uniknąć compiling js/css na instancji Jenkins, jak będziesz to robił na serwerze prod.

2. W jaki sposób obchodzić się z hasłami podczas wykonywania promocji na żywo?

   • Nie jesteś pewien, o co pytasz?

Wnioski

Konfiguracja zależy głównie od wymagań projektowych, zasoby masz dostępne (tj VPS, dzielonego hostingu, Git, ssh, etc) oraz proces uwalniania. Jak widać, nasze wdrożenie różni się nieco od tego, co robisz. To nie czyni go złym ani dobrym - to po prostu pasuje do naszych potrzeb. Jeśli to, co już masz, działa dla Ciebie i rozwiązuje wszystkie problemy - powinieneś trzymać się go i próbować zoptymalizować. W przypadku, gdy dopiero zaczynasz to, co powinno być najbardziej ostrożnym:

1. PEŁNE ... KOPIE ZAPASOWE! Posiadanie kopii zapasowej produkcyjnego systemu plików jest świetne, ale powinieneś także mieć kopię zapasową bazy danych. Podczas kursu rozwoju twojego projektu prawdopodobnie będziesz miał nowe funkcje, które zmieniają bazę danych. Niektóre z tych zmian mogą być niekompatybilne wstecz. Należy więc wykonać kopię zapasową wszystkiego lub może się zdarzyć, że utworzona zostanie kopia zapasowa fs bez bazy danych db, co uniemożliwi wycofanie.

2. Cofnij - utwórz skrypt, który wykonuje wszystkie niezbędne kroki, aby wycofać projekt do poprzedniej wersji. Jeśli jesteś pod dużą presją lub rzeczy są wrażliwe na czas, możesz niechcący popełnić błąd i zepsuć kopię zapasową lub coś innego ... Zrób skrypt, który zrobi to za ciebie.

3. Przetestuj proces wdrażania lokalnie lub na maszynie testowej, aby mieć pewność, że wszystko działa prawidłowo, zanim wykonasz ją na rzeczywistym serwerze produkcyjnym.

Mam nadzieję, że to pomoże Ci znaleźć najlepsze rozwiązanie dla Twojego procesu wdrażania uwolnienie &. Jeśli znajdziesz lepsze rozwiązanie, opublikuj to jako odpowiedź - na pewno będzie pomocne!