As a company, Equiem provides various services - we activate buildings with an expert team of content creators and editors; we source retailers and manage the Portal Store; we work with our clients to help them help us shape our product and use our services; we run around telling people about how amazing our Portal is and of course, we design and build our comprehensive software platform.
The Equiem Portal is a proudly Drupal-based platform. We chose to work with Drupal because it's open source, flexible, scalable and ready to handle anything we throw at it. Drupal, which also powers The White House, Al Jazeera and The Economist among other huge sites around the globe, is a PHP-based platform that draws on the experience of thousands of contributors around the globe to create a rock-solid foundation for our product.
The Portal is more than just a Drupal base, though. With four years' development under our belts, it's safe to say that a huge portion of the code that runs our flagship product is fully written specifically for it. Although Drupal is a modular system and we do leverage the contributed modules provided by the community, our product is what it is due to the work of our talented team of developers who work tirelessly to turn our dreams into reality.
The perils of ongoing development
Releasing software can be a difficult and complex process. As you can imagine, planning a roadmap, managing a team of multiple developers, thoroughly testing everything multiple times, handling last minute requests and working on big, multi-month features requires a well-thought-out plan to make sure the gears don't jam. We've been through various iterations of workflows in our dev team and this year we reviewed again - and made the decision to move to what we see as the ultimate efficiency.
Equiem's previous development workflow required multiple days of prep-work before a new feature could be pushed to production. New work could be held back due to deployment dependencies and time-consuming manual testing. Our weekly release cycle has served us well for a long time, but in order to unleash the full potential of our product we needed to make some changes to our delivery model.
Continuous Delivery (CD)
To summarise, hopefully in an understandable way: CD is a set of methodologies and practices designed to improve the process of software delivery. The goal of CD is to have your software in a release-ready state at all times. This means that, pending automated tests running, your Dev Lead or Team Manager can hit the imaginary button at any time and have a new version of the software immediately go live.
“Continuous Delivery (CD) is a design practice used in software development to automate and improve the process of software delivery. Techniques such as automated testing and continuous integration allow software to be developed to a high standard and easily packaged and deployed to test environments, resulting in the ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead.“ - Wikipedia
It's a big shift from our previous workflow which roughly amounted to weekly (or longer-period) releases. In our previous workflow, developers worked locally on features and reviewed work manually, writing complex manual testing steps and spending lots of time reviewing code for formatting and functionality errors. Big releases with big features could take months if they weren't adequately broken down in to smaller tickets - and breaking things down into smaller tickets had an overhead for testing that we couldn't afford. We knew we needed change and we knew it wasn't going to be easy.
How did we go about it?
We went for the "quick but painful" approach and decided to move to CD within a fortnight. Sort of like tearing off a bandaid, we knew this was a pretty ambitious mission, one we thankfully managed to pull off.
The first thing we had to do was decide on a testing framework, in our case we chose Behat. Behat needed our server to be running on PHP 5.4 or higher, which meant we had to upgrade our server. Thankfully this was already a work in progress and we have dedicated staff to help with this so it didn't take us too long.
We chose to upgrade to PHP 5.5 which also allowed us to use Facebook's new API (bonus win). We also needed to upgrade our Vagrant (Vagrant is how we develop locally, and deserves a whole blog post of its own) to run PHP 5.5.
Our DevOps engineer implemented Acquia Cloud Hooks so our deployment steps run automatically when we change the tag on our Production server. Essentially what this allowed is for us to work hard all day and do a release once per day at the end of the day to deploy our day's good work to production fairly seamlessly. You don't want to be doing any manual steps when deploying a new tag under CD. Trust us on this.
Once Behat was up, our server was running PHP 5.5, any manual steps were automated and our developers were writing tests, we had to get rid of our old processes and workflows. Aka the fun part.
When we decided to move to CD we had over 60 items in our backlog, plus two full releases ready to go. This meant we had to run two systems at the same time. This is where the "painful" part comes in.
Any new work was started under CD which meant branching off Master. No biggie. We decided to push the existing two releases up the old way and any work that was completed but not yet reviewed would go back to the developer and have tests written for it and then follow CD. It's a backlog but we're steadily working through it.
It was a juggling act for a week and led to quite a few dependencies (and I'm sure frustration from the dev team) but once we were through that it was smooth sailing. And we haven't looked back since.
What does CD mean for our clients?
In a nutshell - a whole heap of benefits! Our clients have said goodbye to long wait periods to see (some) new features. You know those small nuisance that are reported every other week that doesn't get fixed quickly enough? CD allows us to address this and fix it on the same day (pending the type of issue, of course).
This is possible because we've outsourced a lot of our testing to automated tests - literally writing a test alongside a feature that asks the computer to go to a page, click a thing, complete a task and see if it all works or not. These tests run every time we push new code to our project so we can maintain our project without accidentally degrading functionality over time.
It’s important to note that CD doesn’t speed up the actual development process itself - we still need people to write code. Huge features still take the amount of time it takes to code a huge feature - we're not bending space and time here. Butit does mean that we can move faster, address issues quicker and push new features live as soon as they are ready (and passing tests). Features can be released in much smaller chunks, minimising introduced complexities and dependencies.
Instead of delivering new features on a weekly basis, we have been able to deliver chunks of work daily - and send gleeful release notes to our team every evening, so everyone is fully up to date with the awesome improvements and useful new features we are sending live all the time.
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” - Principles behind the Agile Manifesto
A great improvement
Overall, we are absolutely thrilled about this new workflow. We know that this has increased efficiency within our dev team and we're consistently delivering awesome features, bug fixes, improvements and ongoing work every single day.
We know that our clients aren't directly obstructed by CD - and if anything, our product is constantly improving and growing, and our clients see changes and can review work and see their feedback put into action faster than ever.
New features are being released more frequently, which means our product is better, faster and more efficient than ever before. Here's to CD!