Our Evolving Infrastructure

The beginning of a new year always seems like a good time to take some time for reflection. While we started to do that the past couple of weeks, in an effort to wrap up some end of the year goals and finalize plans for how we wanted to start 2020, we realized that it's been quite a while since we've written about projects we're working on for the site. With Drupal 9's release planned for June of 2020 now is a great time to do this reflecting and planning work.

While much of my time in the past year has been focused around our new Osio Labs products, we've also been beginning to plan for an upgrade and migration to Drupal 8/9. This seems like a good opportunity to share a bit about how our infrastructure is evolving. As we start to plan for a future upgrade, it's important to take an inventory to help give us a sense of how the project is likely to go.

When I first started working on the Drupalize.Me site, shortly after it originally launched, our tools and processes looked quite a bit different than they do now. Back then we had a site built on Drupal 6, and were using a third-party provider to host our videos, and all of our content was exclusively video. We were using svn for version control, and Unfuddle for our project planning. Needless to say, things have changed quite a bit over the years.

Now, we've moved our writing process over to GitHub. This allows us to use issues, projects and milestones, and pull requests to organize the work of content development outside of Drupal. Joe has written about some of the advantages this gives us when it comes to editing and linting tools. Additionally, it's much easier for us to on-board new writers and editors with something like GitHub than it would be if we had built these tools on top of our CMS. We're doing our content work this way on all of our products. When pull requests are merged, our content is imported (or updated) automatically. On the whole, this process has been a big win for our team. Once we have our content created via this import process we then go about adding metadata to the tutorials (video assets, publication dates, tags, etc).

Our Drupalize.Me infrastructure is somewhat of a monolithic site, aside from the tutorial production process. A single codebase then handles everything from user registration, billing, content delivery, and your personal content queue. For our new products we're trying something a bit different.

Looking at our new products from the backend, there are quite a few similarities. We're still using GitHub to help with our content creation process and importing our content into Drupal. Drupal also still helps us out with user management, and billing (thanks to the Recurly module). That is where the similarities end.

Both GatsbyGuides and HeyNode are using the same Drupal-based backend site. When you visit the site as a member you're interacting with sites built on top of GatsbyJS. This decoupling allows us to reuse our work across our sites, while still allowing them to evolve independently. One of the big advantages we've seen using Gatsby so far is that the requirements to host the sites are drastically simplified. Another nice side effect of this decoupling is that these front-end sites are now solely responsible for displaying content. This has made it easier for us to write comprehensive tests, and deploy new code faster.

As we start the process of planning a migration to Drupal 8 (and eventually 9), we have the chance to compare and contrast the monolithic and decoupled approaches. While the planning work is still in it's early stages, the flexibility we've gained by decoupling parts of our site has given us some unique opportunities. Moving forward with our migration work, I'm hoping to continue to provide a bit of a peak behind the curtain into some of the decisions we're making. In my experience real world projects like these provide the best learning opportunities, so if any of you are working on a similar project I'd love to hear about it.