README

元数据

根据项目发展，本文件应由您进行更新。添加您的作者信息以供历史参考和专业背景，如下所示：

首次编辑日期：姓名（邮箱）

作者

2020-01-10：Calvin（sleepingmonk）

项目信息

工作仓库：Github
托管：
CI/CD： -
后端：Drupal 8
前端：

内容

本地开发

注意： composer.json: extra: working-repo 用于防止开发者意外在工作复制的生产工件上工作。将其值设置为工作GitHub仓库URL。Composer将使用 git remote get-url origin 进行检查。

Docker：https://dockerd.com.cn/community-edition
Lando：https://docs.devwithlando.io

Lando/Docker是可选的，任何 *AMP 环境都可以，但这里有针对Lando的有用工具。

警告：使用Lando安装程序安装它首选的Docker版本。

安装后，转到项目目录并输入 lando 以获取命令列表。

启动本地环境

lando start - 启动环境。
lando db-import [数据库路径] - 导入您的数据库。将数据库存储在 data/ 目录中。
lando composer install - Composer安装。
lando tb - 构建主题资产。
lando reset - 运行 updb、cim、cr ...

Composer安装将 settings.local.php 和 services.local.yml 移动到 sites/default/ 目录，并具有功能配置。如果您愿意，可以替换或修改这些文件。如果它们存在，则不会替换。

准备开始工作。

数据库可以通过多种方式获取。我建议将其保存到 data/ 目录，该目录被忽略，并在环境中，因此可以保存以供将来重置和从中导入，而不会在项目根目录中混乱地保存数据库的不同版本。

选项

[env] = live 或最接近live的环境。

Drush别名
- lando drush @[proj].[env] sql-dump --gzip > data/[env]-YYYY-MM-DD.sql.gz

模块管理

从项目根目录

添加贡献模块

lando composer require drupal/[package_name] --no-update 将其添加到 composer.json 而不更新一切。
lando composer update drupal/[package_name] 仅获取/更新所需的模块。

更新核心

lando composer update drupal/core drupal/core-recommended --with-dependencies

更新贡献模块

lando composer update drupal/[package_name]

有时几个贡献模块落后几个版本。

不要使用未指定模块的lando composer update，否则它将一次性更新所有过时的内容，可能会引入回归，你需要进行更多的测试。

更新应该得到良好的控制和测试。在较小的块中操作最为简单。特别注意模块的BETA、ALPHA或DEV版本，这些版本不稳定，并且不能保证更新不会破坏现有功能。理想情况下，永远不要使用Alpha/Dev模块，并且谨慎使用Beta版本。考虑为项目做出贡献，以帮助其达到完整发布。

移除贡献模块

应该将启用的模块从代码库中删除两次。第一次发布更新应简单地卸载模块。第二次发布应按以下方式从代码库中删除模块。如果你一次性完成所有操作，Drupal将无法找到要卸载的模块代码，因为它将不再存在。

第一阶段：卸载模块

lando drush pmu [module] - 卸载模块。
lando drush cex - 导出由卸载模块引起的配置更改。
部署更改以更新生产站点。

第二阶段：删除模块

lando composer remove [package] --no-update 将从require或require-dev中删除包，而不会运行所有更新。
lando composer update [package] 将删除包代码。

应用补丁

如果需要应用补丁，可以使用composer-patches插件。

要将补丁添加到drupal模块foobar，在composer.json的extra部分插入patches部分

"extra": {
    "patches": {
        "drupal/foobar": {
            "Patch description": "Drupal URL to patch"
        }
    }
}

Git工作流程和代码部署

注意：在开始新的功能之前，始终将本地重置到与生产类似的状态。配置应从master导入，并且在开始工作之前，应导入生产数据库，以确保新功能中的配置更改在导出时是干净的。

此项目配置为使用多开发环境[并行Git工作流程 - 如果在Pantheon上托管，请参阅注释][parallelpdf]。

环境 -> Git分支

develop -> develop
stage -> stage
Live -> master

这样，master始终是干净的生产代码。

任何工作的新功能分支应从master分支，以便它从干净的状态开始。如果你从任何其他内容分支，你将携带与你的票据无关的代码，这可能会在代码被批准但其他代码不被批准时，在部署到生产时难以分离。你的分支将“污染”。保持清洁，以避免意外将拒绝的代码引入生产，并避免让需要精确部署项目代码的人感到沮丧。

feature/[ticket-id]--short-description

使用票据ID作为主要提交消息：PRJ-27：消息...

此存储库由repo管理，因此将您的功能推送那里，并向develop创建一个Pull Request。这将合并并部署到develop环境，以进行内部审查/质量保证。

如果通过审查，将干净的FEATURE分支合并到stage以部署到stage（多开发环境），以进行客户审查/批准。

如果批准部署到生产，将干净的FEATURE分支合并到master以部署到生产环境。

通过这种方式，单个特性可以在环境中移动，而不会影响或被其他正在进行中的工作所影响。任何环境中的问题都可以由于任何原因而停滞，而不会阻碍其他开发中问题的进度。热修复和安全更新可以顺利通过，无需担心是否可以部署可能已经放置了3个月的5个其他事物。

替代发布选项

单个特性/热修复：将单个批准的特性分支合并到主分支中，作为生产发布。
发布分支：当特性在stage上获得批准时，可以将它们合并到一个新的release-x.y.z分支中，这个分支是从干净的master分支中切出的。不要将任何未批准的特性分支合并到发布分支中。准备好后，通过将其合并到master分支中来部署release分支。
完成的阶段：如果您在确认合并到其中的所有特性都经过批准并签署后，可以将stage视为发布分支，然后将其合并到master中，以便将其作为发布部署。部署可能已进入stage但尚未签署发布代码存在一定风险，因此请小心行事。

测试和批准

一个受信任的独立开发者（solo dev）可以在开发级别进行批准，因此开发环境步骤可能不是必需的。如果您需要更详细的内部审查，请保留该步骤。只需记住，如果您不为每个特性使用它，阶段和Live将会落后，因此您需要首先将master合并到develop中，以便在develop中进行干净和简洁的拉取请求。

特性应始终由产品所有者在阶段上批准。请避免在阶段上进行内部审查，因为如果审查失败，阶段将受到一个尚未准备好的产品所有者审查的特性污染，这可能会让产品所有者或项目经理感到困惑。

尽管可以信任独立开发者无需批准即可部署特性或更新，但要求批准和签署建议以帮助发现我们可能存在盲点的错误，并保护我们从生产中的破坏中受到保护。

自动化测试

在CI build_test上执行PHP linting
在CI build_test上执行PHP Code Sniffer
可以添加其他自动化测试，并鼓励这样做

代码部署

将PR合并或向Repo（develop、stage、master）的任一环境分支上推送新提交，将触发CircleCI构建、测试并将更新的分支部署到相应的环境。

它是通过将工作仓库的生产代码同步到主机上的单独生产仓库来做到这一点的。

通过别名运行Drush，应执行如updb -y、cim -y、cr等部署后命令。确保您检查此命令是否失败，并在必要时手动运行。

此过程将工作代码与生产代码分开。

sleepingmonk / drupal-monk

维护者

详细信息