BLT

Repository architecture

Note

Acquia will end support for BLT on December 31, 2024. For more information on how to replace your BLT implementation with updated functionality, see You don’t need BLT on Acquia Cloud.

The repository architecture is based on the following set of core principles:

  • Project dependencies should never be committed directly to the repository.

  • The code that is deployed to production should be fully validated, tested, sanitized, and free of non-production tools.

  • Common project tasks should be fully automated and repeatable, independent of the environment.

Consequently, there are some aspects of a project’s architecture and workflow that may be unfamiliar to you:

  • Drupal core, contributed (contrib) modules, themes, and third-party libraries are not committed to the repository. Contrib module directories that are ignored with .gitignore are populated during build artifact generation.

  • The repository is never pushed directly to the cloud. Instead, changes to the repository on GitHub trigger tests to be run using Continuous integration. Changes that pass testing will cause a build artifact to be created and then deployed to the cloud.

  • Common project tasks are executed using a build tool (such as Robo) allowing them to execute exactly the same in all circumstances.

Directory structure

The following is an overview of the purpose of each top level directory in the project template:

root
  ├── blt      - Contains custom build config files for CI solutions
  ├── box      - Contains DrupalVM Configuration (optional, created by
  |              `blt vm`)
  ├── config   - Contains Drupal configuration files
  ├── drush    - Contain drush configuration that is not site or
  |              environment specific
  ├── docroot  - The Drupal docroot
  ├── hooks    - Contains Cloud Platform hooks (optional, created by
  |              `blt recipes:cloud-hooks:init`)
  ├── patches  - Contains private patches to be used by composer.json
  ├── reports  - Contains output of automated tests; is .gitignored
  ├── tests    - Contains project-level test files and configuration
  ├── vendor   - Contains built composer dependencies; is .gitignored

Dependency management

All project and Drupal (including module, themes, and libraries) dependencies are managed using Composer. This management strategy is based on the Drupal Project.

You can add modules, themes, and other contributed Drupal projects as dependencies in the root composer.json file.

For step-by-step instructions about how to update dependencies, see Project tasks.