8

Craft updates come fast and frequent which introduces a problem when working with lots of people in a team. Don't get me wrong, this is a good problem to have!

How are dev shops handling the update process when sites have multiple developers on them with multi feature branches running all at once?

The main issue is the strong dependency each feature branch has with the database. Once you implement a craft update, craft doesn't like jumping around on older versions as you switch feature branches.

What we're currently doing:

  1. Disabling the ability for people to be able to update on the live production server.
  2. Creating an "Upgrade" branch on git and doing the updates in that before merging them into the develop branch.

We still seem to be occasionally getting the odd issue of an old feature branch that is out of sync with the database/new install because of this we are still looking to improve this workflow.

Ideas we are tossing up:

  1. Making a private repo of the /app directory a submodule so the sites repo is rather clean.
  2. Disabling the ability to upgrade by default on all domains and treat updates as a "big thing" similar to how you would on an Expression Engine upgrade.

Would love to hear how others are tackling this "convenient" problem.

Improve this question

1 Answer 1

Reset to default
7

We at Familiar have decided to leave craft out of git because of this exact issue. It's extra hassle every time an update comes out.

To better deal with it we've built a couple of grunt functions as part of our craft yeoman generator. You can see the whole generator on npm: https://www.npmjs.org/package/generator-familiar-craft. Or just an idea of how the grunt tasks are setup: https://github.com/familiar-studio/generator-familiar-craft/blob/master/app/templates/Gruntfile.js

The tasks are pretty simple, the first one will download the latest copy of craft, unzip it and then move just the app folder into place (perfect if your local environment gets way behind)

We also have a database pull grunt task that grabs a copy of the live (or any staging) database and imports into your local database.

This way there's always a quick fix through one or both commands if things get out of sync on any of our developers local environments

So our normal update process is this

  1. Update local to make sure everything's fine.
  2. Update live
  3. Celebrate!! No committing needed.

Generally we treat craft just like any other project dependency manager like bower would and only add our own code to our repos

Improve this answer
5
  • I would be keen to see this grunt task if you don't mind providing a link!
    – jnowland
    Commented Oct 29, 2014 at 4:53
  • Sure here's the gruntfile github.com/familiar-studio/generator-familiar-craft/blob/master/…. It's part of our craft yeoman generator but you don't have to use the generator to use it. Just make sure you fill in any of the variables. Still needs work but it's been a huge timesaver for us
    – Keith Mancuso
    Commented Oct 29, 2014 at 4:59
  • Interesting approach that makes sense, since Craft is encapsulated in its own folder (Great design!). I certainly hit git conflicts a couple times while upgrading, like that time right before launch deadline. Ouch.
    – Fred Carlsen
    Commented Oct 29, 2014 at 8:40
  • Yea, exactly the kind of thing this setup is ment to avoid. We're consisting adding some way to pull down specific craft versions similar to the way bower lets you specify specific versions or just latest, but we haven't had the need to tie something to a specific version yet
    – Keith Mancuso
    Commented Oct 29, 2014 at 12:17
  • Interesting take on the matter. Thanks for sharing.
    – Jérôme Coupé
    Commented Oct 29, 2014 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.