Skip to main content
Version: v1

Development

This section is for developers who build features and fix bugs on a project created from Vortex. It covers the day-to-day work in 4 areas:

  • Running the local environment
  • Managing the database and the dependencies
  • Working with the Drupal application
  • Checking your code with linters and tests

Most pages cover 1 task or tool: its daily usage, its configuration and how it runs in the continuous integration pipeline. A bigger topic gets a subsection with an overview page of its own. Use this page to follow the overall process and find the page for each task.

To set up the pipeline, the deployments or the hosting, see Continuous integration, Deployment and Hosting.

Typical development process​

A change usually goes through these steps:

  1. Pull the latest changes from the remote repository.
  2. Fetch the latest database dump from the production environment.
  3. Build the project.
  4. Start a new feature or bugfix branch:
    1. Create a new branch from develop (see Releasing > GitFlow for the branch structure).
    2. Implement the feature or fix the bug.
  5. Run tests:
    1. Run automated tests locally.
    2. Fix any failing tests.
  6. Run code quality checks:
    1. Run static code analysis locally.
    2. Fix any issues reported.
  7. Commit your changes to the branch.
  8. Push the branch to the remote repository.
  9. Create a pull request:
    1. Create a pull request from the branch to develop.
    2. Assign reviewers.
    3. Wait for the continuous integration pipeline to pass.

Common commands​

Each video in this section is a live recording of a demo project built from Vortex.

Build the project​

ahoy build rebuilds the project from scratch. After you confirm, it runs these steps in order:

  1. Removes the containers, the installed dependencies and the database.
  2. Builds and starts fresh containers.
  3. Installs the Composer and front-end dependencies.
  4. Compiles the custom theme's assets, when the project has a custom theme.
  5. Provisions the site.
  6. Prints the project information with a one-time login link.

Show project information​

ahoy info prints what you need to reach the running project:

  • The project name and the Docker Compose project name
  • The site URL and the path to the web root
  • The database host, username, password and port
  • The database port on your host
  • The database image, when VORTEX_DB_IMAGE is set
  • The Solr and Storybook addresses, when their ports are mapped on your host
  • The Selenium VNC address, where you can watch the browser tests run
  • The mail catcher address
  • Whether Xdebug is on

To print a one-time login link too, pass any argument, such as ahoy info login. Without an argument, the output ends with a reminder to run ahoy login, which unblocks user 1 and prints a one-time login link.

Run linters​

ahoy lint runs 3 groups of linters. Each group also has a command of its own:

  • ahoy lint-be: the backend linters PHPCS, PHPStan and Rector
  • ahoy lint-fe: the frontend linters Twig CS Fixer, ESLint and Stylelint
  • ahoy lint-tests: Gherkin Lint for the Behat feature files

ahoy lint-fix applies the automatic fixes of Rector, PHPCBF (the PHPCS fixer), Twig CS Fixer, ESLint and Stylelint.

SDC Devel validates the custom theme's components against a provisioned site, so it runs separately as ahoy lint-sdc. Continuous integration runs DCLint and Hadolint from their Docker images, so neither has an Ahoy command.

Run unit, kernel and functional tests​

ahoy test runs every PHPUnit suite: unit, kernel, functional and functional JavaScript. To run 1 suite, use its own command:

  • ahoy test-unit
  • ahoy test-kernel
  • ahoy test-functional
  • ahoy test-functional-javascript

The Jest tests for JavaScript run separately, with ahoy test-js.

Run BDD tests​

ahoy test-bdd runs the Behat tests against the provisioned site. Scenarios tagged @javascript drive a real browser in the chrome container. All other scenarios send HTTP requests from PHP.

Re-provision the site​

After you confirm, ahoy provision runs provisioning again in the running stack. The database it starts from depends on the project:

  • With VORTEX_PROVISION_OVERRIDE_DB set to 1, the command replaces the current database with the dump from .data/db.sql.
  • With VORTEX_PROVISION_OVERRIDE_DB set to 0, the command imports the dump only when no site is installed yet.
  • With the database in a container image (VORTEX_DB_IMAGE), the command starts a fresh database container from that image, whatever VORTEX_PROVISION_OVERRIDE_DB says.

.env sets VORTEX_PROVISION_OVERRIDE_DB to 0. .env.local.example sets it to 1 for local work, after you copy that file to .env.local.

The provisioning steps run next, from the database updates and the configuration import to the deploy hooks and your custom scripts/provision-*.sh scripts. The command finishes with a one-time login link.

Beyond local development​

