What advantages does Features offer in deploying changes

Question

What advantages does using features to manage deploying changes (versus keeping code updated and data fresh)?

The Features way (near as I can discern):

Features takes configuration (which is ‘content’) re-envisions it as code and builds a module for it, and then pushes it up where it continues to live as an object that has to be maintained as code forever.

The next time the developers update their code, (where the best would include updating their dev database to a fresher copy of production), they get these configuration changes that they too have to manage in perpetuity.

The not really doing anything special way

The original developer updates the configuration on production, (after ironing out these changes in development), then we are done worrying about that configuration change, forever.

The next time the developers update their code, (where the best would include updating their dev database), the configuration changes are included. No one ever has to worry about overrides and reverting ever.

Obvious Caveat:

If the original developer changes 103 individual settings, remembering and setting them all would be nightmarish. In this case I would understand using a configuration packager, which is more or less how Features is used, to set the production system to match. But then what? I don’t understand keeping that project alive after you have updated the settings on prod to match what you did in development. Features as a fire and forget config missile, I get... as code... I don't get maintaining it after the fact.

===================================

I started out this post open to Features, after it was regaled by some incredibly trustworthy Drupal gurus. I had a bad feeling about it, but hoped it would wane. After writing this, again find myself frustratingly opposed to something everyone else seems to think is the best thing since sliced servers.

The features ideals I can’t wrap my brain around:

I have always approached Drupal with a philosophy less eloquently described by one aforementioned gurus as: “Content comes down, code goes up.”

In Drupal 7, configurations for the system and modules is stored in the database. The dotted line I've drawn in my perception demarcates content from code is right on that line; code is stored in files managed in Git, content is entered into the UI and stored in the DB.

Using Features for Structure: On my gut feeling about exports and features, another Guru said: “It’s going to end up in a file one way or another”.

I didn't argue at the time because I wasn't seeing his perspective and wasn't comfortable calling him on it (guru vs. marginally experienced flounder).

I've never thought about it because I wasn't using the paradigm he was thinking about (developer). I had always just imported the structure, because my brain is always in a different paradigm (site builder) when I’m working with structure.

I haven’t ever done it the way he described. It is actually clever, and I can see using that method in certain cases. I realized later when my brain was back in developer mode that I have done something similar this, in a different sort of way; I use Form Builder to build rough forms quickly, then drop them into my code, I don’t export them, because Form Builder gives you access to the code for their construction as you build them out.

This makes me hesitant to say “Features is teh Ahhsumz”

So what am I missing?

Answer 1

You seem to have mentioned the use-case of Features only as a configuration packer, probably with strongarm, or with structure - where you would not use the code once it is run and has made its changes in the database.

But one of the important uses of Features is ctools exportables, such as Views, rules, etc... Here, the settings are much more complex than '103 configuration options' and if you are dealing with multiple developers, a staging site and then production, you can't imagine doing all of this manually on all different servers and instances.

Answer 2

As a Drupal developer, I find that there is a virtual ocean of tricks and tips out there that don't make much sense at first, but then grow on you as you use them. Features is one of them. Here are a few points to keep in mind (you probably know most of this):

• Using Development and Test servers are an absolute must.
• Drupal updates are often complicated and require plenty of trial and error (and advice.)
• Manual Live updates are bad. You won't get it exactly right the first time every time.
• Sometimes manual Live updates are unavoidable, be sure to practice a few times on test.
• Otherwise, have an established method for moving updates from production to test to live.
• Almost all of your (back-end) site updates will change the database in some way.
• Content does indeed move down and changes move up.
• If you don't separate database updates from content, content will (eventually) be lost.
• To minimize loss, take the site off-line and be as quick as possible or...
• If you can separate updates from content, you will not need to download/manage content.
• Features automatically separates database updates from content.
• automatic processes are faster, more accurate and more reliable in the long run.
• It is still important to move content to test to insure that your changes won't break things.
• Features improves to process of adding, storing, sharing and reverting updates.
• If there happens to be a problem with your update, reverting a feature is FAST.
• There are cases were you can publish your update to additional sites using features.
• features is a form of encapsulation and encapsulation is good.