Decision The main branch of a project should always be ready to deploy to production

accepted

Even with the best planning, unexpected bugs and security issues can require a fast deployment to production. By ensuring the main branch is always deployable, we minimize additional development work and QA in the case of an unplanned deployment.

Decision

The main branch in a git repository will always be ready to deploy to production for sites that have launched. We will not use long-lived branches such as a dev or sprint branch as the day-to-day target for code changes.

Consequences

Teams will be confident in knowing that a main branch is ready to deploy if an unplanned deployment is required, such as a critical but out of schedule Drupal security release.

Unplanned deployments will be faster to complete, because only the specific new changes will need to be tested, and not a backlog of untested work.

Testing will need to occur primarily on pull requests, and not on a single qa branch or environment. Pull request preview platforms like Tugboat will need to be configured for projects. This will ensure that main is tested and ready to deploy.

Some hosting platforms, like Pantheon, enforce a strict dev / test / prod workflow. For those platforms, we may need to work outside their default workflows. For example, with Pantheon teams may need to deploy main to a multidev environment so only tags from main are deployed to dev, test, and production. This also allows development teams to continue to commit to main during deployment windows, increasing effeciency.