GIT i strategia wdrażania Projekty Magento2

92

Z Magento 1 użyłem narzędzia do wdrażania, które pobrało repozytorium GIT, uruchomiłem polecenia podobne modman deploy-alli upewniłem się, że varkatalog jest zapisywalny. Do tego .gitignoreużyłem tego, który działał całkiem dobrze.

A co z Magento 2 ?

Co gitignore działa najlepiej, jak wdrożyć projekt i jakie polecenie należy uruchomić przed i po wdrożeniu. Czekamy na informacje od społeczności.

Pytanie pozostanie otwarte przez dłuższy czas

Sander Mangel
źródło
Dobre pytanie @sander Mangel
Amit Bera
1
Z definicji nie można udzielić kanonicznej odpowiedzi na to pytanie, więc jest on prawdopodobnie zbyt szeroki, a także źle dopasowany do charakteru pytań i odpowiedzi strony. Powinien być meta. Ale już to wiesz. To powiedziawszy, pozwolę na to, dopóki nagroda się nie skończy.
philwinkle
@ philwinkle może być szeroki, ale najwyraźniej niezbyt szeroki, ponieważ udzielono już 3 odpowiedzi. Jak omówiono tutaj: meta.magento.stackexchange.com/questions/745/… Meta ma być używana do pytań o MageSE, a nie do losowych postów / pytań. Jeśli chcesz go usunąć, nie mogę cię powstrzymać, ale wydaje się, że jest to dużo ludzie są zainteresowani pytaniem i moim zdaniem jest ono ważne, ale nie jest zbyt szczegółowe.
Sander Mangel
Dwie rzeczy: Po pierwsze, Sander ma rację co do Meta - powinno się jej używać tylko do pytań o platformę SE, ponieważ dotyczy ona Magento SE (Uwaga: być może Meta nie była wystarczająco dobrze nadzorowana, aby wzmocnić tę zasadę). Po drugie, „wiele osób [zainteresowanych]” pytaniem nie ma nic wspólnego z tym, czy na pytanie można odpowiedzieć kanonicznie, czy nie (a zatem z przydatnością pytania do formatu StackExchange). To na pewno frustrujące (sam sobie z tym poradziłem). Jestem skłonny zobaczyć, gdzie idzie ten wątek pytania / odpowiedzi. Być może A można stwierdzić na tyle dobrze, aby być wyłącznie „prawo” ...
benmarks
@benmarks w tym przypadku wybrałem niewłaściwy powód lub temat nagrody, moją motywacją było nagradzanie tego, kto poświęcił czas na napisanie pełnej odpowiedzi na to pytanie. Jeśli ten wątek nie jest tutaj, skopiuję go i opublikuję w Internecie, podając autorów, ponieważ uważam, że nadal ma wartość. Proszę mnie powiadomić, jeśli przed usunięciem
Sander Mangel

Odpowiedzi:

56

Kroki poniżej opisują, jak skonfigurować środowisko do tworzenia niestandardowych modułów, a nie do produkcji.

Inicjalizacja projektu

  1. Dodaj poświadczenia repo.magento.com i token dostępu do github do auth.json w katalogu osobistym kompozytora
  2. Utwórz projekt za pomocą następującego polecenia:

    composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .

  3. Weź to .gitignore i umieść w katalogu głównym projektu. Prawie wszystkie podstawowe pliki / katalogi są już dodane do katalogu głównego .gitignore, ale lepiej również dodać następujące 2 /updatei /phpserver(wystarczy dodać te 2 wiersze do .gitignore)

  4. Zainicjuj nowe repozytorium git w katalogu głównym projektu
  5. Dodaj wszystkie nieśledzone pliki do git i zatwierdź je
  6. Rozpocznij tworzenie swoich modułów jak zwykle (umieść je poniżej app/code/VendorName/ModuleName), teraz będziesz mieć tylko swój własny kod w repozytorium git

Instalacja Magento

  1. Upewnij się, że wszystkie uprawnienia systemu plików są ustawione zgodnie z oficjalnym przewodnikiem
  2. Zainstaluj Magento za pomocą wiersza poleceń, np .:

    ${project_root}/bin/magento setup:install \ --db-host=localhost \ --db-name=magento \ --db-user=root \ --backend-frontname=admin \ --base-url=http://base.url.goes.here/ \ --language=en_US \ --timezone=America/Chicago \ --currency=USD \ --admin-lastname=Admin \ --admin-firstname=Admin \ [email protected] \ --admin-user=admin \ --admin-password=123123q \ --cleanup-database \ --use-rewrites=1

  3. Włącz zadanie cron indeksatorów, np. Na Ubuntu:

    echo "* * * * * php ${project_root}/bin/magento cron:run &" | crontab -u www-data -

  4. Magento będzie działać w defaulttrybie, a wszystkie brakujące treści zostaną automatycznie wygenerowane na pierwsze żądanie. Nie trzeba więc uruchamiać kompilatora ani instalować zawartości statycznej
  5. [opcjonalnie] Jeśli używasz PHP Storm, uruchom następujące polecenie, aby włączyć obsługę XSD:

    bin/magento dev:urn-catalog:generate .idea/misc.xml

