I’m wondering if someone might be able to explain how Bloomreach content/configuration is migrated with build distributions that flow through the DTAP pipeline - after the initial deployment to all environments. I was expecting this to occur if bootstrapping is set to true on all deployments, but this does not appear to be the case.
I want to describe the above with an example: Developer builds a project with message bundles, document content, page configurations, then deploys to the BR Cloud in a testing environment (say named “QA”). Everything in QA appears fine. As part of the development life-cycle, however, the developer makes more changes (adds new and modifies existing message bundles, content documents, site pages), rebuilds, redeploys to same QA, bootstrapping is on, no errors in the logs, but NONE of these changes made by the developer appear in QA.
Two “work-arounds” that are painful and that I’m trying to avoid are as follows:
On each environment (DTAP), faithfully reproduce all changes manually by hand in the /cms and /cms/console applications. For an infrequent and simple change, this option would be feasible. But as part of the larger development life-cycle, this is highly error-prone and tedious.
Delete the data in all higher environments each time a new deployment needs to be made. (Effectively, recreate each DTAP environment on every build.) For the time being, we’re getting by with this option, but we cannot use it for long - especially after we go live. To state the obvious, the production server will eventually have data by customers that we will need to preserve.
I’m thinking there has to be a way to conveniently migrate content/configuration changes in Bloomreach from one environment to another (other than by hand in cms). Surely, others have come across this as well.
Any suggestions offered by anyone would be very gratefully appreciated.