Hi Fish,
There's a few ways to tackle this and really depends on what suits your needs. At Funnelback, we also use git to manage the development and deployment process. This is possible as all Funnelback configurations as stored as flat files on disk. The process looks a bit like:
- Create a collection and add the configurations to git. Push the git repository to a central server accessible by all environments (but not accessible to the public if security is a requirement).
- Develop on dev as you normally would, periodically committing the changes to git.
- On test (or any other environment), clone the git repository into the relevant folder. e.g.
$SEARCH_HOME/conf/
- Provision the collection (creates the the relevant folders required for the collection to run) by running
$SEARCH_HOME/bin/create_collection <path to config>. This only has to be done once per collection per deployment.
- Kick off updates on test as per normal.
- Further changes are made on dev and then
pulled on other environments
The benefit of the above approach is that we get all the benefits of git include:
- Peer review using merge requests
- Access to a complete change history
- Simpler and safer deployment process than manually applying changes
However, it does also have some trade-offs:
- Requires backend access
- Complex to make adhoc changes
- Conflicts are annoying. e.g. If someone made a change to a curator rule in production via the Marketing UI and in the dev environment, a conflict will occur. If will be up to the implementer to decide who wins.
Hope this helps.
~Gioan
