如何在Acquia Cloud上移除Drupal站点的BLT依赖（支持终止前）

1. Acquia Cloud上移除BLT的成功案例 #

肯定有大量成功案例。不少企业级Drupal项目（涵盖媒体、电商、政务类）已经完成BLT依赖移除，尤其是原本依赖BLT做标准化部署、测试流水线的团队，迁移后普遍反馈减少了额外依赖的维护成本，同时部署流程更贴合Acquia原生工具链的特性。

2. 移除BLT的解决方案、实施步骤及最佳实践 #

核心实施步骤 #

（1）梳理BLT核心功能依赖

先逐个清点当前项目用BLT实现的核心操作：比如部署钩子执行、前端资产编译、配置导入导出、自动化测试触发等，明确每个功能对应的替代方案。

（2）替换BLT核心功能

• 部署流水线：用Acquia Cloud原生的部署钩子（post-code-deploy、post-db-copy等）替代BLT的部署命令，把BLT里的部署逻辑拆分为独立脚本，放到项目的hooks/acquia目录下。
• 前端资产编译：将BLT集成的前端编译命令（如npm/yarn脚本）直接迁移到composer.json的scripts字段，或者放到Acquia构建阶段的自定义脚本中。
• 配置管理：用Drupal原生的drush config:import/drush config:export命令替代BLT的配置操作，将配置导入逻辑加入到部署钩子脚本里。
• 自动化测试：把BLT集成的PHPUnit、Behat测试，改为通过composer脚本或Acquia CI/CD流水线直接触发执行。

（3）移除BLT依赖

• 执行composer remove acquia/blt移除包依赖，同时删除项目中的BLT配置文件（blt.yml、blt.local.yml等）及相关目录（blt/、tests/blt/）。

（4）分环境验证

• 本地环境：测试前端编译、配置导入、站点运行等核心流程，确保功能正常。
• Acquia开发环境：推送修改后测试部署流水线，验证所有钩子脚本和自定义命令执行无误。

最佳实践 #

• 分步迁移：不要一次性移除所有BLT依赖，先替换单个功能（比如部署钩子），验证没问题再推进下一项，降低风险。
• 保留有用逻辑：把BLT中符合项目需求的脚本逻辑（如特定配置处理、缓存清除流程）提取出来，放到自定义shell脚本或composer脚本中，避免重复造轮子。
• 贴合Acquia原生工具：优先使用Acquia Cloud IDE、原生CI/CD流水线替代BLT的开发部署工具，适配云端环境特性。
• 版本控制回溯：每一步修改都提交到Git，出现问题时可快速回滚定位。

3. 部署流水线未执行的排查方案 #

按照官方指引操作后流水线未触发，可按以下步骤排查：

• 检查钩子目录与权限：确保自定义钩子脚本放在hooks/acquia目录下，且文件具备执行权限（运行chmod +x 脚本文件名），Acquia仅识别该目录下的钩子脚本。
• 确认Git推送状态：修改后的钩子脚本、composer配置必须已提交并推送到Acquia关联的代码仓库，Acquia部署仅由Git推送触发。
• 查看部署日志：在Acquia Cloud控制台的「部署历史」中查看详细日志，定位是否存在脚本找不到、权限不足、命令执行失败等具体报错。
• 验证composer脚本配置：如果用composer脚本替代BLT命令，确认composer.json的scripts字段配置正确，比如deploy类脚本可在本地正常执行。
• 手动测试钩子脚本：SSH连接到Acquia开发环境，手动执行钩子脚本（如./hooks/acquia/post-code-deploy），查看输出判断是否存在逻辑错误。

内容的提问来源于stack exchange，提问作者Ram Sharma