Magento2 - Yerel / Hazırlama / Üretim Dağıtımı & Gitignore

Bu bir sorudan çok daha fazla tartışma olabilir.

Magento2 ve yerel > sahneleme > üretim ortamlarıyla hangi dağıtım politikasını izlediğinizi bilmek istiyorum

Bazı denemelerden sonra en iyi (veya en azından en sağlam) yaklaşımın git'teki satıcı klasörü de dahil olmak üzere bu gitignore dosyası olacağına karar verdik .

.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

Bu yüzden besteciyi yalnızca yerel ortamda çalıştırıyoruz : Herhangi bir yeni uzantı veya yazılım yükseltmesi yerel olarak test edildikten sonra onaylanır ve onaylanır. Muhtemelen git / app / etc / config.php dosyasını da dahil ederiz, ancak bu dosya çalışırken yeniden yazılır setup:upgrade, değil mi?

Satıcıyı dahil etmek, havuz boyutunun (belki) önerilenden daha büyük olacağı anlamına gelir, ancak bu şekilde kod dağıtılırken, diziyi çalıştırıyoruz:

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

İlgili bilgi: http://www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

Derleme komutunu neden isteğe bağlı olarak Magento 2 olarak seçtiğimize bakın - setup: di: compile ?

GÜNCELLEME

Gerçek şu ki, yayınlanan Magento 2 projelerimizde kod değişikliklerini uygularken bazı sorunlar yaşıyoruz

Değişiklikler yerel ve evrelemede çalışır (her iki modda da kontrol edilir: geliştirici ve üretim ... bu ortamları geliştirici modunda kavramsal olarak yapılandırmamıza rağmen), ancak bazıları üretim ortamında (üretim modunda) vb. bu yüzden doğru stratejiyi takip ettiğimizden emin değilim. Uygun komut dizisinin ne olduğunu ve bu komutlardaki düzenin alaka düzeyini görmek istiyorum

Aslında, projede hiçbir şeyi değiştirmeyeceğiniz sürece, her gün Magento 2 üretim modunun faydası hakkında daha az ikna oldum. Fikrimi değiştirebilir misin?

Aslında, projede hiçbir şeyi değiştirmeyeceğiniz sürece, her gün Magento 2 üretim modunun faydası hakkında daha az ikna oldum. Fikrimi değiştirebilir misin?

Sana düzeltmek anlıyorum olmadığından emin değilim, ama bu üretim modu için tam olarak ne: Üretim sistemleri nerede bir şey değişmez (bilge kodu). Bir sonraki konuşlandırmaya kadar.

Git ön dağıtımını Magento 2 için kullandığınız tüm ön işleme nedeniyle Magento 1'den daha az uygun buluyorum. Derleme ve dağıtım daha karmaşıktır ve IMHO otomatik derleme işleminin bir yolu yoktur

Ne tavsiye ederim:

• Var tekrarlanabilir dağıtımları, yani emin olmalıdır tam aynı kod, sahnesi oldu üretimde biter oluşturulan dosyalar dahil .

• Bunu başarmak için derlemeyi dağıtımdan ayırın ve derleme işleminde aşağıdakileri yapın:

  • composer install( vendorbunun yerine depoya eklemek de mümkündür, ancak bunu dağıtım sırasında sunucuda besteci çalıştırmaktan kaçındıysanız, bunu oluşturma adımında yapın ve yalnızca depoda tutun composer.lock)

  • Kod oluşturma (YMMV):

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

  • bir arşiv (yaratmak inşa eser hariç, tam Magento dizinden) mediave varfakat içeren vendor, pub, var/generatedve var/di. İle başlayan magento-2.2 , var/generatedve var/ditaşınır generated/codeve generated/metadatadaha kolay geri kalanından ayırmak için yapar, vardağıtımlar için göz ardı edilmelidir.

• Dağıtımda, yapı yapay nesnesini hedef sunucuya kopyalayın, yeni bir dizine çıkarın ve:

  • İçine kalıcı dizinleri bağlantı ( media, var/session, var/log, ...)
  • bakım modunu etkinleştir
  • belge kökünü değiştir (genellikle docroot son sürüme bir simge bağlantısıdır, yeni sürüme değiştirir)
  • önbelleği temizle
  • Çalıştırmak setup:upgrade
  • bakım modunu devre dışı bırak

• Bu dağıtım işlemi, Capistrano gibi ama PHP'de bulunan Deployer ile kolayca uygulanabilir . Dağıtımcıya dayalı Magento 2 için tam bir dağıtım çözümü burada bulunabilir: https://github.com/mwr/magedeploy2 (netz98 sayesinde!) Ve kullandığımız başka bir çözüm: https://github.com/staempfli / magento2 dağıtım-aracı

• Tutulması app/etc/config.phpdepoda etkin ve devre dışı modüllerin takip etmek için iyidir.

Bu adım adım talimat değildir, ancak mevcut işleminize daha sağlam bir alternatif için genel bir bakış sunmalıdır. Tam bir çözümün nasıl görünebileceğini görmek için bağlantılı araçlara göz atın.

Bana göre Magento 2.2'yi bekleyin ya da benzer bir yaklaşım uygulamaya çalışın.

Magento 2.2 , örneğin inşa sunucusunu üretim sunucusuyla ayırarak boru hattı dağıtımını sunar .

İşte resmi belgeler: http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

Ayrıca, şu anda Ansible'ı yapılandırma şablonları ve çoklu ortam kurulumu ile otomatik dağıtımı yönetmek için kullanıyorum.