Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-24T08:48:14.303Z
Answers: 2017-04-26T11:39:22.573Z
Answers: 2017-04-26T11:39:22.573Z
Answers: Pierre.Vriens
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-04-24T18:54:00.497Z
Comments: 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?
Comments: Pierre.Vriens
Comments: CC BY-SA 3.0
Comments: 2017-04-24T23:42:12.367Z
Comments: @Pierre.Vriens sorry, I didnt check versions, were just example numbers
Comments: JorgeeFG
Tags: <automation><drupal>
Title: Best practice when automating Drupal (or other soft) installation regarding database settings
UserDisplayName: JorgeeFG
ThreadText: # 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.
  
  
  ---
  
  