Magento2 - wdrożenie lokalne / inscenizacja / produkcja i gitignore

To może być jeden rodzaj dyskusji więcej niż pytanie.

Chciałbym wiedzieć, jakie polityka rozmieszczenie postępować zgodnie z Magento2 & lokalnych > inscenizacji > produkcyjnych środowiskach

Po kilku próbach zdecydowaliśmy, że najlepszym (lub przynajmniej najbardziej solidnym) podejściem będzie ten plik gitignore, w tym folder dostawcy w git.

.DS_Store
/.buildpath
/.cache
/.metadata
/.project
/.settings
atlassian*
/nbproject
/sitemap
/sitemap.xml
/.idea
/.gitattributes
/app/config_sandbox
/app/etc/config.php
/app/etc/env.php
/app/code/Magento/TestModule*
/lib/internal/flex/uploader/.actionScriptProperties
/lib/internal/flex/uploader/.flexProperties
/lib/internal/flex/uploader/.project
/lib/internal/flex/uploader/.settings
/lib/internal/flex/varien/.actionScriptProperties
/lib/internal/flex/varien/.flexLibProperties
/lib/internal/flex/varien/.project
/lib/internal/flex/varien/.settings
/node_modules
/.grunt
/pestle.phar
/pub/media/*.*
!/pub/media/.htaccess
/pub/media/catalog/*
!/pub/media/catalog/.htaccess
/pub/media/customer/*
!/pub/media/customer/.htaccess
/pub/media/downloadable/*
!/pub/media/downloadable/.htaccess
/pub/media/import/*
!/pub/media/import/.htaccess
/pub/media/theme/*
/pub/media/theme_customization/*
!/pub/media/theme_customization/.htaccess
/pub/media/wysiwyg/*
!/pub/media/wysiwyg/.htaccess
/pub/media/tmp/*
!/pub/media/tmp/.htaccess
/pub/media/captcha/*
/pub/static/***
!/pub/static/.htaccess

/var/*
!/var/.htaccess

.unison*
/sync.sh

Dlatego uruchamiamy kompozytora tylko w środowisku lokalnym: jak każde nowe rozszerzenie lub aktualizacja oprogramowania jest testowana w lokalnym, a następnie sprawdzana i zatwierdzana. Prawdopodobnie wtedy też umieścilibyśmy plik app / etc / config.php w git, ale ten plik jest ponownie zapisywany podczas działania setup:upgrade, prawda?

Dołączenie dostawcy oznacza, że ​​rozmiar repozytorium będzie większy niż (być może) zalecany, ale w ten sposób podczas wdrażania kodu uruchamiamy sekwencję:

bin/magento setup:upgrade
bin/magento setup:di:compile (optional)
bin/magento setup:static-content:deploy

Powiązane informacje: http://www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

Zobacz, dlaczego wybieramy polecenie kompilacji jako opcjonalne Magento 2 - setup: di: compile ?

AKTUALIZACJA

Prawda jest taka, że ​​mamy problemy z wdrażaniem zmian kodu w naszych opublikowanych projektach Magento 2

Zmiany działają w trybie lokalnym i testowym (sprawdzane w obu trybach: programista i produkcja ... chociaż koncepcyjnie konfigurujemy te środowiska w trybie programisty), ale niektóre z nich nie działają w środowisku produkcyjnym (w trybie produkcyjnym) itp. więc nie jestem pewien, czy stosujemy właściwą strategię. Chciałbym zobaczyć, jaka jest odpowiednia sekwencja poleceń i znaczenie kolejności w tych poleceniach

W rzeczywistości każdego dnia jestem mniej przekonany o użyteczności trybu produkcyjnego Magento 2, chyba że nie zamierzasz niczego zmieniać w projekcie. Czy możesz zmienić zdanie?

W rzeczywistości każdego dnia jestem mniej przekonany o użyteczności trybu produkcyjnego Magento 2, chyba że nie zamierzasz niczego zmieniać w projekcie. Czy możesz zmienić zdanie?

Nie jestem pewien, czy rozumiem, czy masz rację, ale właśnie do tego służy tryb produkcyjny : systemy produkcyjne, w których niczego nie zmieniasz (pod względem kodu). To znaczy do następnego wdrożenia.

Uważam, że wdrożenie oparte na Git jest mniej odpowiednie dla Magento 2 niż dla Magento 1, z powodu całego procesu wstępnego przetwarzania. Kompilacja i wdrożenie jest bardziej złożone, a IMHO nie ma możliwości obejścia procesu automatycznej kompilacji

Co poleciłbym:

• Mają powtarzalne wdrożeń, czyli powinien mieć pewność, że dokładnie ten sam kod kończy się w produkcji, która była w inscenizacji, w tym generowanych plików .

• Aby to osiągnąć, oddziel kompilację od wdrożenia i wykonaj następujące czynności w procesie kompilacji:

  • composer install( vendormożliwe jest także dodawanie do repozytorium, ale jeśli to zrobiono, aby uniknąć uruchamiania kompozytora na serwerze podczas wdrażania, raczej zrób to w kroku kompilacji i zachowaj tylko composer.lockw repozytorium)

  • Generowanie kodu (YMMV):

    bin/magento setup:di:compile
    bin/magento setup:static-content:deploy

  • utworzyć archiwum (The build artefakt ) z pełnego katalogu Magento, wyłączając mediai var, ale w tym vendor, pub, var/generatedi var/di. Począwszy od Magento-2.2 , var/generatedi var/disą przenoszone do generated/codei generated/metadata, co sprawia, że łatwiej jest oddzielić je od reszty var, które powinny być ignorowane dla wdrożeń.

• We wdrożeniu skopiuj artefakt kompilacji na serwer docelowy, rozpakuj go do nowego katalogu i:

  • odwołują się do niego trwałe katalogów ( media, var/session, var/log, ...)
  • włącz tryb konserwacji
  • zmień katalog główny dokumentu (zwykle docroot jest dowiązaniem symbolicznym do ostatniej wersji, zmień go na nową wersję)
  • opróżnij pamięć podręczną
  • biegać setup:upgrade
  • wyłącz tryb konserwacji

• Ten proces wdrażania można łatwo wdrożyć za pomocą Deployer , który jest podobny do Capistrano, ale w PHP. Pełne rozwiązanie do wdrażania Magento 2 oparte na wdrażającym można znaleźć tutaj: https://github.com/mwr/magedeploy2 (dzięki netz98!), A oto inne, którego używamy: https://github.com/staempfli / magento2 -loyment-tool

• Przechowywanie app/etc/config.phpw repozytorium dobrze jest śledzić włączone i wyłączone moduły.

Nie jest to instrukcja krok po kroku, ale powinna dać ci przegląd bardziej niezawodnej alternatywy dla twojego obecnego procesu. Spójrz na połączone narzędzia, aby zobaczyć, jak może wyglądać pełne rozwiązanie.

Moim zdaniem poczekaj Magento 2.2 lub spróbuj zastosować podobne podejście.

Magento 2.2 wprowadza wdrażanie potokowe , na przykład oddzielając serwer kompilacji od serwera produkcyjnego.

Oto oficjalna dokumentacja: http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

Ponadto obecnie używam Ansible do zarządzania automatycznym wdrażaniem za pomocą szablonów konfiguracji i konfiguracji wielu środowisk.