Our direction was simple: migrate the site to Drupal 8, and reuse as much code as possible from the Bravo and Oxygen brands. Both of those sites are full-stack Drupal sites sharing the same code base and content model. In contrast, Universal Kids used a different content model and a decoupled architecture. The front end was a single-page application written in React with an API powered by Drupal. Between the two was a custom Java application that stored content in a MongoDB database.
Based on our discovery, we recommended reusing and refactoring modules to be shared among all three sites while maintaining independent content models to simplify the Universal Kids migration and reduce testing-related risks.
Taking an Agile Approach to Migration
Drawing on what we previously learned when setting up jobs for migrations, we:
- Created a full migration every three hours, taking a fresh database dump from the source site and saving the resulting database in a Docker MySQL image. The front and back-end teams used this database—containing recent content—for their work.
- Enabled the migration team to make tweaks via pull requests and trigger the migration job on CircleCI in an isolated way to verify it before merging, which prevented tests from breaking in the master branch and the front and back end teams from getting a broken migration.
Implementing Test-Driven Development for an API Project
With a plan to swap the back end without affecting the front end, we theorized that we should be able to write a test suite that proved we had not impacted the API, without requiring manual QA. We mapped out a development workflow that resulted in every single test failing since the Drupal 8 site didn’t exist yet. As we implemented more API features, the corresponding tests began to pass until we had test coverage that proved we’d accurately completed development.
Our test-driven approach enabled us to launch before finishing development because we were able to show that the site was running even without a complete one-to-one API. Not only was this successful, but it also exposed bugs in the existing application, and we found a variety of edge cases, not uncovered in the current implementation, that needed addressing.
Making the Most of Project Forecasting Tools
Unlike many projects, this migration was a fit for a waterfall-style project plan. With minimal dependencies on other teams or software platforms, a limited and fixed scope with no design or front-end changes, and a team with experience completing similar migrations for the same client, we felt solid in our estimations. We used Jira for ticket management while leveraging two forecasting tools: Smartsheet for Gantt charts and Throughput Forecaster. These tools helped track epics and velocity and worked great since the minimum to launch D7 to D8 replatforming projects is very high.
Using Tugboat with the Decoupled Front End on Every Pull Request
To speed up development and improve communication, we used Tugboat with the decoupled front end to illustrate progress on every pull request—each one used a recently-migrated database to leverage up-to-date content for testing. Using Tugboat to build a complete copy of the site stack let us show in a pull request: “I fixed this API, and you can now see the page is working better.”
Tugboat eliminated waiting for a production hosting setup and gave us an environment in which we could test infrastructure configs, such as Varnish, where we committed the VCL to Git. This setup enabled a local copy of the React app to point to a Tugboat environment to reverse-engineer how some APIs were used instead of always having to maintain up-to-date Drupal on a local.
Refining the Feedback Loop
We continuously improved our feedback loop during the project and were able to offer weekly demos. These demos, primarily targeted to the editorial staff, showed the implementation of the simplifications we made. We also showed changes in some of the UI elements of the administrative interface due to the D8 upgrade, like custom Media module browser implementations in D7 being replaced by Entity Browser/media in core UIs.
Demonstrating the React front-end in Tugboat and maintaining regular communication about progress and blockers gave all stakeholders and the Lullabot team confidence that the migration would work.
Delivering a Better Experience for All Users
We set up the foundation of the migration job in just a few hours and tweaked it gradually. That, coupled with researching and implementing new ways of testing APIs in a model to show progress after each sprint, allowed us to develop and launch faster than planned.
The Universal Kids team had a site with faster performance, fewer errors reported in the React app, and a better editorial experience.
Lullabot was an amazing partner for this project. They seamlessly made our migration a reality, and we immediately noticed great improvements to the site’s speed and responsiveness from just a few minor editorial changes.