As part of our development and support workflow, we have gradually built up a Continuous Integration (CI) platform to run automated tests and builds. It’s become such an essential part of our ever-growing toolkit that we are now offering it as a service to select customers.
Our Jenkins-based platform has evolved to the point that we are providing dedicated CI as a service, as either a fully managed SaaS offering or as a one-time setup. As a fully managed service, organisations get all the benefits of the system without any maintenance burden. Other organisations may be able to maintain the platform, but need help with the initial setup.
Here’s a quick summary of how our CI works, from Github to production. For our development workflow, we always maintain a “development” site and a “staging” site in addition to production.
Jenkins provides a clean and functional user interface to interact with the various builds. In the dashboard, you can:
- View in-progress builds, including the real time console output
- Check the results of a build that has finished (a simple green/red indicator shows whether each instance has passed or failed)
- View the details of any test fails
- Trigger a new build for any of the available tasks
- Cancel a build that is already in progress
Github pull requests
When a pull request is created in Github, the CI system runs a suite of tests as part of an automated build process. This ensures that any issues are raised early in the cycle and can be addressed immediately. This also ensures that the code stability is always maintained, and lessens the effort in a testing phase at the end of the sprint or release.
The following tests are run as part of continuous integration:
- Code quality: checks for conformance to Drupal’s coding standards (https://www.drupal.org/coding-standards), including the requirement that all files, classes and functions are well commented.
- Unit tests: tests individual code paths independently of overall system. Ensures that code is logically correct, and drives code testability and clarity.
- Functional tests: tests a Drupal installation from the perspective of a user. Ensures that custom code is interacting with the rest of the system as expected.
Site per pull request
In addition to the automated tests, each pull request build generates a fresh site install from the PR, so that changes can be verified and tested before the code is merged into the master branch. By default, the PR site copies the database from the “development” site to ensure there is recent content for testing.
My favourite (and most used) part of our CI is the automated deployment to the development and staging environments. This eliminates the manual processes involved in deployment, and shortens the time taken for code to be ready for QA.
We use Jenkins to listen for merge events triggered from Github. When code is merged to master, the updated branch is automatically deployed to the development site. Releases updates are deployed to the staging site.
When used in conjunction with install hooks, the automated deployment system means there are no manual deploy steps at any point. Just merge the code and you’re done.
Automation is great, but it has to stop somewhere. We always deploy a version of the releases branch to production, via a tagging system. Each time code is merged to releases, a tag is generated so the code can be deployed to production.
Depending on where the production site is hosted, the actual production deploy is done differently. One option is to use yet another Jenkins build. By running a “production deploy” build, you can either deploy a specific tag or releases in its current state, with the click of a button - no terminal required.
Database and file syncing
Since we don’t need terminal to deploy, why should we rely on it for database syncing? We have Jenkins jobs for syncing the database and/or files from production to staging or development (and never the other way around). Not only does it save time, it ensures that no one will “accidentally” sync the wrong way.
For organisations without any access restrictions, http authentication is an easy way to handle user access, with a single shared username and password.
Where restricted access is required, we can authenticate via Github accounts so that specific users can be granted access only to specific builds.
Support & maintenance
As part of our fully managed offering, we provide ongoing support for CI users. Server maintenance and ad hoc server upgrades are also included.
Please contact us for a demo and to discuss how we can deploy a CI service for your team.