We are developing/tweaking our funnelback collections and are wanting to setup a testing environment... so no damage is done to live collections.
we have two live collections, local (courses) and web (site wide).
how do you currently do funnelback development? do you have a testing / sandbox environment, or test collections setup? Whats the standard approach?
Our Funnelback is hosted on squiz servers, how do non-squiz funnelback developers approach this?
There are a couple of approaches here, listed from least effort to most effort:
- Use the built-in preview/publish mechanisms for production collections. This is appropriate for:
- Template changes
- Best Bet management
- Synonym management
- Curator management
- Create a meta collection that uses the target production component collection. This is handy for isolating tests to:
- Query processor options
- Hook scripts
- Create a test/dev collection on a production instance. Useful for:
- Changes to index structures
- Changes to faceted navigation
- Changes to filter chains (and other update workflows)
- Changes to source (sourcing content from a test/dev, rather than production, location)
- Replicate configurations across separate environments. Useful for:
- Clean separation of production configs and data from test / dev equivalents
- Promotion between environments (not currently natively supported in product, but can be applied to some configurations using publish hooks - http://docs.funnelback.com/workflow_publish_hook_collection_cfg.html)
- Host file configs between environments may be required (ensuring things like seed URLs and exclude / include patterns can stay in sync between environments, especially if you want to retain update schedules, gather sizes and aggressiveness).
Thanks, that explains the various options very well.