Alex Paliarush
źródło
Cześć Aleks. Krok 3 inicjalizacji projektu - czy mógłbyś go trochę rozwinąć? Czy zauważyłeś, że musisz ręcznie skopiować ten podkatalog do katalogu głównego? (Zastanawiam się, czy coś nie działa poprawnie - nie spodziewałem się tego kroku.)
Alan Kent
@AlanKent obecnie pobierasz wszystkie pliki związane z Magento vendor, w tym magento2-base, które są tylko szkieletem nowego projektu. Nie wiem, dlaczego ten krok nie jest skonfigurowany do automatycznego wykonywania przez kompozytora, spróbuje się dowiedzieć. Jeśli chodzi o .gitignorekopiowanie z innego repozytorium, jest już dyskutowane, jak wyeliminować / uprościć ten krok.
Alex Paliarush,
Krok 3 nie jest wymagany. Scalanie plików / folderów odbywa się w kroku 2.
Maddy,
Dzięki @Maddy. @AlanKent, kopiowanie magento2-basedo katalogu głównego nie jest już konieczne (tylko zweryfikowane), wydaje się być ostatnio naprawione. Usunięto ten krok z odpowiedzi.
Alex Paliarush,
1) położyłem cały mój kod na repozytorium, już odinstalowany i wszystko, kiedy ściągam z tego repozytorium i po prostu zmieniam ustawienia dla administratora i pseudonimu db, czy wszystko będzie działać poprawnie? 2) skoro zapomniałem wykluczyć folder var / i pub / podczas wypychania, czy mogę je całkowicie usunąć, aby mogły zostać usunięte na zdalnym repozytorium, czy zregenerują się ponownie? Dzięki.
Lachezar Raychev
25

W przypadku inicjalizacji i instalacji postępuj zgodnie z instrukcjami Alexa dla większości kroków, tylko różnice, które poleciłbym:

Konfiguracja Git

Przechowuj tylko następujące pliki w repozytorium Git:

  • composer.json
  • composer.lock
  • app / etc / config.php

Do niestandardowego kodu projektu używaj także oddzielnych modułów, które dołączasz do kompozytora. Zarządzanie tym kompozytorem jest łatwiejsze, ponieważ możesz zablokować określoną wersję / wydanie, które chcesz wdrożyć. Zmusza to również do korzystania z tego samego podejścia w przypadku modułów wewnętrznych i zewnętrznych.

Rozlokowanie

Podczas programowania aktualizujesz moduły w swoim środowisku (dev / test) poleceniem:

composer update

Spowoduje to zaktualizowanie pliku composer.lock do wersji zainstalowanych w tej instalacji.

Podczas przemieszczania / produkcji wstępnej / produkcji możesz utworzyć / zainstalować tę samą konfigurację za pomocą polecenia:

git pull
composer install

Spowoduje to zainstalowanie wszystkich tych samych modułów, które są używane w dev / test, aby upewnić się, że testowanie przed opublikowaniem do produkcji odbywa się przy użyciu tych samych wersji modułów, z którymi jest rozwijany.

Po instalacji uruchom następujące polecenia:

bin/magento setup:upgrade
bin/magento setup:di:compile (or setup:di:compile-multi-tenant)
bin/magento setup:static-content:deploy

Spowoduje to zaktualizowanie bazy danych (aktualizacji schematu i danych), wygenerowanie konfiguracji DI i wdrożenie wszystkich plików widoku statycznego.

Vladimir Kerkhoff
źródło
Może warto używać przykładowych danych zamiast generować urządzenia? Urządzenia wypełniają tylko najbardziej krytyczne moduły i wydają się przydatne do testowania wydajności.
Alex Paliarush,
Dzięki, usunąłem tę część, ponieważ nie jest potrzebna podczas korzystania z witryny w produkcji.
Vladimir Kerkhoff
Jest to bardzo zgodne z podejściem, którego również używam. Działa to również dobrze z Magento 1 (z mniej złożonym procesem kompilacji) Pozwól kompozytorowi wykonać swoją pracę, działa bardzo dobrze dla wdrożeń z mojego doświadczenia i nie widzieliśmy wielu wad innych niż złożoność ze strategią .gitignore, kiedy nie podążaj za mniejszą powierzchnią w git.
Aepod
Ta instalacja wygląda jak „integrator”. Dodaje repozytoria w vendor / magento / *. W aplikacjach / code / .. i innych katalogach nie będzie kodu. Jak miałbym mieć główne katalogi Magento 2 jak w archiwum .zip Czy można dodać przez kompozytora moduł (inne repozytorium git) i niż automatycznie skończyć w app / code / ...?
niejasne
4
ryzykowne, kompozytor nie jest narzędziem do wdrażania. jeśli coś zawiedzie podczas instalacji kompozytora podczas uruchamiania w produkcji ...
Claudiu Creanga
3

