I’ve finally done it – I’ve jumped on the version control wagon. I was already partway there, with all my open source projects and a few internal development projects hosted on GitHub, but now I’ve finally started using version control for new client projects as well.
I have to admit, I feel a little grumpy about it. It’s more steps in my workflow and more work to set up on the front end of each project. However, it’s also entirely necessary now that more than one person often ends up touching the code for any given project. With version control, we’re able to collaborate more fluidly (and safely) and it opens the door to bringing in even more collaborators on the fly without having to jump through too many extra hoops to get them touching the existing code in a low-risk way.
There are some vague plans floating around in my head for a start-to-finish screencast experience where you can see exactly how I set up and work on custom theme projects, which will of course now include the details on my version control set-up, but for now here’s a quick overview of the things we’re trying and how it’s going so far.
Tools & Apps
I’m using Beanstalk to host and deploy our client project code as well as the theme for this very website (which is my test case, for better or for worse). My open source projects are still hosted on GitHub, along with a couple of private repositories that I’m eventually planning to release publicly.
While Terminal and I are usually on speaking terms, it isn’t my favorite tool in the universe so I’ve been trying out a variety of Git GUI apps and I think I’m probably going to end up sticking with Tower:
I like that it’s got built-in support for both Beanstalk and Github, so I can easily use it to jump between projects hosted in either place. Tower has handily posted their help docs online, including this quick reference to a basic workflow, and their overall documentation seems to be solid.
It’s a complex app but as I learned while getting my own theme set up, it’s pretty straightforward to use once you’ve got the steps down. One piece of advice:
It's amazing how much more smoothly things go when you actually read the documentation.
— Zoe Rooney (@zoe_rooney) July 27, 2013
That’s a lesson I can never learn enough.
For actually editing my code I’m still a big fan of Espresso. Perhaps counterintuitively, the built-in S/FTP is as useful as ever with my new workflow since it allows me to keep those connections around for quick access when needed. This is helpful for all the files we may need to touch that aren’t handled through version control, such as WordPress core files, and files that contain sensitive information like passwords.
I’m still thinking through the development environment side of things for our team – I’ve yet to talk to anyone with a similar business model who works on a similar type and volume of websites and uses version control so I’ve been unable to compare notes in a really useful way with how others do this.
The good news is that my ever expanding team of developers and independent contractors includes really smart people who offer productive suggestions when I bounce random thoughts and ideas off of them (thanks, Kim and Blake).
So far, we’ve landed on only handling our custom themes through version control, since that’s (a) where the active work is taking place and (b) content that can’t be readily modified via the WordPress admin.
We’re also still working out how to handle (or not) staging sites vs production sites, particularly in cases where we’re working with an existing site. For new themes on non-public sites, we’re currently auto-deploying since there’s next to no risk involved. Once the site is close to going live or just after it’s gone live, we’re swapping over to manual deployment as an extra check point against introducing new bugs or errors. In general, we don’t use separate staging sites that mirror production sites but that’s something we’ll likely be changing, at least for projects on existing sites.
Finally, right now this whole version control process is limited only to our WordPress projects since there isn’t much in the way of version control integration with Shopify. If you’ve got ideas or strategies for Shopify, please do share them in the comments – it’s something I’m actively brainstorming and would love to discuss.
This is a brand new frontier for me, and one I’m still actively pursuing so I’m certain there will be more to come as we work out our systems and refine our methods over time.
Are you using version control of any kind for your coding projects? What have you learned or what would you like to know about a front-end workflow that incorporates version control?
Further Reading & Resources
- This is a nice starter article about WordPress version control
- If you are interested in developing locally, there are some great tutorials on setting up local environments from TutorialZine and Smashing Magazine
- Continuing with local development, the WordPress Codex has an article on Setting up a Local Mirror on MacOS X
- There are tons of tips & resources in this recap of a WordCamp Jerusalem talk on development environments
- One of the tricky things about handling staging sites in WordPress is migrating the database – this plugin purports to handle that cleanly
- There are also desktop apps for working with databases that may help, including Sequel Pro for Macs