Expand to see the complete code lifecycle
Local Development
═════════════════════════════════════════════════════════════════════════════════════════
Developer writes code ──► Build and test locally ──► Commit changes
│
▼
Git Repository
═════════════════════════════════════════════════════════════════════════════════════════
Push to remote branch ──► Open/Update Pull Request
│
▼
┌─ CI Pipeline ────────────────────────────────────────────────────────────────────────────┐
│ │
│ ┌─ Database Job (Nightly) ───────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Scheduled ──► Download production ──► Import and export ──► Store database cache │ │
│ │ trigger database to validate the dump │ │
│ │ │ │
│ └─────────────────────────────────────┬──────────────────────────────────────────────┘ │
│ │ Provides cached database │
│ ▼ │
│ ┌─ Lint Job ────────────┐ ┌─ Database Job ────────────────┐ ┌─ Audit Job ──────────┐ │
│ │ │ │ ◆ Nightly cache exists? │ │ Composer audit │ │
│ │ Composer validate │ │ Yes ──► job succeeds │ │ (advisories) │ │
│ │ ▼ │ │ No ──► download, validate, │ │ ▼ │ │
│ │ Hadolint │ │ store cache │ │ npm audit │ │
│ │ ▼ │ └───────────────┬───────────────┘ │ (advisories) │ │
│ │ DCLint │ ▼ │ ▼ │ │
│ │ ▼ │ ┌─ Build Job ───────────────────┐ │ Gitleaks │ │
│ │ Build CLI container │ │ Code assembly │ │ (committed secrets) │ │
│ │ ▼ │ │ Docker, Composer deps, │ │ │ │
│ │ Composer normalize │ │ NPM deps, assets │ │ │ │
│ │ ▼ │ │ ▼ │ │ │ │
│ │ PHPCS │ │ Website setup │ │ │ │
│ │ ▼ │ │ Import cached DB, drush │ │ │ │
│ │ PHPStan │ │ deploy, custom scripts │ │ │ │
│ │ ▼ │ │ ▼ │ │ │ │
│ │ Rector │ │ Testing │ │ │ │
│ │ ▼ │ │ Jest ──► PHPUnit ──► Behat │ │ │ │
│ │ Twig CS Fixer │ └───────────────┬───────────────┘ │ │ │
│ │ ▼ │ │ │ │ │
│ │ Gherkin Lint │ │ │ │ │
│ │ ▼ │ │ │ │ │
│ │ ESLint / Stylelint │ │ │ │ │
│ │ │ │ │ │ │
│ └──────────┬────────────┘ │ │ │ │
│ │ │ │ │ │
│ ▼ ▼ │ │ │
│ ┌─ Deployment Job ─────────────────────────────────────────┐ │ │ │
│ │ │ │ │ │
│ │ Webhook Artifact Lagoon │ │ Does not gate │ │
│ │ Call URL Package artifact Run Lagoon CLI deploy │ │ deployment │ │
│ │ │ │ │ │
│ └──────────────────────────────────────────────────────────┘ └──────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────────────────────────┘
│
▼
Hosting Platform
═════════════════════════════════════════════════════════════════════════════════════════
◆ Environment ──No──► Sync DB from production ───┐
exists? │
│ Yes ▼
└──────────────────────────────────► drush deploy ──► Custom scripts ──► Notifications


Available Environments
═════════════════════════════════════════════════════════════════════════════════════════
┊ PR Environment ┊ Dev Staging Production
┊ (auto-removed) ┊ develop branch main branch production branch or tag

In this section​

The following table lists the pages in this section:

PageDescription
EnvironmentThe container stack, Ahoy, Drush, Doctor, Pygmy, debugging, logs and troubleshooting
ComposerManaging packages, patching, security auditing and the shipped composer.json
ProvisionFetching and importing databases, the provisioning flow and deploy hooks
SettingsEnvironment type detection and per-module settings overrides
ModulesEvery shipped module, the module scaffold, Drupal helpers, generated content and Testmode
ThemesThe theme scaffold and its build system
MigrationsThe optional second database powering Drupal migrations
Code qualityThe linters and how to run them
TestingPHPUnit, Behat and Jest
SecuritySecret scanning, dependency auditing and environment access
Visual regressionDiffy-powered visual regression on deployments
Dependency updatesAutomated dependency updates with Renovate
AIThe AI agent configuration files
FAQsAnswers to common operational questions
VariablesThe full environment variable reference

Tools​

The following table lists the tools that Vortex ships and the page that documents each one:

ToolDocumented in
AhoyEnvironment > Ahoy
audit-ciSecurity > Dependency audit
BehatTesting > Behat
ComposerComposer
DCLintCode quality > DCLint
DiffyVisual regression > Diffy
DockerEnvironment > Docker
DoctorEnvironment > Doctor
DrushEnvironment > Drush
ESLintCode quality > ESLint
Gherkin LintCode quality > Gherkin Lint
Git artifactDeployment > Artifact > Git artifact tool
GitleaksSecurity > Secret scanning
HadolintCode quality > Hadolint
JestTesting > Jest
PHPCSCode quality > PHPCS
PHPStanCode quality > PHPStan
PHPUnitTesting > PHPUnit
PygmyEnvironment > Pygmy
RectorCode quality > Rector
RenovateDependency updates
SDC DevelCode quality > SDC Devel
StorybookThemes > Storybook
StylelintCode quality > Stylelint
Twig CS FixerCode quality > Twig CS Fixer
XdebugEnvironment > Debugging