Over time, you may want to begin pushing updates to your GoodData workspaces for a variety of reasons (ie. adding new dashboards and insights, updates to the LDM, implementing new GoodData product features, etc). To deploy updates safely, we want to focus on a few key points:
The ability to programmatically deploy updates in a timely manner.
Testing updates before releasing to Production workspaces.
Maintaining backups of Production workspaces, and the ability to easily return to a former state.
Minimal downtime and disturbance to clients during production releases.
To account for future updates, we strongly recommend maintaining 3 servers, Development, QA and Production, each running GoodData.CN. This way, Development can be used as a sandbox for creating updates, QA is used to safely test those changes, and Production can maintain a clean, client facing status throughout development.
Using JSON Layouts for Workspace Promotion
JSON layouts are a solution for quickly submitting consistent workspace configurations between environments. Older versions of a layout also act as back-ups for that workspace’s configurations. These older versions can be easily reapplied if needed (please note that changes in the underlying database tables may cause issues when reverting layouts). JSON layouts can also be released for individual workspaces, reducing the scope of release risk.
For maximum flexibility, create a JSON layout for each version of a workspace. New versions of workspaces’ layouts can be promoted from Development up to QA for testing, and later to Production. Old versions can be maintained on the servers to act as back-ups, and each JSON layout generally costs minimal memory.
Note that Workspace IDs may change between environments (illustrated below). In order to apply a JSON layout to the correct workspace, you may need a metadata log that matches layouts to workspaces for each of your environments. Alternatively, creating workspaces through the GoodData API allows you to define the workspace ID, ensuring consistent workspace IDs between environments .
Below is an illustration of how JSON layouts may be organized between your various workspaces and environments.
Backups are only maintained in the Production environment.
Workspace 1 has its 3rd iteration productionalized, and a 4th iteration is actively being worked on and tested.
Workspace 2 is maintaining V1.
Workspace 3 has its 2nd iteration productionalized, with V3 in testing, and work has started to develop V4.
Workspace 4 has its 3rd iteration productionalized, and its begun development on V4. In the case that QA on V3 requires more development work, Development would need to revert back to V3, and development of V4 would be paused.
Please note that during Production releases of new layouts, both GoodData.CN and the workspaces to be updated can stay online. Still, it’s best to communicate with the clients whose workspaces will be affected when the production release should occur and that the end users will need to refresh their browser to see the new layout.
For more information around configuring your own JSON layout file, see here.
Promoting with Hierarchical Child Workspaces
In the above image, we were only illustrating the promotion of independent, parent workspaces. GoodData.CN also allows you to create child workspaces that inherit the LDM, measures, insights, dashboards, and entities from a designated parent workspace. Unlike their parent workspaces, child workspaces do not receive their own dedicated JSON layout. Instead, the items required for child workspace promotion are:
Workspaces file: A list of the workspaces found in the domain, along with metadata pointing child workspaces to their parents
Data Filter file: Metadata about the Data Filters for limiting available data to Child Workspaces.
Both files can then be promoted along with the parent workspace JSON layout files, and applied via API to GoodData.CN. Similar to the JSON layout files, we recommend keeping versioned copies of both these files to use as potential backups.
The workspaces and data filter files both require alignment of Workspace IDs on the environment they are applied to. As a result, if your parent workspace IDs are different between environments, you will need to update your workspaces and data filter files based on the environment.
In the above image, the ws-layout (workspaces) file was updated to add a Child workspace off of Workspace 1.
Please note that changes made to a parent workspace will immediately be inherited by its children workspaces.
Look here for more information on Hierarchical workspaces in GoodData.CN.