Separating Configuration from Code in CollectionSpace

For the past few months I’ve been working on a project to migrate a museum’s collection registry to CollectionSpace. CollectionSpace is a “free, open-source, web-based software application for the description, management, and dissemination of museum collections information.”1 CollectionSpace is multitenant software — one installation of the software can serve many tenants. The software package’s structure, though, means that the configuration for one tenant is mixed in with the code for all tenants on the server (e.g, the application layer, services layer, and user interface layer configuration are stored deep in the source code tree). This bothers me from a maintainability standpoint. Sure, Git’s richly featured merge functionality helps, but it seems unnecessarily complex to intertwine the two in this way. So I developed a structure that puts a tenant’s configuration in a separate source code repository and a series of procedures to bring the two together at application-build time.

Footnotes

  1. From the answer to the first question of the CollectionSpace frequently asked questions. []

LYRASIS’ “Reposervice” Setup Pushed to GitHub

Earlier this month published ‘reposervice’ to GitHub. Reposervice is a “self-contained” Islandora installation source tree that is intended to smooth the LYRASIS deployment of repository services between development servers, a staging server and production servers. It is a bit of a work-in-progress at the moment, but others might find it useful as well.

(By the way, if you had looked at Reposervice prior to June 18th, you may have noticed a missing critical element — the Drupal submodule. Not because you couldn’t add Drupal yourself but because the Reposervice clone has relative soft symlinks to the Islandora modules positioned in the top level Reposervice directory.)