-
Run installer:
curl -L https://raw.githubusercontent.com/drevops/drevops/8.x/install.php > /tmp/install.php && php /tmp/install.php --interactive; rm /tmp/install.php -
Commit added files.
-
Follow instructions in the generated
README.mdfiles of your project.
DrevOps is a Drupal project scaffolding template with included development environment, CI configuration and tools. It can be used on new or existing projects as is or can be customized as required. It may also be used as a reference for custom configurations.
DrevOps is designed to support updating of the code templates it provides. This makes it easy to keep projects using DrevOps up-to-date with the latest scaffolding code.
DrevOps supports both database-driven development and fresh install for every build. Database-driven development is when the existing production database is used for every build (useful for product development), while fresh install is when the site is installed from the scratch during every build (useful for module or profile development).
DrevOps has own automated tests that guarantees stability and ease of maintenance.
Expand for more non-technical information
Increase the quality of the produced Drupal websites with minimum setup effort and knowledge.
High quality Drupal websites are stable, secure, faster and safer to change.
But developers do not always have the time or skills to setup the tools required to produce and maintain high-quality Drupal websites.
Quick install of best practices Drupal configuration on Docker stack using a single command lowers entry barrier, while unification of the developer's experience improves development speed across projects.
- Digital agencies that want to standardise their development stack (standard operating environment) across projects
- Developers that are looking for best practices
- Developers that do not possess required time or knowledge to setup these tools themselves
- You run installer script once
- DrevOps brings the latest release into your codebase
- You commit all new files
- If required, you may override files with changes relevant only to a specific project.
Since DrevOps is a template, it can be forked and adjusted to your needs. The installer script will continue to work with your fork, provided that you adjust several environment variables.
In other words - you will have your own development templates for your own projects the way you want it!
Run ahoy update to download the latest version of DrevOps for your project.
Show update process screenshot
- Highly configurable
All configuration is made through environment variables without the need to change any of the scripts. - Flexible
Anything can be overridden for your specific project and will not be lost during the next update. - Pure Docker stack
No special binaries to work with Docker. No generated Docker Compose configurations from custom configurations. Modify configuration to fit your project needs. - Tested
There are tests for workflows, configuration, deployments, CI. Everything. And they run automatically on every commit. - Versioned
It is always clear which version of the stack your site uses. - Upgradable
Your website can be updated to a newer version of DrevOps with minimal effort. Your project customisations are easily preserved. - Documented
The major areas of DrevOps are explicitly documented, while most of the code is self-documented.
- Drupal
- Local development environment
- Code linting
- Testing
- Automated builds (CI)
- Deployment
- Documentation
- Integrations
- Maintenance
More details
| Area | Feature | Why it is important |
|---|---|---|
| Drupal | ||
| Versions | Drupal 7 support | Drupal 7 is still widely used |
| Drupal 8 support | Drupal 8 is current version | |
| Separate branches for each Drupal version | Handling both Drupal versions in the same repository allows to easily re-use some commits across branches. | |
| Composer-based configuration | Pure composer configuration | Website is assembled using industry-standard tools such as Composer |
| Uses drupal-scaffold | Industry-standard composer package to scaffold some of Drupal files | |
| Scripts to create required settings and files with environment variables support | Required files and directories created automatically.Environment variables override support allows to provide override values without the need to change scripts. Useful for per-environment overrides. | |
| Settings file with multi-environment support | Per-environment variables allow to easily target specific settings to specific environments without too much mess | |
| Best-practices development modules | Having the same development modules on each website helps to reduce development time. | |
| Custom module scaffolding | Mechanism to organise contributed module-related hook implementations into standalone files | Helps avoid large files with all hook implementation, which leads to a simple maintenance. |
| Custom theme scaffolding | ||
| Grunt + SASS/SCSS + globbing + Livereload | Grunt configuration defines multiple build steps to work with frontend in Drupal. Livereload allows to automatically refresh the page once there are changes to styles or scripts. |
|
| Patches management | Based on composer-patches | Support for custom (per-project) and contributed patches is simply essential for any project. |
| Local development environment | ||
| Docker | Using stable Amazee images | Amazee images are stable - they are covered by tests and are used in many production environments. |
| Pure Docker configuration | Pure Docker configuration allows anyone with Docker knowledge to alter configuration as required. | |
| Custom application support | As a result of using Docker, it is possible to install any application, provided that it can be ran in container | |
| Multi-application support | As a result of using Docker, it is possible to have multiple applications (not only Drupal) in one stack. For example, decoupled Drupal and Frontend VueJS application. | |
| Using Pygmy | Adds support for additional Docker tools as well as Mailhog (to test emails) | |
| Unified Development Experience (DX) | Ahoy commands to abstract complex tasks into set of workflow commands | To improve development speed and unify development tasks across projects |
| Single command project build | Project must be built in the same way on any environment and a single command always guarantees that it will be done in the same predictable way.Improve development speed and easy maintenance. | |
| Database sanitization support | Remove all personal data from the database before working on it. | |
| Configuration | Configuration provided through a (file)[.env] with reasonable defaults | To cover majority of the project without the need to change any scripts |
| Code linting | ||
| PHP | Drupal PHP coding standards | To increase code quality and lower technical debt |
| PHP Version compatibility | To avoid language constructs that may not be supported by a certain version of the language | |
| JavaScript | Drupal JS coding standards | To increase code quality and lower technical debt |
| SASS/SCSS | To increase code quality and lower technical debt | |
| Testing | ||
| PHPUnit* | Configuration + examples | Enables unit-testing capability to improve code quality and stability |
| Behat | Configuration + examples | Enables integration-testing capability using fast tests to improve code quality and stability |
| Browser testing | Enables integration-testing capability with JavaScript support to improve code quality and stability | |
| Automated builds | ||
| CI template | Build + Test + Deploy | Standard workflow for automated builds |
| Conditional Deploy | Supports conditional deployments based on tags and branches to allow selective deployments | |
| Parallel builds to speedup pipeline | Running jobs in parallel may significantly lower the build time for large projects | |
| Cached database support | Reduce build times by using daily cached database | |
| Identical environment as local and production | While running on a 3rd party provider, CI uses hosting stack identical to the local and production in order to identify any problems at early stages.CI also acts as a 'shadow' developer by running exactly the same commands as what a developer would run locally. | |
| Documentation | ||
| Readme files | Generic project information | Helps to find relevant project information in one place |
| Local environment setup | Helps to lower project onboarding time | |
| List of available commands | Helps to lower project onboarding time | |
| Build badges | Shows current build status | |
| FAQs | Helps to lower project onboarding time | |
| Deployment information | Helps to find relevant deployment information in one place | |
| Onboarding checklist | Onboarding checklist | Helps to track the progress of onboarding to DrevOps |
| GitHub management | Pull request template | Helps to improve team collaboration and reduce the time for pull request management |
| Pre-defined issue and pull request labels* | Helps to improve team collaboration and reduce the time for pull request management | |
| Integrations and deployments | ||
| Acquia | Production database from Acquia | Using production database for development and automated builds (CI) requires database dump from Acquia |
| Deploy code to Acquia | Deploying to Acquia requires packaging Composer-based project into artifact before pushing | |
| Deployment hooks | Standardised deployment hooks guarantee that every deployment is reproducible | |
| Lagoon | Deployment configuration | Lagoon configuration is required to perform deployments |
| Production database from Lagoon | Using production database for development and automated builds (CI) requires database dump from Lagoon | |
| dependencies.io | Automated pull request submissions for automated updates. | Automated dependencies updates allow to keep the project up to date by automatically creating pull requests with updated dependencies on a daily basis |
| Maintenance (of DrevOps) | ||
| Install and upgrade | Follows SemVer model for releases | Projects may refer to a specific version of DrevOps, which sets expectations about what tools and configuration is available |
| Managed as an agile project | New features and defects can be addressed in a shorter development cycle.GitHub issues organised on the Kanban board provide clear visibility for future releases | |
| One-liner install script with optional wizard | Minimises the time to try DrevOps.Provides centralised point for installation into new and existing projects, as well as updates. | |
| Stability | Test suite for all provided commands | Guarantees that commands will work |
| Own CI to run test suite | Pull requests and releases are stable | |
| Daily Drupal and NPM updates | Composer (including Drupal) and NPM packages are always using the latest versions. | |
| Documentation | Contribution guide* | Engages community to contribute back |
| Pull request template | Helps to improve community collaboration and reduce the time for pull request management. |
* Denotes features planned for 1.7 release
- Progress is tracked as GitHub project.
- Development takes place in 2 independent branches named after Drupal core version:
7.xor8.x. - Create an issue and prefix title with Drupal core version:
[8.x] Updated readme file.. - Create PRs with branches prefixed with Drupal core version:
7.xor8.x. For example,feature/8.x-updated-readme.
- Fetch as much of development configuration as possible from DrevOps repository
Allows to keep your project up-to-date with DrevOps - Avoid adding things to the wrong places
Example: Using Composer scripts for workflow commands. Instead, use tools specifically designed for this, like Ahoy - Abstract similar functionality into steps
Allows to apply changes at the larger scale without the need to modify each project - Run the most of the code in the containers
Reduces the number of required tools on the host machine
Integrated Experts provides paid support for DrevOps:
- New and existing project onboarding.
- Support plans with SLAs.
- Priority feature implementation.
- Updates to the latest version of the platform.
- DevOps consulting and custom implementations.
Contact us at [email protected]
- Drupal module testing in CircleCI
- MariaDB Docker image with enclosed data - Docker image to capture database data as a Docker layer.
- CI Builder Docker image - Docker image for CI builder container with many pre-installed tools.
- Behat Steps - Collection of Behat step definitions.
- Behat Screenshot - Behat extension and a step definition to create HTML and image screenshots on demand or test fail.
- Behat Progress Fail - Behat output formatter to show progress as TAP and fails inline.
- Behat Relativity - Behat context for relative elements testing.
- Code Artifact Builder - Robo task to push git artifact to remote repository.
- GitHub Labels - create labels on GitHub in bulk.
- Formatted git messages - pre-commit git hook to check that commit messages formatted correctly.
Below is a content of the README.md file that will be added to your project.
All content above this line will be automatically removed during installation.
Drupal 8 implementation of YOURSITE for YOURORG
Use Onboarding checklist to track the project onboarding progress.
- Make sure that you have latest versions of all required software installed:
- Make sure that all local web development services are shut down (Apache/Nginx, Mysql, MAMP etc).
- Checkout project repository (in one of the supported Docker directories).
- Authenticate with Acquia Cloud API
- Create your Acquia Cloud API token: Acquia Cloud UI -> Account -> API tokens -> Create Token
- Populate
$AC_API_KEYand$AC_API_SECRETenvironment variables in.env.localfile with values generated in the step above.
ahoy download-db
pygmy upahoy build
Run each command as ahoy <command>.
build Build or rebuild the project.
clean Remove containers and all build files.
cli Start a shell or run a command inside the CLI service container.
debug Enable debug configuration.
deploy Run remote deployment procedures
doctor Find problems with current project setup.
down Stop Docker containers and remove container, images, volumes and networks.
download-db Download database.
drush Run drush commands in the CLI service container.
export-db Export database dump or database image (DATABASE_IMAGE variable must be set).
fe Build front-end assets.
fed Build front-end assets for development.
few Watch front-end assets during development.
flush-redis Flush Redis cache.
info Show information about this project.
install-site Install a site.
lint Lint back-end and front-end code.
lint-be Lint back-end code.
lint-fe Lint front-end code.
login Login to a website.
logs Show Docker logs for all or specified services.
pull Pull latest docker images.
pull-db Download database image with the latest nightly dump. Run "ahoy reload-db" to reload DB in the running stack.
reload-db Reload the database container using local database image.
reset Reset environment: remove containers, all build, uncommitted files.
restart Restart all or specified stopped and running Docker containers.
start Start all or specified existing Docker containers.
stop Stop all or specified running Docker containers.
test Run all tests.
test-bdd Run BDD tests.
test-unit Run Simpletest unit tests.
up Build and start all or specified Docker containers.
update Update development stack.
Development stack needs to be downloaded for each environment, but some files may be committed to the project repository. Update process brings new versions of development stack files and may overwrite some of them. The changes in these files need to be reviewed and selectively committed.
- Start a new branch to make sure that your changes do not affect the main branch
- Run
ahoy updateto download the latest version of the development stack - Review and commit changes
- Make sure that your CI build passes with updated development stack configuration
- Merge your changes to the main branch
composer require drupal/module_name
- Add
titleandurlto patch on https://drupal.org to thepatchesarray inextrasection incomposer.json.
"extra": {
"patches": {
"drupal/core": {
"Contextual links should not be added inside another link - https://www.drupal.org/node/2898875": "https://www.drupal.org/files/issues/contextual_links_should-2898875-3.patch"
}
}
}
composer update --lock
ahoy fe- build SCSS and JS assets.ahoy fed- build SCSS and JS assets for development.ahoy few- watch asset changes and reload the browser (using Livereload). To enable Livereload integration with Drupal, add tosettings.phpfile (already added tosettings.local.php):$settings['livereload'] = TRUE;
PHP and JS code linting uses PHP_CodeSniffer with Drupal rules from Coder module and additional local overrides in phpcs.xml and .eslintrc.json.
SASS and SCSS code linting use Sass Lint with additional local overrides in .sass-lint.yml.
Set ALLOW_LINT_FAIL_BE=1 in .env to allow back-end code lint failures.
Set ALLOW_LINT_FAIL_FE=1 in .env to allow front-end code lint failures.
Behat configuration uses multiple extensions:
- Drupal Behat Extension - Drupal integration layer. Allows to work with Drupal API from within step definitions.
- Behat Screenshot Extension - Behat extension and a step definition to create HTML and image screenshots on demand or test fail.
- Behat Progress Fail Output Extension - Behat output formatter to show progress as TAP and fail messages inline. Useful to get feedback about failed tests while continuing test run.
FeatureContext- Site-specific context with custom step definitions.
Add @skipped tag to failing tests if you would like to skip them.
In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day. Before feature changes can be merged into a shared mainline, a complete build must run and pass all tests on CI server.
This project uses Circle CI as a CI server: it imports production backups into fully built codebase and runs code linting and tests. When tests pass, a deployment process is triggered for nominated branches (usually, master and develop).
Add [skip ci] to the commit subject to skip CI build. Useful for documentation changes.
Circle CI supports shell access to the build for 120 minutes after the build is finished when the build is started with SSH support. Use "Rerun job with SSH" button in Circle CI UI to start build with SSH support.
Circle CI supports caching between builds. The cache takes care of saving the state of your dependencies between builds, therefore making the builds run faster.
Each branch of your project will have a separate cache. If it is the very first build for a branch, the cache from the default branch on GitHub (normally master) will be used. If there is no cache for master, the cache from other branches will be used.
If the build has inconsistent results (build fails in CI but passes locally), try to re-running the build without cache by clicking 'Rebuild without cache' button.
Test artifacts (screenshots etc.) are available under "Artifacts" tab in Circle CI UI.
Please refer to DEPLOYMENT.md
dependencies.io integration allows to keep the project up to date by automatically creating pull requests with updated dependencies on a daily basis.
Please refer to FAQs