Magento2 - distribuzione locale / di gestione temporanea / produzione e gitignore

Questo potrebbe essere un tipo di discussione più che una domanda.

Mi piacerebbe sapere che la politica di distribuzione che si seguono con Magento2 e locali > messa in scena > produzione ambienti

Dopo alcuni tentativi abbiamo deciso che l'approccio migliore (o almeno il più solido) sarebbe questo file gitignore, inclusa la cartella del fornitore in 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

Quindi eseguiamo compositore solo in ambiente locale: come ogni nuova estensione, o l'aggiornamento del software viene testato in locale, quindi convalidato e impegnato. Probabilmente includeremmo anche il file app / etc / config.php in git ma quel file viene riscritto durante l'esecuzione setup:upgrade, giusto?

Includere il fornitore significa che la dimensione del repository sarà maggiore di (forse) consigliata ma in questo modo durante la distribuzione del codice, eseguiamo semplicemente la sequenza:

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

Informazioni correlate: http://www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

Scopri perché scegliamo il comando di compilazione come Magento 2 opzionale - setup: di: compile ?

AGGIORNARE

La verità è che stiamo riscontrando alcuni problemi durante la distribuzione delle modifiche al codice nei nostri progetti Magento 2 pubblicati

Le modifiche funzionano a livello locale e di gestione temporanea (selezionato in entrambe le modalità: sviluppatore e produzione ... sebbene configuriamo concettualmente quegli ambienti in modalità sviluppatore), ma alcuni di essi non funzionano in ambiente di produzione (in modalità produzione), ecc ... quindi non sono sicuro che stiamo seguendo la giusta strategia. Mi piacerebbe vedere qual è la sequenza di comandi appropriata e la pertinenza dell'ordine in quei comandi

In effetti, ogni giorno sono meno convinto dell'utilità della modalità di produzione Magento 2, a meno che tu non abbia intenzione di cambiare nulla nel progetto. Mi puoi cambiare idea?

In effetti, ogni giorno sono meno convinto dell'utilità della modalità di produzione Magento 2, a meno che tu non abbia intenzione di cambiare nulla nel progetto. Mi puoi cambiare idea?

Non sono sicuro di aver capito bene, ma è esattamente a questo che serve la modalità di produzione : sistemi di produzione in cui non cambi nulla (per quanto riguarda il codice). Fino alla prossima distribuzione, cioè.

Trovo la distribuzione basata su Git che stai usando meno adatta per Magento 2 rispetto a Magento 1, a causa di tutto il preelaborazione. La compilazione e la distribuzione sono più complesse e IMHO non ha modo di aggirare un processo di compilazione automatizzato

Cosa consiglierei:

• Avere distribuzioni ripetibili , vale a dire che si dovrebbe essere certi che lo stesso codice esatto finisca nella produzione in fase di gestione temporanea, inclusi i file generati .

• A tale scopo, separa la build dalla distribuzione e procedi nel seguente processo:

  • composer install( vendorè possibile anche aggiungere al repository, ma se lo hai fatto solo per evitare di eseguire compositore sul server durante la distribuzione, piuttosto fallo nella fase di compilazione e mantieni solo composer.locknel repository)

  • Generazione di codice (YMMV):

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

  • creare un archivio (il manufatto accumulo ) dalla directory completa Magento, escluso mediae var, ma tra cui vendor, pub, var/generatede var/di. A partire da magento-2.2 , var/generatede var/divengono spostati su generated/codee generated/metadata, il che rende più facile separarli dal resto dei varquali dovrebbe essere ignorato per le distribuzioni.

• Nella distribuzione, copiare l'artefatto di compilazione sul server di destinazione, estrarlo in una nuova directory e:

  • link directory persistenti in esso ( media, var/session, var/log, ...)
  • abilitare la modalità di manutenzione
  • cambia la radice del documento (di solito il docroot è un link simbolico all'ultima versione, cambiarlo nella nuova versione)
  • svuota cache
  • correre setup:upgrade
  • disabilita la modalità di manutenzione

• Questo processo di distribuzione può essere facilmente implementato con Deployer , che è come Capistrano ma in PHP. Una soluzione di distribuzione completa per Magento 2 basata su deployer è disponibile qui: https://github.com/mwr/magedeploy2 (grazie a netz98!) Ed eccone un'altra che usiamo: https://github.com/staempfli / magento2-distribuzione-tool

• Conservare app/etc/config.phpnel repository è utile per tenere traccia dei moduli abilitati e disabilitati.

Questa non è un'istruzione passo per passo, ma dovrebbe darti una panoramica per un'alternativa più solida al tuo processo attuale. Dai un'occhiata agli strumenti collegati per vedere come potrebbe apparire una soluzione completa.

Secondo me, attendere Magento 2.2 o provare a implementare un approccio simile.

Magento 2.2 introduce la distribuzione della pipeline, ad esempio separando il server di build con il server di produzione.

Ecco la documentazione ufficiale: http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

Inoltre, attualmente sto usando Ansible per gestire l'implementazione automatizzata con modelli di configurazione e configurazione di più ambienti.