Zarządzanie Magento / Composer / Deployment

Tak więc lubię korzystać z instalatora hackathonu Magento Composer, ale staram się zrozumieć, jak inni używają go w związku z usługą wdrażania. Obecnie używam DeployHQ i tak, mogę ustawić go do wdrażania i uruchamiania kompozytora, gdy pojawi się aktualizacja repozytorium, ale nie ma to dla mnie sensu.

Moje główne repozytorium kompozytora, zawierające tylko plik json wszystkich pakietów, które chcę dołączyć do mojej kompilacji, jest aktualizowane tylko po dodaniu nowego pakietu do listy.

Kiedy aktualizuję mój motyw lub niestandardowe rozszerzenie (do którego odwołuje się plik json), nie ma „haka” do aktualizacji mojej usługi wdrażania. Muszę się więc zalogować na mój serwer i ręcznie uruchomić kompozytora (co powoduje, że strona zostaje zamknięta, dopóki nie zostanie ukończona).

Jak więc inni to zarządzają? Czy powinienem uruchamiać kompozytora tylko lokalnie i dołączać folder dostawcy do mojego repozytorium?

Wszelkie odpowiedzi będą mile widziane.

W naszej agencji utworzyłem strukturę, która pozwala nam używać Composer do wdrażania wszystkich naszych stron Magento. To może być trochę przesada w przypadku zadanego pytania, ale i tak oto podstawowy przegląd struktury:

Struktura repozytorium

Poniżej znajduje się struktura folderów repozytorium „nadrzędnego”. Zawiera kompozytor JSON i pliki blokujące oraz inną konfigurację wymaganą do wdrożenia.

- code
   - magento
- deployment
- environmental
   - local
       - local.xml
       - robots.txt
   - staging
       - local.xml
       - robots.txt
   - production
       - local.xml
       - robots.txt
- provisioning
- public
   - index.php
- vendor
- composer.json
- composer.lock

• Wszystkie dostosowania dostosowane do klienta są przechowywane w osobnym module „dostosowań”, który jest instalowany za pomocą Composer
• Rdzeń Magento jest zawarty jako podmoduł Git ( code/magento)
• Niestandardowe index.phpi inne foldery, takie jak multimedia i błędy, znajdują się w folderze publicznym poza katalogiem głównym Magento
• Pliki specyficzne dla środowiska (local.xml, robots.txt itp.) Są symlinkowane do katalogu głównego Magento podczas procesu wdrażania
• Folder dostawcy jest wykluczony z Git, ale plik composer.lock jest dołączony.

Rozlokowanie

• Wdrażamy za pomocą Capsitrano, który pozwala na wiele serwerów aplikacji i środowisk (inscenizacja / produkcja)
• Capistrano buduje całą bazę kodu na serwerze w nowym folderze, a następnie zamienia dowiązanie symboliczne webroot na samym końcu, co oznacza, że ​​nie ma przestojów dla Twojej witryny.
• Capistrano działa composer installpodczas kompilacji i wdraża wszystkie moduły do ​​submodułu Magento.

To wciąż nie jest ciągła konfiguracja integracji, ale uważam, że działa dobrze na stronach Magento. Wyślij mi wiadomość, jeśli chcesz uzyskać więcej porad dotyczących Twojej konfiguracji.

Inną metodą jest użycie strategii wdrażania hackathonów magento, która wygląda trochę tak w pliku composer.json:

"extra": {
    "magento-root-dir": "./",
    "magento-deploystrategy": "copy",
    "magento-force": true
}

Zastosowanie powyższej metody powoduje skopiowanie zainstalowanych plików od dostawcy do faktycznej instalacji, co pozwala na zatwierdzenie go w Git i wdrożenie zgodnie z normalną procedurą, bez konieczności instalowania przez kompozytora.

Nie jestem wielkim fanem wycofywania się z repozytoriów stron trzecich, gdy masz zamiar przeprowadzić wdrożenie na żywo, a bycie zależnym od repozytoriów stron trzecich jest dość ryzykowne, chyba że masz jakiś bufor proxy dla swojej sieci .

Przeczytaj ten artykuł, a zobaczysz inną perspektywę: http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_debacle

Zasadniczo NPM spadł (tak jakby ...) i systemy kompilacji wszystkich przestały działać (w przypadku krytycznych wdrożeń!), Ponieważ były bezpośrednio zależne od NPM. (NPM jest trochę podobny do Packagist dla Javascript, z tym wyjątkiem, że NPM faktycznie hostuje plik, a Packagist po prostu wskazuje repozytorium modułów Github - popraw mnie, jeśli się mylę)

edycja: tylko odpowiedź czerwonego fschmenglera. To jest rozwinięcie jego pierwszego podejścia

Ważne jest, aby zrozumieć, że Composer nie jest narzędziem wdrażania, ale narzędziem programistycznym.

Istnieją różne podejścia do przygotowania wdrożenia ze wszystkimi zależnościami:

• zatwierdz katalog katalogu (lub gdziekolwiek kompozytor instaluje źródła) do repozytorium projektu
• użyj serwera kompilacji, który działa composer installi tworzy archiwum z rezultatem, które możesz wdrożyć powtarzalnie w różnych systemach docelowych
  • uruchamianie composer installna serwerze, a następnie przełączanie dowiązań symbolicznych zgodnie z sugestią @ jharrison.au jest odmianą tego

Poza tym, ja nie polecam korzystania kompozytora dla każdego modułu i tylko zachować composer.jsoni composer.lock w repozytorium projektu. To przesada i niepotrzebnie komplikuje rozwój. Ma to sens w przypadku kodu, który jest ponownie wykorzystywany w kilku projektach, ale dlaczego miałbyś umieszczać kod specyficzny dla projektu w osobnych repozytoriach?

Moja obecna struktura projektu wygląda następująco (przy użyciu alternatywnych instalatorów kompozytora AOE ):

• srczawiera wszystkie moduły specyficzne dla projektu. Kompozytor instaluje tutaj również inne moduły Magento
• .modmanlinki do src, aby modman mógł łatwo obsłużyć symlinkowanie
• wwwjest webroot. Kompozytor instaluje tutaj rdzeń Magento

W ten sposób dołączam moduły zewnętrzne do repozytorium. Jeśli nie chcesz tego robić, dostosuj go w następujący sposób:

• srczawiera wszystkie moduły specyficzne dla projektu. Aby je włączyć .modman, aby modman tworzył dowiązania symboliczne, użyjmodman link
• .modmanjest w .gitignore. Kompozytor instaluje tutaj moduły Magento
• wwwjest webroot. Kompozytor instaluje tutaj rdzeń Magento