Re .gitignore, 2.2. Oficjalna odpowiedź Magento brzmi: „config.php przechodzi do git, env.php nie”.

Patrzymy na wtyczki kompozytora, takie jak Mediawiki, aby zbliżyć wewnętrznego programistę do rozwoju rozszerzeń i stron klientów. Wciąż odkrywam, jeszcze nie ostateczne.

Bardzo podobało mi się używanie typu repozytorium Composer „Path” ze ścieżką ../othergitrepo/app/code/*/*pobierania modułów, ale używa on dowiązań symbolicznych, które nie działają tak dobrze w środowiskach programistów korzystających z Unison lub podobnego.

Alan Kent
źródło
3

stosujemy inne podejście, które nie wymaga osobnego kompilacji serwer / proces , rozwijamy się lokalnie jak w produkcji

następnie zatwierdzamy wszystkie pliki niezbędne do produkcji . następnie po prostu wdrażamy zestawy zmian na serwerze i uruchamiamy polecenie aktualizacji.

przejście do wersji odpowiedniej do programowania, ale działającej również w trybie produkcyjnym było trudną częścią i wciąż nie jest idealne, ale teraz mamy przepis, który działa.

Powodem jest to, że chcemy mieć 100% kontroli nad tym, jaki kod zostanie wprowadzony do produkcji. ponieważ magento2 generuje mnóstwo kodu, musimy uruchomić go lokalnie, aby móc zrozumieć wszystkie efekty i móc debugować jak podczas produkcji.

Zdaję sobie sprawę, że nie tyle wielu ludzi zaleca, ale dla nas działa najlepiej.

kroki konfiguracji interfejsu użytkownika

Aby te skrypty działały, ustaw sklep w trybie produkcyjnym w env.php i skonfiguruj motyw dev/tools/grunt/configs/themes.js. (następujące kroki zostały umieszczone w ansible playbook)

  1. usunąć var/cache
  2. usunąć var/view_preprocessed
  3. usuń pub/static/*(nie usuwaj .htaccess)
  4. usunąć var/composer_home
  5. biegać php bin/magento cache:flush
  6. biegać php bin/magento setup:static-content:deploy %your_languages%
  7. usuń wszystkie motywy / języki, których tak naprawdę nie używasz z pub / static / frontend
  8. usuń z kopii mniej plików pub/static/frontend
  9. biegać php bin/magento dev:source-theme:deploy --locale="%your_language%" --theme="%your_theme%" css/styles-m css/styles-l css/email css/email-inline
  10. opcjonalnie: używamy skryptu bash do zmiany bezwzględnych dowiązań symbolicznych, utworzonych w kroku 9, na względne, umożliwiając uruchamianie chrypki spoza vm
  11. biegać grunt less:your_theme

kroki backend / di-setup

  1. usunąć var/cache
  2. usunąć var/generation
  3. usunąć var/composer_home
  4. usunąć var/di
  5. biegać php bin/magento cache:flush
  6. biegać php bin/magento setup:di:compile
greenone83
źródło
Dzięki za to @ greenone83, takie podejście zasadniczo przyjąłem, chociaż generuję backend jako część interfejsu. NIGDY nie używam setupu: di: kompiluj, bo uważam, że to wszystko psuje! Nie rozumiem tylko, dlaczego setup: static-content: deploy tworzy pliki w wygenerowanym / kodzie (lokalizacja zmieniła się od twojego postu)? Przekonałem się, że jeśli usunę cały wygenerowany / kod, gdy moja witryna będzie w trybie produkcyjnym, pliki te zostaną automatycznie utworzone podczas przeglądania witryny.
PedroKTFC
2

Powinieneś też zignorować te pliki
/app/etc/config.php
/app/etc/env.php
/.idea/workspace.xml // phpstorm

mrtuvn
źródło
2
Jeśli zignorujesz plik config.php, będziesz musiał ponownie włączyć nowe rozszerzenie po wypchnięciu go do innego środowiska, dlatego lepiej jest dołączyć je do swojego repozytorium.
Vladimir Kerkhoff,