Hosting

Hosting environments vis-a-vis development workflows

By:

Jerrod Long

on 5/18/2016

“Fulfilling our clients’ goals and needs by delivering stable and usable software helps their business succeed.” – Joe

This is a core concept of what we do at VIA. If the needs of a client lead us outside our standard operating practices, we adjust to the project.

We recently completed development on a website that streams coverage of an annual competition. Due to the nature of their business, the site has one month of high traffic and server demand out of the year. The rest of the year, however, sees little to no traffic. Due to the vast fluctuation in the server load for this product, it was determined our standard hosting provider, WP Engine, was not the best fit for this particular client. When the decision to use a different hosting provider was made I did not foresee this making a major difference in our development workflow. I was wrong. Very wrong.

Tailored workflows to hosting environments

As much as possible, our development workflow has been tailored around our various development environments to ensure code quality and efficiency. Our local environment mirrors our standard production environment as closely as possible. In both environments, the WP (WordPress) core is not version controlled by using a .gitignore file. Our hosting provider maintains the WP core, ensuring it is updated to the latest version, while on development we have a grunt task that leverages wp-cli to fetch the latest WP version in our setup task. Obviously this aligns perfectly, allowing our repositories to be nice and streamlined, containing only the theme and plugins for each project.

The similarities between environments do not stop there. Database management is handled the same way and a multi-developer workflow is supported. In addition to environment similarities we have automated jobs for creating a new project, deploying to servers, syncing databases between environments, restarting web servers, adding staging environments, creating sub-domains and much more. Basically, we have an automated job for the majority of server management and project setup tasks that have to happen in order for the actual development to begin. We leverage Jenkins to make all of this possible.

Much like a concert goer does not think about all the equipment costs or rehearsal hours that go into the performance, I did not fully appreciate the refined nature of our development workflow. Nor did I grasp the increased productivity that it facilitated. The old adage of you don’t know what you’ve got until it’s gone certainly holds true.

We didn’t settle on a new hosting provider at the beginning of the project. Instead, we began development locally and then transferred the project to the new host partially through development. This caused some issues. Some of the problems we encountered while migrating the code and database were minor. Having a .gitignore file that does not block the WP core, for instance, was a quick and easy change. Some were slightly more problematic, such as the new provider strongly urging against sessions. Other problems, like not having a visual database management tool, were a major hindrance to peak development efficiency. While converting the codebase from the requirements set by hosting platform to the other I became frustrated. It was tedious, time consuming, and did not get us any closer to a great product for our client.

Tailored tools === better products

The hosting compatibility issues were eventually worked through and solved. We even wrote a few new automated jobs so that we could more closely adhere to our standard workflow. This also will allow for a faster ramp-up time if a similar project opportunity arises in the future. After the frustrating transfer period, development went much more smoothly.

At least three things changed during the course of this project: the hosting provider, our development workflow, and my understanding and appreciation of our development and project management processes.

One thing did not change though. Despite the headaches, the hosting solution we chose fits the needs of the project and will provide a better experience for the product’s users. Which is the most important consideration.

View a recap of the project results.

Share to

Related Posts

Replacing Jenkins with GitHub Actions

By:Nick Stewart on 8/14/2023

GitHub Actions are basically workflows that are trigged by Git actions and live inside GitHub. For example, you want to build and deploy to production when a branch is merged into main.

Read More »
Website Hosting: It's Not as Complicated as You Think

By: Natalie Miller on 8/22/2017

We're really satisfied by WP Engine's hosting, and if you don't know what that means, here's a basic overview.

Read More »