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.
If I’m not coming across clearly in question above with regards to what I’m trying to do, the following steps detail a failed experiment in this content/configuration migration between environments that I had hoped would work. The experiment is broken down into five chronologically ordered points in time (time t0, t1, …, t4).
t0: On a local developer machine (DEV), setup a BR project with a message bundle (messageBundleA) and a simple content document (documentA).
t1: Create distributable and deploy to a target, higher environment (QA). (Bootstrapping is turned on.)
t2: Confirm that messageBundleA and documentA appear fine in QA. Check logs in QA and ensure no unexpected errors occurred. (This succeeds, but I believe it’s because it’s a brand new deployment with a new database.)
t3: Back on DEV, (1) edit a single caption in messageBundleA, (2) edit the content of documentA, (3) create a new message bundle with one caption (messageBundleB), (4) create a new simple content document (documentB), and (5) create a new Page showing any document with Channel Manager. Publish all these changes. (Note: the purpose of this step is to create a few different kinds of content and configuration changes to redeploy in the following step.)
t4: Create a new distributable on DEV and redeploy it to the same QA environment.
After doing the above steps and inspecting the QA environment, the following observations are made:
Following the initial deployment to QA (time t2), none of the changes made in DEV (time t3) appear in QA. Content documents are not updated/created, message bundles are not updated/created. The new page and sitemap entry does not appear in QA either. The log files in QA show no errors.
I should add that I remain convinced bootstrapping is on, as the QA environment in the BR Cloud contains the following start-up logging line:
22.05.2019 22:14:57 [org.apache.catalina.startup.VersionLoggerListener log] INFO Command line argument: -Drepo.bootstrap=true
My belief is that the steps outlined here simulate common occurrences between builds during a development life-cycle.
Content will never be reloaded, unless it’s marked as configuration (this has to be done explicitly, so I guess this is not the case). This is for the simple reason, that you don’t want to override changes made by (cms) end users. You might want this for QA at the moment, but then you might want to remove your repository, like when developing locally.
Although this is just for the content part, configuration like hst:pages etc. should be reloaded automatically, since they’re actually ‘owned’ by the developers. Although all pages within the workspace are considered content, which will not be automatically reloaded.