Wordpress开发过程

Question

我想设计一个wordpress开发过程，如下图所示：

首先，我想为我的Wordpress网站创建一个bitbucket存储库。从该存储库中，我们所有的软件开发人员都应该能够将站点克隆到本地计算机上进行开发。对于开发所有开发人员应该有一个本地数据库来测试更改。

在开发人员完成任务后，他应该能够将他的更改推送到回购。当sprint完成后，我想将来自repo的所有更改与Jenkins管道/作业一起发送到测试环境。在这种环境下，测试人员应该能够使用prod系统中的克隆数据库测试所有新功能（包括dev更改）。

成功完成所有测试后，我希望能够将数据库更改应用于prod系统（使用SQL脚本），并将所有更改与其他Jekins管道/作业一起发送到prod系统。

你认为这可行吗？什么是插件更新？我可以为每个系统设置环境变量，以便可以在开发机器上完成插件更新吗？

我不确定这是否可行，因为插件或插件更新会创建大量新的数据库更改，我想我需要一个可以显示所有更改的工具，如Sourcetree for git。

是否有人具有wordpress和这种开发过程的专业知识，可以与我分享他的经验？

或者你认为这个过程不适用于wordpress？如果这是真的，那将是非常糟糕的，因为我需要一个像这样的过程。

非常感谢！

Answer 1

我真的不懂Wordpress，但你描述的过程绝对是可能的（例如我在Drupal和Adobe Experience Manager上实现了类似的解决方案）。

然而...

这个很难（硬。

在CMS项目中，更改/新功能可以包括： - 代码更改（PHP，CSS，JavaScript） - 数据库结构更改（例如，新表） - 数据库内容更改（例如，复制修复或默认/测试）内容） - 配置更改

找出哪个版本应该得到真正的难度。您希望开发人员提交更改，并使用测试内容在QA上复制该更改 - 但是一旦QA签署了该更改，您可能不希望将该测试内容提升为生产。配置更改应该可能在系统之间流动，但每个环境的值都不同。

为了管理数据库更改，我发现了一个监视database changes的插件;不知道那是多么可编剧。

我在过去类似情况下所做的是编写一个脚本，为每个更改创建数据库定义 - 因此开发人员可以运行该脚本，并将其作为代码更改的一部分提交。但它需要很多规则 - 您只能使用脚本修改数据库结构。

Answer 2

正确的答案是肯定的，你可以做到这一点。我非常了解WordPress，Bit-bucket，GIT，SVN，Linux，Ubuntu。我已经建立了一个非常类似于你描述的系统并且每天都使用它。

问题是CMS可能会变得棘手。确实如此，但您需要使用正确的工具进行正确的升级。因此，WordPress ALREADY内置了版本控制和修订版。 DATABASE根本不需要参与

首先。除非您正在更新插件，否则不需要更新数据库。但是对于严格的开发，没有DB推送是必要的。因此，您的开发人员可以检查进出Bit-bucket的文件。当主要开发人员批准更改时，他会迁移/推送到您的REPO中的MASTER BRANCH。在bit-bucket里面有一个名为GIT HOOKS的工具。每次推送到生产分支时，您都可以在服务器上触发php文件。 PHP文件的作用只是触发linux命令GIT PULL，它将使用PRODUCTION BRANCH中的内容更新服务器上的所有代码。如果文件被删除等，GIT PULL也将删除任何文件。在服务器上，您将获得GIT仓库的“签出”副本，并在Linux上存储第一个克隆后的凭据。只需让你的PHP文件触发一个执行GIT PULL的BASH脚本。完成。

无论您拥有多少开发人员，总是需要一组眼睛来审查代码更改并将这些更改合并到生产中。即这是Lead Developer发挥作用的地方。

仅供参考。你的wordpress实例中唯一需要在bitbucket中的目录是THEME DIRECTORY和PLUGINS目录。您不需要同步整个WP安装，这是非常大的。

如果您要构建自定义插件，那么它只是存储在plugins目录中的代码。如果您的自定义插件构建正确并需要使用数据库，那么当它们被激活时，它们将立即构建所需的WP DB。同样，正确构建的插件也会在卸载时删除自己的自定义表。

您需要同步以下2个目录。

插件文件夹位于：wp-content / plugins /

主题文件夹是wp-content / themes / SELECTED_THEME

任何其他问题只是问我在这里。

Answer 3

根据我的经验，最好让每个开发人员拥有自己的分支机构，并为开发服务器设置专用的主分支以进行质量控制。你可以查看一些关于如何设置https://plixxer.com/docs/server-management/website-quality-control/的文档

基本上你想拥有一个实时服务器和开发服务器。实时服务器应该只从REPO中拉出来，并且Dev和编码器可以从repo中拉出或推送。我的团队将开发服务器视为质量检查站。如果当前的实时代码不符合我们的标准，则整个开发人员将回滚到主分支上的实时代码。当主代码中的代码成功达到我们的标准时，我们将从主分支拉到实时服务器上。每个开发人员都应该拥有自己的分支，以便在本地服如果您需要一些关于使用GIT设置本地环境的帮助，请告诉我。

Answer 4

您将希望区分“构建”和另一个围绕“发布”。我理解的工作流程是开发人员将他们的本地工作站称为“dev”，并将他们的工作请求发送到开发分支（您可能已经通过Gitflow阅读）。然后，使用您选择的CI自动化，您可以将最新的源代码放入构建区域并执行此操作 - 构建它。看看Ansible。如果你有BitBucket，也许你也想和Jira一样组织你的冲刺？然后，您将sprint目标与包含相关工作/源的实际分支完美地集成在一起。 Ansible可以帮助您将构建和发布自动化到您每天构建的位置，并在各种集成环境中跨构建运行单元测试。

在构建期间，您将根据目标环境考虑不同的配置文件。这是如何关心环境配置。它是构建过程的一部分，理想情况下，所有配置都可以通过构建实现。例如，如果您使用不同的数据库来隔离架构更改的迁移，则整个环境中的连接字符串可能会有所不同。例如，在Angular应用程序中，您将执行ng b --prod来构建生产，这将在构建期间引入生产配置文件以更改连接字符串（例如）。

有关特定于环境的配置的更多信息...您还可以包括在上载文件后部署和执行的部署后脚本，以便他们根据需要配置环境。

在下面提出您的问题，我会尽力将其构建成一本综合指南。