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.
PreviousNext and our Continuous Integration (build system) have been on a journey for the past 3 years. We are now onto our 3rd generation and would like to share with you some of the concepts and technologies behind it.
The DrupalCI initiative is geared towards developing tools for the next generation of testing on Drupal.org. In the following video I will demonstrate the "Results" component responsible for providing build feedback.
At the recent DrupalCon Amsterdam sprints something amazing happened, people from all corners of the globe assembled to sprint on DrupalCI. DrupalCI is an initiative born out of the requirement for new testbot infrastructure. Our goal is to implement a brand new Continuous Integration (CI) workflow that can not only be used for Drupal but anyone wishing to run a CI infrastructure / Automated tasks. Until this point we had only corresponded via a weekly hangout and IRC.
While this was keeping us on track with building out some of the components, the conference gave us an opportunity to sit down in the same room and perform an end-to-end architectural review to ensure we didn't have any gaps. A modular design approach has been used to ensure that many of the following components could be used as a standalone entity in any infrastructure.
Cameron Zemek (@grom358) and myself got the priviledge of speaking at DrupalCon Amsterdam as a part of the Core Conversation track. This was off the back of the work that we had been doing in core to swap out some of simpletest module with libraries. We were also joined by Konstantin Kudryashov (@everzet) creator/maintainer of the Behat, Mink and PHPSpec projects.
I recently spoke at the Drupal Melbourne meetup about running Puppet and Docker to improve isolation when running multiple sites on the one host. It's alot of work to get setup properly for a remote speaker so I would like to thank the organisers for allowing me to present.
We are passionate about code quality. We want to make sure our code is well tested and confirms to standards at all times. If there is a bug, we want to know as soon as possible, so we can fix it and keep our code stable, well tested and bug free, even in early development versions.
Typical workflows use a git topic branch for development of each feature, and require code to be merged into a development branch before automated tests are run. The problem with this approach is it tests code after it has been reviewed and merged.
Using Jenkins for automated testing of Github pull requests, we can get one step closer to code quality nirvana.
