从开发->阶段->生产迁移（CMI）配置的建议工作流程是什么？

41

几个月前，我们有一个drupalcamp，有人问如何使用新的配置（CMI）系统管理部署。一种可能的理想工作流程是将配置保留在版本控制中，并且仍然能够在团队成员之间迁移配置。

我们在会议室中能够发现的最好结果（部分基于DrupalCon Portland的演讲）是：

告诉版本控制忽略活动的配置目录。
将所有配置复制到暂存目录并提交到版本控制。

并使用settings.php在两个环境之间反转活动目录目录。但是，尽管弄清楚从一台服务器到另一台服务器的部署工作流程虽然复杂但可行，但从多个本地环境（即多个开发人员）到开发人员（或彼此之间）的建议工作流程是什么？可能的问题是每个团队成员会共享相同或相似的环境，那么如何改变一个队友的机器？

migration 8 version-control

— btmash
source

5

我不同意目前的近票。由于CMI是Drupal 8的重点，我认为我们可以在这里找到一些好的答案。

— mpdonadio

3

同意，这是一个很好的问题。我相信drupal.org/node/1703168的关键任务是关于此主题和其他主题的，并且尚未完全解决，因此此处的答案可以帮助推动该问题的发展。

— Berdir 2013年

如果我的问题对CMI计划持否定态度，我深表歉意（这完全不是我的意图）。我已经更新了问题，所以听起来更中立。

— btmash

2

我几乎要说“您尝试过功能”。也许“ D8”应该放在问题标题中？“ 8”标签有点看不见。

— donquixote13年

1

修改了标题，因此可以通过标签或标题来查看问题：)

— btmash

19

与CMI维护人员讨论了一些之后，关于什么是最佳方法的讨论还没有结束，但以下是目前最有意义的。

暂时保持简洁，将根据问题/当引用的问题得到正式答复后进行扩展。

所以，首先，事实

如前所述，存在活动目录和暂存目录。Active由Drupal完全管理，不支持直接在其中进行更改（通过切换到其他位置进行直接或间接更改）。
分阶段是Drupal寻找要导入和执行的配置的地方，否则不关心它。
导入过程很重要，配置更改可能以某种方式影响站点，因此需要检查其有效性。您不能将文本字段的字段类型更改为实体引用，例如，这根本不起作用。
config import始终需要在所有配置上运行，您不能导入单个视图或节点类型。它曾经尝试过，但是试图应付依赖关系，删除/重命名等导致系统非常复杂，并且无法正常工作。
重新安装默认配置的唯一方法是重新安装该模块。这意味着它将首先尝试删除所有配置（如字段）。所以这不是一个真正的选择。我认为可以对更新功能进行手动，特定的更改，但是对此我觉得太麻烦了。
正如功能模块所描述的那样，它将专注于提供可重用的功能，而不是连续的配置部署。这是它最初设计的目的。

鉴于此，现在的建议是将登台目录放入版本控制中。然后，每个开发人员都可以完全控制自己放置的内容，方法是复制整个活动目录，也可以仅复制特定的配置文件。然后提交暂存目录更改，将其推送到生产环境，然后运行配置导入（在UI中或使用drush）。

— 贝迪尔
source

版本控制中的暂存目录，我明白了。其他部分是我的想法正在尝试的过程。因此，如果有人进行更改，他们会将其更改复制到登台目录并提交。此后，其他开发人员/下一个服务器将获取更改并将其同步到活动目录。然后冲洗并重复执行此过程中的任何其他服务器链（分段，生产等）。而且它总是经过暂存，因此不再发生目录切换。这样准确吗？

— btmash

是。必须没有目录切换。每个配置更改都必须经过导入过程，否则您可能会遇到站点损坏的情况。例如，模块列表也是配置。部署它意味着需要安装/卸载模块（注意：这尚不可行，但存在修复问题）。

— 2013年

好的，所以现在还有更多问题（分成2条评论）:)首先，您提到模块是配置。因此，即使将模块添加到存储库中并且未启用/禁用它，也仅需要坐在那里就需要安装/卸载该模块？

— btmash

以及后续措施：（A）是否有一种机制可以复制活动目录中的更改->暂存（以简化操作，而将人员转移到config目录中的这些组件可能是一种选择某些变量的方法）。（B）更改从暂存->活动同步后，暂存目录是否被清空？（B1）如果是这样，那么从devops的角度来看，策略是在git pull之前重置该目录吗？（B2）如果不是，那么假设在进行staging-> active同步时，对配置没有任何影响应该没有影响吗？

— btmash

模块安装状态为配置。不是模块本身：)这就是您要部署的内容。a）有一个UI可以下载活动目录的tar.gz，一个UI可以将所述tar.gz上载到暂存目录，而一个UI可以实际执行导入，其中包含更改的概述和差异。B）我相信现在它已被清空，但是我想您可以使用git轻松还原它。不确定，易于检查。所有这些东西都是可插入的，因此可能会有一些不删除的实现。B2）我没有收到，但是我认为是。

— Berdir 2013年

4

到目前为止，答案很好。谢谢大家！

我们最近启动了一个Drupal 8项目，并实现了以下工作流程。

