General questions about cap and vagrant workflows for clients

I imagine this probably differs from project to project and from developer to developer, but I’m wondering how the Roots community at large utilizes the Capistrano and Vagrant tools in Bedrock for the most client-friendly workflow. (Also, like many people here, I’m pretty new to these tools and am figuring out how best to use them.)

Specific questions bouncing around in my head:

  • Do you use the Vagrant box as a deploy area, as Scott does in the Cap screencast? (I was under the impression that he was doing that purely for demonstration purposes, but I wasn’t sure if Vagrant is often used in this way, rather than purely as a LAMP server/MAMP replacement–which is how I’ve been using it so far.)
  • Using Capistrano to deploy personal projects into date-based folders makes sense, but when working on client projects, I could see it causing problems in the future–particularly if the client hires another developer to hack on the site at some point. If each release is a set-in-stone, tagged version of the code, how do we accommodate a developer who, down the road, wishes to change a background color or whatever? Do we assume they know how to use Capistrano and git? Or do we simply deploy to date-based folders in our dev/staging environments and just push the final files into the client’s server, sans Capistrano’s additional folders and symlinks?
  • If the future developer happens to know git, Capistrano, and all these other fun toys, how do you guys share your dev environment with the client in such a way that’s private, and that they’ll actually be able to access it down the road? Do you just give them a ZIP file with all the relevant information, or do you provide access to your Bitbucket/github/etc. repositories? Do you provide any sort of instructions or a README for future devs?

I apologize if this is longwinded or off-topic; I’m just trying to figure the best way to serve clients using tools available to me–Bedrock, in particular.

Some quick thoughts:

  1. You’re right that I was only doing this demonstration purposes. Not sure you’d ever actually “deploy” to a dev Vagrant environment. It should be just using a synced local folder. I hope I didn’t accidentally give the impression in my screencast people should deploy to Vagrant boxes :expressionless:

  2. A lot of my workflows, tools, practices, etc for WordPress, Vagrant, Capistrano, Composer etc are more meant for developers working on “in house” WP applications. For developers quickly spinning off client projects, a lot of these tools don’t make as much sense and since I don’t have a lot of experience in that world, I can’t even speak to it as much. You can still incorporate some of these ideas and tools (especially for the dev side). You could still create a new Bedrock based site, use Composer and Vagrant for a dev environment (with our upcoming Ansible setup too), and maybe even use those tools to set a staging and/or production environment and then just pass it off to them. Commit the Composer packages for example and do the initial deploy. After that, it’s all up to the client.

  3. Depends on the client/future dev, but at a minimum you should either transfer a repo to them, or just provide an export. If they want to use any of these tools then they can. But I probably wouldn’t bother trying to create your own instructions or teaching them these tools unless it was a special circumstance (like their new dev actually knew this stuff or wanted to learn).

It’s a good question!

While I’ve been using roots since who knows when, I still haven’t started building anything with Bedrock. Part of the reason has been me worrying about devs that come in at a later date, as some of the sites aren’t that big of a deal (quick custom theming jobs).

As for handoff, a repo is fine but I ALWAYS try to be descriptive in my code, say that I used Roots, and pass in an updated .zip file or just make sure every theme file has been updated and uploaded to the live site. Let’s face it - most WP devs that come in on a project they didn’t build from scratch just grab all the FTP down and start hacking away, so giving them as much background as possible w/out wasting your own time is the way to go.

Unless the client pays me for theme documentation, there’s no way in hell I’m going to try and explain how to run “grunt” to make CSS changes.

Thanks, Scott.

  1. You didn’t necessarily give that impression–but I just recently started messing around with Vagrant and realized that it’s entirely possible (if not sorta dumb) to use a Vagrant box as a dev environment for deployment. Sorta got intrigued by the idea, and wondered if anybody had found any sort of use for it in that way.

  2. I sorta figured Bedrock was more oriented toward WP-based apps, but most of what I do is client (theme) work, and I find the workflows pretty useful. What you list here is sort of what I had in mind re: workflow–develop with Bedrock in place, and then hand them the final theme.

    The folder structure and obscuring the WordPress-ness of the sites is actually really useful, though, and I’ve been doing it for awhile now with the Roots URL rewrites and such. Roots fixes some of my little WP pet-peeves (messy <head>, all those verbose URLs that give away what you’re using to any passing yahoo), and Bedrock makes development and implementation faster, but I wasn’t sure how far it makes sense to go with Capistrano when doing client work, where the hand-off is usually a theme and maybe a couple plugins.

  3. I guess the export thing makes sense. I’ve never provided a ZIP with all the dotfiles and such; my assumption is they get the application itself, and don’t care about the dev setup, but I suppose the hand-off could include all my source.

I forgot to ask another question: Because WP is by its nature dynamic and automatically updated, my repositories of client sites become outdated very quickly, sometimes in a day or two. (Including my composer files, which install outdated versions of plugins on deploy.) I understand it’s easy enough to update version numbers in Composer, but doesn’t all that hand-holding sort of defeat the purpose of automating deployment? (Again, this is strictly for client sites, which are for the most part not updated often after release.) Does anybody out there have a workflow in place for developing a site with Bedrock that you can later come back to without muddying up the sleek Composer workflow?

Thanks for your thoughts. Really curious to see how other folks use this stuff.

1 Like

Bedrock is really cool. It’s taken me a long time to wrap my head around it–and Capistrano in particular–but it’s worth learning, I think. It makes developing for WP fast and fun–but it also treats WP as more of an app (or app platform), which is where Mullenweg &co. see WordPress going anyway. He’s literally used the words “the OS of the Internet”, which is a bold statement, but also suggests to me it’s worth shifting our thinking of WP from a content engine to a general application engine. Bedrock pushes that idea forward, without waiting for Automattic to move things around themselves, which I really like.

I guess that’s how I’m approaching it. If I’m a dev who comes to a site after the fact, I usually just copy files down and use grunt and all that locally. My assumption is that there’s no repo provided, or real workflow in place, on old code. But…should that be the case? Should we be handing tools off as well, assuming the next guy will know how to use them? I’ve never disclosed that I used Roots, because I don’t think clients usually care; they just want their site to work…but do we owe them (at least) access to our repositories, whether in ZIP or git:// form?

You’re right re: theme docs, though. I was thinking more along the lines of a general README for future devs. Some sort of doc that says “This site was developed using Bedrock v. x.x.x. and Roots v. x.x.x. Here is documentation for both. Clone the repository from here and work this way.”

1 Like