QA testers face a dilema when validating new builds: they want to have real world test cases but it is difficult to recreate the actual Production content.
Content authors are creating (and publishing) new content within the Production Author all the time. The amount of content can be a lot! Some companies push 100s if not 1,000s of pages a day. How can a team of QA testers ensure that the new content being created works with the latest development builds being tested? What if there are breaking changes that are not covered by the test content generated within QA for testing purposes? These gaps will not be noticed until the latest build is pushed into Production!
What is the solution? Simple, migrate the actual Production content down into the QA environment!
However, migrating this content is not trivial. There are a couple of options (some to be covered in later posts). One method is to perform migrations with the command line VLT tool. This tool can be used to do regular syncs of PROD content down to your lower level environments (say, every Sunday at 2am) or on demand (directly before testing begins). You also have control over what content moves from PROD to DEV/QA and do not need to send the entire content repository but just a subset or a targeted content tree (example: /content/en_us/site/test) .
I have published a generic version of a vlt rcp the script I began to write for the initial migration of adobe.com back in 2012. I’ve been using this ever since that upgrade/migration (we went from 5.3 –> 5.5 and launched the very first CQ 5.5 site worldwide). The script can be found in our public gitlab repo. The variables within the script and how to use it are documented in the corresponding README file.
We typically would either run this script on demand (./vlt_rcp_content_sync.sh) or schedule it via a cron job to run at some regular interval. This should schedule it to run on the 1st and 3rd Sundays at 2am for example:
0 2 1-7,15-21 * * [ `date +\%u` = 7 ] && /<script_path_director>/vlt_rcp_content_sync.sh
Please feel free to use this script in your own AEM environments and let me know what you think!
