<p>Your question sounds like you should have a look at what I call <strong>F</strong>eatures <strong>C</strong>onfiguration <strong>M</strong>anagement, aka <strong>FCM</strong>. FCM is not only about using Drupal's <a href="https://www.drupal.org/project/features" rel="nofollow noreferrer">Features</a> module, and not about <strong><em>Configuration Management</em></strong> (as introduced in Drupal version 8). Instead, it is a special case of <a href="https://en.wikipedia.org/wiki/Software_configuration_management" rel="nofollow noreferrer"><strong>S</strong>oftware <strong>C</strong>onfiguration <strong>M</strong>anagement</a>, aka <strong>SCM</strong>, applied to Drupal.</p>

<p>Mostly because <a href="https://www.drupal.org/project/features" rel="nofollow noreferrer">Features</a> can be considered as a code generator, whereas that generated code may be considered as the <em>build script</em> (as in your question). Which can then also be used to be migrated through multiple environments.</p>

<p>Have a look at my (popular) answer to "<a href="https://drupal.stackexchange.com/a/199860/39516">How to use the Features module in a 3 dev environments?</a>" for (way) more details about all this.</p>

CC BY-SA 3.0
2017-04-24T08:48:14.303Z
2017-04-26T11:39:22.573Z
2017-04-26T11:39:22.573Z
Pierre.Vriens
<p>Suppose I have Drupal and CiviCRM installations to automate.</p>

<p>These, however, need particular configs for working together (some file edits and database configs)</p>

<p>Should I make a fixed version install (eg. <a href="https://www.drupal.org/project/drupal/releases/4.7.5" rel="noreferrer">Drupal 4.7.5</a> + CiviCRM 4.5.6), install them and configure, and then save the edited files plus database?</p>

<p>Or should I put more effort in my build script and make some queries and seds to edit those configs in the database and files?</p>

CC BY-SA 3.0
2017-04-24T18:54:00.497Z
Drupal ***4.7.5*** ... really? That's a release from Jan 5, 2007 ... Are you familiar with what (the scary) [Drupal 7.32](https://www.drupal.org/drupal-7.32-release-notes) was all about?
Pierre.Vriens
CC BY-SA 3.0
2017-04-24T23:42:12.367Z
@Pierre.Vriens sorry, I didnt check versions, were just example numbers
JorgeeFG
<automation><drupal>
Best practice when automating Drupal (or other soft) installation regarding database settings
JorgeeFG
# Best practice when automating Drupal (or other soft) installation regarding database settings

(Asked by: username_0 on 2017-04-23)

Suppose I have Drupal and CiviCRM installations to automate.

These, however, need particular configs for working together (some file edits and database configs)

Should I make a fixed version install (eg. [Drupal 4.7.5](https://www.drupal.org/project/drupal/releases/4.7.5) + CiviCRM 4.5.6), install them and configure, and then save the edited files plus database?

Or should I put more effort in my build script and make some queries and seds to edit those configs in the database and files?

**Tags:** automation, drupal

> **Comments:**
> **username_1**: Drupal ***4.7.5*** ... really? That's a release from Jan 5, 2007 ... Are you familiar with what (the scary) [Drupal 7.32](https://www.drupal.org/drupal-7.32-release-notes) was all about?  
> **username_0**: @username_1 sorry, I didnt check versions, were just example numbers  

---

## 1 answers

### Answer by username_1 on 2017-04-24. Score: 7 | Accepted answer

Your question sounds like you should have a look at what I call **F**eatures **C**onfiguration **M**anagement, aka **FCM**. FCM is not only about using Drupal's [Features](https://www.drupal.org/project/features) module, and not about ***Configuration Management*** (as introduced in Drupal version 8). Instead, it is a special case of [**S**oftware **C**onfiguration **M**anagement](https://en.wikipedia.org/wiki/Software_configuration_management), aka **SCM**, applied to Drupal.

Mostly because [Features](https://www.drupal.org/project/features) can be considered as a code generator, whereas that generated code may be considered as the *build script* (as in your question). Which can then also be used to be migrated through multiple environments.

Have a look at my (popular) answer to "[How to use the Features module in a 3 dev environments?](https://drupal.stackexchange.com/a/199860/39516)" for (way) more details about all this.


---

