What is the best way to deploy through different Aperture Environments, dev -> uat -> prod?

Ryan Chapman
Ryan Chapman Member
edited August 9 in Support

We have the following structure for some of our processes (there will also be a prod but the structure will be identical to below):

image-9b24d1c1be324-4fd8.png

The idea is that we have a space where all of the core datasets reside - from these, views are created. And these views are shared and used within any workflows we create in different spaces.

The underlying dataset for each Aperture instance / environment for these views may vary, pointing to different S3 locations using external systems. The dataset name, schema and view set up will be the same though (and external system name will be the same, just pointing to a different S3 account / location) - i.e. we have dev test data vs live data with the same schema in different AWS accounts.

I have managed to achieve this in theory by creating a solution with the views in the data space and workflow space. Subsequently remapping the view to the different dataset and publishing. Whenever I then release a workflow to the workflow space it is still able to see the view (and works as expected as long as I don't create a solution with this view in, otherwise the version will revert and the source will need remapping).

A few aspects that concern me with the method I mentioned is

  1. If we have a new space using the same views, will we need to deploy that as a Solution to be able to see the views? and if so, their version will be reverted and need remapping again.
  2. If we have 100 datasets, this will require a manual remap of 100 views.

Tagged:

Answers

  • Josh Boxer
    Josh Boxer Administrator

    Sharing a comment from a discussion here for reference:

    "suggest splitting the two. So one package is the source dataset and view, promote this through the other environments changing the source dataset for each view. Then the second package is all the consuming spaces, these can then be promoted through separately. Changes to the consuming spaces/workflows would then be promoted as changes occur"

Categories