Magento2-本地/分段/生产部署和gitignore

这可能是一种讨论，而不是一个问题。

我想知道您对Magento2和本地 > 分段 > 生产环境遵循哪种部署策略

经过一些尝试，我们决定最好的（或至少最可靠的）方法是此gitignore文件，包括git中的vendor文件夹。

.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

因此，我们仅在本地环境中运行composer：由于任何新扩展或软件升级均在本地进行测试，然后进行验证和提交。然后，我们可能还会在git中包含app / etc / config.php文件，但是运行时会重写该文件setup:upgrade，对吗？

包括供应商意味着存储库大小将大于（也许）建议，但是通过这种方式，在部署代码时，我们只需运行以下序列：

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

相关信息：http : //www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

看看为什么我们选择compile命令作为可选的Magento 2-setup：di：compile？

更新

事实是，在我们发布的Magento 2项目中部署代码更改时，我们遇到了一些问题

更改在本地和暂存中工作（在两种模式下都进行了检查：开发人员和生产...虽然我们在概念上将环境配置为开发人员模式），但其中一些在生产环境（生产模式）中不起作用，等等。所以我不确定我们是否遵循正确的策略。我想看看适当的命令序列是什么，以及该命令中命令的相关性

实际上，除非您不打算在项目中进行任何更改，否则我每天都不相信Magento 2生产模式的实用性。你能改变主意吗？

实际上，除非您不打算在项目中进行任何更改，否则我每天都不相信Magento 2生产模式的实用性。你能改变主意吗？

我不确定我是否理解正确，但这就是生产模式的确切含义：生产系统中您无需进行任何更改（代码明智）。直到下一次部署。

我发现由于所有预处理，您正在使用的基于Git的部署不适合Magento 2，而不是适用于Magento 1。构建和部署更加复杂，恕我直言，自动化构建过程无法解决

我建议：

• 具有可重复的部署，即，您应确保完全相同的代码最终会出现在登台的生产环境中，包括生成的文件。

• 为此，请将构建与部署分开，并在构建过程中执行以下操作：

  • composer install（也可以vendor将其添加到存储库中，但是如果这样做是为了避免在部署过程中在服务器上运行composer，则应在构建步骤中进行操作，仅保留composer.lock在存储库中）

  • 代码生成（YMMV）：

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

  • 创建归档文件（在构建神器从全Magento的目录），但不包括media和var，但包括vendor，pub，var/generated和var/di。从magento-2.2开始，var/generated并将var/di其移动到generated/code和generated/metadata，这使得将它们与其余部分分离变得更加容易var，因此在部署中应将其忽略。

• 在部署中，将构建工件复制到目标服务器，将其解压缩到新目录，然后：

  • 链接持久目录进去（media，var/session，var/log，...）
  • 启用维护模式
  • 切换文档根目录（通常docroot是到上一发行版的符号链接，将其更改为新发行版）
  • 刷新缓存
  • 跑 setup:upgrade
  • 禁用维护模式

• 可以使用Deployer轻松实现此部署过程，就像Capistrano一样，但是使用PHP。可以在此处找到基于部署程序的Magento 2的完整部署解决方案：https : //github.com/mwr/magedeploy2（感谢netz98！），这是我们使用的另一个解决方案：https : //github.com/staempfli / magento2-部署工具

• 保留app/etc/config.php在存储库中可以很好地跟踪已启用和已禁用的模块。

这不是分步说明，而是应该为您提供一个概述，以替代您当前的过程。查看链接的工具，看看完整的解决方案是什么样子。

在我看来，请等待Magento 2.2或尝试实现类似的方法。

Magento 2.2 通过例如将构建服务器与生产服务器分离来引入管道部署。

这是官方文档：http : //devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

此外，当前我正在使用Ansible通过配置模板和多个环境设置来管理自动部署。