我们有三个文件夹处于活动状态，暂存和导出。开发人员将其转储以导出。我不想继续上演。当共享配置未直接存储在暂存文件夹中时，我认为它更易于使用。这只是一个砍伐，我对此没有硬道理...

我们当前的drupal 8项目模板可在github上找到。我还编写了一些方便的drush命令，以加快开发人员的工作流程。无需从活动副本到出口的手动复制。

项目模板：https：//github.com/webflo/d8-project-template
其他Drush命令：https : //github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

— webflo
source

1

到目前为止，我同意这种方法。我已将本文中链接中的所有功能添加到Drush config-export和config-import命令中。我希望其他人可以和我和@florian一起探索这3个目录解决方案。

— moshe weitzman 2014年

您如何处理带有sites/default/files/config_HASH哈希后缀的config文件夹，例如config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr

— therobyouknow

@therobyouknow可以覆盖这些文件夹的位置。只需查找“站点配置文件的位置”。在settings.php中，我使用以下代码段。这意味着，配置存储在Drupals根目录之外。$ config_directories = array（'active'=>'../config/active'，'staging'=>'../config/staging'，）;

— webflo 2015年

谢谢@webflo我看到了。分别管理代码库和配置有什么好处？我认为这种分离有些人为，因为代码和配置（以yaml为单位）都决定了行为并相互依赖。在Drupal 7中，代码配置（或可由Git跟踪）是通过功能模块完成的，该模块为需要在代码中跟踪的每个特定配置创建了一个模块。在Drupal 8中，有功能3.x，据我所知，功能相同，但是使用YAML来存储配置，并且生成的模块不依赖于功能模块。

— therobyouknow 2015年

我认为您误解了我，配置目录仍在git中，但是我的Drupal站点不在git repo根目录中。该站点存储在/ web。因此/ config和/ web在同一级别。

— webflo

2

我还没有尝试过，但是我的计划是创建一个自定义模块，其中包含仅包含我关心的配置的“默认”配置文件。我相信其他模块可以包含覆盖其他模块的配置。（如果没有，则应使其成为可能）。

我认为您必须不理会config文件夹。忽略它。它是在安装时根据所有单个模块的配置文件自动生成的。路径很长而且很随机。如果将所有内容保存在一个存储库中，则将需要一个单独的存储库，并且将附带大量的默认，不需要的配置文件。

将配置放在自定义模块中使其成为您主要代码库的一部分。

部署过程为：

git pull或其他获取新文件的工具。
清除缓存。
重置默认配置。（来自自定义模块的文件）

您可以根据需要为每个环境创建自定义模块（具有其自己的配置）。

— 琼普
source

这听起来很像功能，不是吗？还是我缺少重要的区别？

— Letharion

这是一种有趣的方法，我喜欢这个想法。但是，作为CMI计划的一部分提到的最大优势之一是能够从配置目录移到配置上。从我看来，settings.php文件确实允许您指定活动/暂存目录的位置（即，它们不需要是自动生成的路径）。因此，我认为使用当前配置的工作流应该是可能的，而无需创建上述@Letharion所提到的功能。

— btmash

2

注意： 我很欣赏这不是关于问题的最严格答案，但是我还是把它放在了这里，一旦Features发布了8.x版本并且尘埃落定了，我将重新访问并编辑/删除。安顿了一点。这太大了，无法发表评论，我想在:-)中获得我的0.02英镑

作为Feature的忠实拥护者，建议您密切注意Features模块的D8化身。

取自项目页面

计划将Drupal 8的3.x版本功能与新的配置管理系统集成。如果仅需要导出简单的站点配置，则应使用D8配置管理系统代替“功能”。您将使用D8中的功能来导出捆绑的功能（例如“照片库功能”）。

我的方式有点看出来的是，这种想法更容易为开发团队工作的网站上的更小的部分。我仍然不打算进入工作流程，因为仍然有太多未知变量，但是我看不到它与当前的Features部署过程有很大不同。

我忍不住想，CMI很棒。但我的大多数网站仍将以功能模块结尾（尽管数量较少，原因是不必导出每种内容类型，权限等）

— Chapabu
source

虽然我确实同意功能会稍微改变其作用，并且（希望）是将配置组件捆绑在一起的工具（例如您提到的照相馆功能），但配置（据我所知）仍将通过主动维护。配置目录。因此，功能部件可以解决某个组件，但是如何在整个环境中管理配置目录工作流是真正的问题。部署过程与当前功能部署过程略有不同，主要是因为活动存储区数据位于db中，而数据存储区为文件。

— btmash

... d7功能部署过程涉及数据库中的活动存储数据和文件中的数据存储。我们正在转变为既是文件又是仅需确保这如何影响工作流程的转变。

— btmash

请注意，功能确实没有活动和数据存储/登台的概念。或至少不一致，这全都取决于与其集成的特定挂钩/事物。默认视图包含在代码中，例如，更改立即生效（除了缓存），没有具有功能的受控部署过程。在使用功能进行部署时，这始终是主要问题之一。

— 2013年

你是对的。我不知道如何将D7的配置模块与功能混合使用，但是我做到了。

— btmash 2013年