Repository architecture¶

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.

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