My team is currently working on a number of WordPress instances. We have a very very bad practice which is to work directly on the clients’ server for development.
We are having a couple of designers and developers working on the same project at the same time and pushing changes directly to the client’s server is definitely bad. I would rather have something more like Bedrock from Roots.io.
I use ManageWP. I design and develop on my server then use manage wordpress to move the site to its permanent hosting. Honestly, I’ve been cowboy coding from the start. I’ve only just begun trying to go down this path too. I have one test site that I am working on sorting out git with right now, but I’ve not made as much progress as I had hoped to.
Bedrock is awesome. But also heavy if you aren’t even using Git yet. Here is my companies boilerplate. Designed to give you environments and a quick base to get started.
Yes, some kind of SCM is definitely in order. Even if you all just dev in your respective environments, and then one person is charged with pulling the repo and uploading it all at once.
Personally I prefer to work locally and deploy via git (I use roots, though I am not sure that I will be working with bedrock, as I haven’t looked at it very much), but depending on what you’re doing it might be quite a hassle to setup.
Personally, I like roots and how it uses grunt, so that’s the extent of the build automation I use. I think that most other folks who need some level of automation are using codekit or similar, as mostly you don’t really need to build much in a php application.
Ok, here’s what I would do. First, every developer should have a full stack dev environment. This is hard on Windows, simple on Linux or Mac so, ideally, they’re working on one of those. Whatever they use, everyone needs to work off a repository so setup a git repository and have everyone install a git client (or learn the command line basics).
Next, setup a simple, efficient workflow. This is a good starting point:http://scottchacon.com/2011/08/31/github-flow.html.
Basically, branch for everything, even small changes, make the change, run tests locally, commit that change. Don’t have long branch checkout times – you’ll get out of synch.
When the site is done, deploy from staging to live.
You can have long branch checkout times, you just have to be responsible for consistently staying in sync with master/staging. You also should be rebasing and squashing. The master branch should only be working versions of the site, no daisy chain commits.
A startup I was working with a couple years back designated one developer as the “gitkeeper” (ha); basically it was their job to review pull requests before merging feature branches back into the trunk/main branch. Haven’t worked with a team that large since, but it seemed like a good practice.
There is a bit of a problem with that, especially in larger teams or where you need higher tolerances… for instance, say I have XAMPP and am writing a module in Magento, and I’m still looking for my butt with my flashlight, as far as Magento is concerned. I might write a module that has the wrong case for the auto-loading classes, and then when I commit the work to the staging server, it breaks because OSX doesn’t respect file capitalization in the same way that Linux does. Now, that’s a purely fictitious example, never happened to me, I assure you … but imagine that multiplied by Microsoft.
I’m using Desktop Server, git with bitbucket.org and WP Migrate DB Pro to work with a local, staging and production server. Freaking awesome. Over Christmas I’ll be looking at Root.io Bedrock too.
Honestly, I wouldn’t develop under Windows if I was deploying to a Linux environment and I had a choice. But Desktop Server looks like an interesting product if you have to as does XAMPP. Case sensitive file names are an issue. I worked on a project a while back where some devs were on Windoze and other on Unix. After a few collisions we set a strict policy: ALL FILE NAMES ARE IN LOWER CASE! It solved the problem