When I first decided to join Growella as the Director of Technology, one of the most appealing parts was the utter lack of technical debt; after all, if you haven’t built anything yet, you probably don’t have a whole lot of technical debt to worry about!
I decided that we would set out from the start to do things “right” (with “right” being a relative term, based on my past experiences and personal opinions on software development), and one of the first things I wanted to introduce was a Continuous Integration (CI) and Continuous Delivery (CD) workflow.
Growella uses DeployBot to handle deployments, but we're also using Gulp to run webpack, Sass, and other compilation tasks, then building a
dist/ directory that acts as the root of our deployment. This ensures we're only deploying the files we need on production, while leaving out development assets.
We're also building Growella as a twelve-factor application, so we're using Composer and WPackagist to pull in our dependencies, which is super easy to do with DeployBot. We're even able to cache the
composer install, ensuring it's only run when something has changed in
composer.json (for instance, installing/upgrading a plugin).
On paper, this looks great: we're only running Composer when we need to, and we're able to prepare a nice, packaged version of the site for delivery to the target server, which is taking advantage of DeployBot's atomic deployment pattern.
Here's the rub: it was slow. Unacceptably slow, taking 10-15min to deploy a WordPress site.