version control

Deploying From Bitbucket to WordPress

Of all the projects I've worked in the last few years, there's one that stands out as my favorite: I wrote a WordPress plugin called Great Eagle (Tolkien reference) that allows my team to install and update themes and plugins from our private Bitbucket repos, via the normal wp-admin updates UI.

This plugin has blasted our dev shop through the roof when it comes to development best practices, in ways we never expected or intended. It forces us to use proper version numbers because now we can't deploy without them. It forces us to store our work in Bitbucket because now we can't deploy without it. It forces us to use the command line en route to deploying our work (by which I simply mean, git push origin master), which then led to us using phpUnit. Now we can't deploy unless our tests pass. We've arrived at the nirvana of test-driven development, all because we started with the unrelated step of deploying from git.

If this all sounds standard and obvious, great. I'd love a chance to learn from you. If this sounds like exotic rigmarole, guess what? This article is for you.


Develop Locally, Use Images from Production

Working on your website locally means having the files that make your website tick right there on your computer. It's common those files live in a version control repository. You work on them, and push them up to the repo when you are ready. Other people work too, and you pull their changes back down.

What might not be in that repo, are images files from the CMS. WordPress is a classic example of this. When you upload an image in WordPress, it does a whole song and dance. It gets uploaded to the `uploads` folder, multiple versions are created, even the database is updated and attachment meta data happens. What doesn't happen is that a version control commit happens with all those files.