5

"How to Write a Drupal 7 Installation Profile": http://drupal.org/node/1022020

Any experience with this (good or bad)?

The link above references the ability to create an installation profile. Question is, how much can it do?

The real objective is to be able to put everything into code (and version control) that defines the website; permissions, OG field group settings, you name it. And then use that as a routine production path from dev, to stage, to production.

I've heard theory that this technique could be used to not only establish a site, also as a vehicle for migrating from the dev environment, to staging, to production.

Clearly, there is a benefit to be gained by an organization like Pressflow to be able to build a preconfigured base distribution. But, how viable is this technique for routine website updates and maintenance?

4

I have 1 site in production (re)built every academic quarter off of an installation profile. I have various sites in development I am building using installation profiles.

It's a PITA to try and include content into an install profile in my opinion. It seems to be a great way to code up the functionality of a website. But I still rely on a BASH build script and Drush to run additional import stuff -- and tools just as Migrate, Taxonomy_csvimport and backup migrate to move "content" around places.

I do like "building" the site codebase using an install profile and would recommend the Profiler module to help you along. You can do alot with install profiles.

3

I began to consider this alternative some time ago; I have started to make a drush command to generate an installation profile from an existing site. My general thought was that backing up unmodified versions of Drupal core and contrib modules was inefficient and clumsy to analyze; much better to commit only a makefile plus an installation profile that contains the custom components.

There is an open question as to whether configuration should be represented in the installation profile, or in features. Drupal 8 has a better solution, but in the meantime, many people use features to deploy configuration options. It was therefore my assumption that I should make features that capture my configuration, and save the features in my installation profile. I have discovered, though, that drush feature-revert does not always handle dependencies inside a feature very well. I did not get to the bottom of it, but as a workaround, running drush fra multiple times (until nothing further changed) seemed to be a potential workaround. It would also be possible to create multiple features, and install each one in turn, effectively manually managing dependencies. Of course, features cannot capture all configuration information in code, but the alternative of manually hand-crafting all configuration in code in an installation profile seems too labor-intensive for smaller projects.

I have not gotten to the point of using this mechanism for any live sites, but some people have.

3

Don't try to use the installation script in a profile to maintain your configuration unless you're shooting to make a distribution profile. Using Features, or the results of the CMI in D8 is a good way to maintain your configuration.

Keeping everything grouped in a profile so you can use a stub drush make file and a single git repository isn't just "theoretical", it's an excellent way to keep things organised and deploy.

You can use Aegir to manage backups, deployments and migrations between different versions of your profile.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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