15

This could be one kind of discussion more than a question.

I'd like to know which deployment policy you follow with Magento2 & local > staging > production environments

After some tries we've decided the best (or at least, the most solid) approach would be this gitignore file including vendor folder 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

So we run composer only in local environment: As any new extension, or software upgrade is tested in local, then validated and committed. We'd probably then include app/etc/config.php file in git too but that file is rewriten when running setup:upgrade, right?

Including vendor means repository size will be bigger than (maybe) recommended but this way when deploying code, we just run the sequence:

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

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

See why we choose compile command as optional Magento 2 - setup:di:compile ?

UPDATE

The truth is we are having some problems when deploying code changes in our published Magento 2 projects

Changes work in local & staging (checked in both modes: developer & production... although we conceptually configure that environments in developer mode), but some of them don't work in production environment (in production mode), etc... so I am not sure we are following the right strategy. I'd like to see what's the appropriated command sequence, and the relevance of the order in that commands

In fact, every day I am less convinced about the utility of Magento 2 production mode, unless you are not going to change anything in the project. Can you change my mind?

1
  • I going the same route: everything in my git repo. The production machine does not have composer so there is no other way for me. May I ask how you deal with .git repositories inside the vendor folder? When I commit to my repo those are considered as submodules and therefore do not end up inside my repo.
    – omsta
    Jan 18, 2019 at 16:45

2 Answers 2

21
+100

In fact, every day I am less convinced about the utility of Magento 2 production mode, unless you are not going to change anything in the project. Can you change my mind?

I'm not sure if I understand you correct, but that's exactly what the production mode is for: production systems where you do not change anything (code wise). Until the next deployment, that is.

I find the Git based deployment that you are using less suitable for Magento 2 than it was for Magento 1, because of all the preprocessing. The build and deployment is more complex and IMHO there is no way around an automated build process

What I would recommend:

  • Have repeatable deployments, i.e. you should be sure that the exact same code ends up in production that was in staging, including generated files.
  • To achieve that, separate build from deployment and do the following in the build process:

    • composer install (adding vendor to the repository instead is possible too, but if you did that just to avoid running composer on the server during deployment, rather do it in the build step and only keep composer.lock in the repo)
    • Code generation (YMMV):

      bin/magento setup:di:compile
      bin/magento setup:static-content:deploy
      
    • create an archive (the build artifact) from the full Magento directory, excluding media and var, but including vendor, pub, var/generated and var/di. Starting with , var/generated and var/di are moved to generated/code and generated/metadata, which makes it easier to separate them from the rest of var which should be ignored for deployments.

  • In the deployment, copy the build artifact to the target server, extract it to a new directory and:

    • link persistent directories into it (media, var/session, var/log, ...)
    • enable maintenance mode
    • switch document root (usually the docroot is a symlink to the last release, change it to the new release)
    • flush cache
    • run setup:upgrade
    • disable maintenance mode
  • This deployment process can be easily implemented with Deployer, which is like Capistrano but in PHP. A full deployment solution for Magento 2 based on deployer can be found here: https://github.com/mwr/magedeploy2 (thanks to netz98!) and here is another one that we use: https://github.com/staempfli/magento2-deployment-tool

  • Keeping app/etc/config.php in the repository is good to keep track of enabled and disabled modules.

This is not a step by step instruction but it should give you an overview for a more robust alternative to your current process. Take a look at the linked tools to see how a full solution may look like.

5
  • Thank you very much Fabian... I was looking for something like this, as we've been using Capistrano in Magento 1 & I was hoping to find a similar tool for Magento 2... I will try during the week & give you more feedback Jul 31, 2017 at 18:02
  • @fabian-schmengler explains pretty much what we do. We generate everything in staging environment and we test it there in production mode, then we move the generated code from staging environment to production environment to make sure that the code that ends in production environment is exactly the same we have in staging.
    – diazwatson
    Aug 1, 2017 at 0:39
  • Thanks for the explanation. It would be nice to have the content of the gitignore file in your answer.
    – Mehdi
    Aug 1, 2017 at 20:45
  • @Mehdi the .gitignore file is not relevant to the actual problem. You can just use the default one. Aug 2, 2017 at 15:19
  • @FabianSchmengler, I have similar problem, all file commit changes will reflect after each deployment in all the systems, but the admin config settings any theme configs will not reflect, is there any solution to avoid configuring same settings multiple times in all the system? Mar 18, 2020 at 13:31
5

To my mind, wait Magento 2.2 or try to implement a similar approach.

Magento 2.2 introduces pipeline deployment by for example separating build server with production server.

Here is the official documentation : http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

Moreover, currently I am using Ansible to manage to automated deployment with configuration templates and multiple environment setup.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.