Do you know how changes reach your website?
Websites change all the time. A security update comes out, or someone needs a new field on a form. Each change travels from a developer's computer to your live site, and on many websites only 1 person knows the steps, or they live in a checklist that has grown over the years. That's normal, and it works until that person is on leave, or 2 changes need to go out on the same afternoon.
It starts to matter as more people rely on the site. Your team publishes to it every day. Drupal security updates are best applied within days, sometimes within hours. Several developers work on the code, or a new team is about to take it over. Or someone in your organisation asks how changes are tested before they go live.
A CI/CD pipeline gives every change the same tested path to your live site, so each release follows the same steps whoever runs it, and you can see what was checked along the way. Every website we build gets one from the first commit, and we can bring an existing website onto one when we take over its support.
How we build and run your pipeline
CI/CD stands for continuous integration and continuous deployment: every change is built and tested automatically, then deployed the same way every time. Ours starts from Vortex(Opens in a new tab/window), the open-source Drupal project template we've maintained for more than 8 years, which ships the pipeline ready for GitHub Actions or CircleCI.
1. We set your site up on Vortex
On a new website, Vortex is there from the first commit. On an existing one, we bring your code onto it. Either way, your site gets a local development environment in Docker, the pipeline and a connection to your hosting.
2. We check every change before it merges
Each change arrives as a pull request, a proposed change your developers can review, and the pipeline runs on it automatically. The results appear on the pull request, and a change deploys only after its build and code checks pass.
| Check | What it does |
|---|---|
| Code checks | Drupal coding standards and static analysis for PHP, Twig, JavaScript and CSS, plus the Docker files your site runs in |
| Build | Builds the whole site in Docker, usually from a nightly copy of its database, and runs the update steps a deployment would |
| Tests | Runs the PHPUnit(Opens in a new tab/window) and Behat(Opens in a new tab/window) tests. Code coverage below the threshold, 90% by default, fails the build, and on GitHub Actions the results appear on the pull request |
| Security audit | Checks your PHP packages against published security advisories and scans for committed passwords and keys, as a separate check |
| Visual regression | On the pull requests you label, Diffy compares the changed pages with your live site and reports the differences |
The 2 kinds of test cover different ground. PHPUnit, the standard testing framework for PHP, checks your custom code piece by piece. Behat tests the site the way people use it, with scenarios written in plain English that visit pages, fill in forms and check the result. Here's a small Behat feature the pipeline can run on every pull request, confirming the homepage loads and editors can still reach their content:
Feature: Smoke test
As a site owner
I want the key pages checked on every change
So that each release is checked before it goes live
Scenario: The homepage loads for visitors
Given I am an anonymous user
When I visit "/"
Then the response status code should be 200
Scenario: Editors can reach their content
Given I am logged in as a user with the role "editor"
When I visit "/admin/content"
Then the response status code should be 200
And I should see "Content"3. We release the same way every time
Once a change merges, the pipeline deploys it to your development environment. Each release gets its own build and deployment for final testing, and it reaches your live site only when someone decides it should. On Lagoon, a production deployment backs up the database first, and a pull request can get its own temporary environment for review. You can limit those to the pull requests you label. When a deployment finishes, your team hears about it by email, Slack, Jira, GitHub or New Relic.
4. We keep it running
Drupal, PHP and the tools a pipeline uses keep moving, so a pipeline needs looking after. Renovate opens pull requests for dependency updates on a schedule, and the pipeline tests each one like any other change. The CI image and every third-party GitHub Action are pinned to exact versions, so their updates arrive as pull requests too. We bring Vortex updates into the sites we support as part of regular maintenance, and when something in the pipeline breaks, we fix it.
What you get
Everything we set up lives in your site's code repository, so it stays with the site.
The pipeline
The GitHub Actions or CircleCI configuration runs the checks, tests and deployments described above. Any developer who works on your site later, ours or anyone else's, can read it and change it.
A local environment that matches it
Your developers get Docker containers and a short set of commands for their own machines. The same setup script runs locally, in the pipeline and on your hosting, so a change behaves the same way in all 3. Our containerisation page has more.
A test suite that grows with the site
PHPUnit and Behat are set up from the start, with Behat Steps, our open-source library of ready-made test steps, already wired in. New features we build come with tests, and our automated testing page explains how we write them.
Documentation
The Vortex documentation covers each part of the pipeline, and your project gets its own, including how your releases run.
Where we've done this
- Vortex is open source, so its whole pipeline is public. Recent releases added a security audit that runs separately from the build (Vortex 1.41.0, Lumen), and deployments that wait for a pull request label (Vortex 1.40.0, Spectrum).
- Our own website runs on Vortex, with its code and pipeline public on GitHub. Behind www.drevops.com has the details.
- From 2018 to 2020, we contributed to the GovCMS Drupal 7 and SaaS project scaffolds and their CI, the starting templates that set how GovCMS sites are built, tested and deployed.
- In 2018 and 2019, a state government's whole-of-government content platform ran its CI on our CI image and its tests on 3 of our Behat libraries. That image, now called ci-runner, runs every job in the Vortex pipeline today.
- For a dual-sector Australian university's vocational-brand website, we measured where its test suite spent its time before changing anything. Most of the time went on page weight, such as tag manager scripts loading in every browser test, and after a handful of changes those pages loaded about 3 times faster once cached.
What it costs
The pipeline comes with the websites we build and support, so it's priced as part of that work.
| A new website | An existing website | Ongoing support | |
|---|---|---|---|
| What we do | Set up Vortex and the pipeline with the first commit | Bring your code onto Vortex and connect the pipeline to your hosting | Keep the pipeline current, bring in Vortex updates and fix what breaks |
| How it's priced | Part of the fixed-price quote for your build | Estimated up front for your site | Part of your support plan |
For work we quote, we send you an estimate before anything starts, or a fixed-price quote for a defined scope. A fixed-price quote is the price, and nothing starts until you've approved the scope and cost.
Ongoing care runs on a support plan, and our support plans page sets out the blocks, response times and rates. Our managed hosting, which the pipeline deploys to directly, starts at $250 per site per month plus GST.
Where the pipeline fits
The pipeline runs the tests from our automated testing work in the same containers your developers use, and deploys to our managed hosting. It makes a Drupal upgrade safer, because every step of the upgrade is built and tested before it reaches your live site. Once it's running, a support plan keeps it current.
FAQs
Do we need automated tests before you set up a pipeline?
No. On a website we build, tests arrive with the first feature. On an existing website, the pipeline still builds, checks and deploys the code that's there, and we add tests as we work on the site. A check that fails on day one can report its findings without holding up releases while we work through them.
Can we control when changes go live?
Yes. Code reaches your live site only when a release goes out, and we agree the release process with you and write it into your project's documentation. Pull request environments can wait for a label, deployments can be paused for any branch while its checks keep running, and GitHub can require every check to pass before a change merges.
Does it work with Docker and Vortex?
Yes, it's built on both. Every pipeline we run starts from Vortex, and every Vortex site runs in Docker, so a change is tested on the same setup it was written on.
Which CI services do you use?
GitHub Actions or CircleCI. Vortex ships the pipeline for both, with the same stages on each, so if your team already uses either of them, we'll use it too.
Which hosting can it deploy to?
Acquia and Lagoon are built in, and Lagoon is the platform behind our managed hosting. Other hosting works when it can deploy from a git repository or a webhook and run Drupal's update steps after each deployment.
Does the pipeline check AI-written code?
Yes. Every change goes through the same pipeline and a developer's review before it merges, however it was written. Our post on what we put around AI-written code covers the rest.
Can you set up a pipeline for a site you don't build or support?
We set up pipelines as part of building or supporting a website, because a pipeline needs regular care for as long as the site runs. If your own team looks after your site, Vortex is free and open source, and its documentation walks through installing it on a new or existing project.
