Release Brick

The release brick creates master workspaces for one or more segments within a data product based on a predefined template called 'Development master workspace'. If the segments or the data product do not yet exist, the release brick creates them as well.

The Development master workspace is a workspace that is created in advance and set up according to your needs: it contains required dashboards, reports, metrics, and so on. The master workspaces created based on the Development master workspace inherit all the objects from it.

Each execution of the release brick creates a new version of the segment's master workspaces instead of changing the current ones.

For information about how to use the brick, see How to Use a Brick.

Contents:

Prerequisites

Before using the release brick, make sure that the following is true:

  • A domain is implemented at your site, and a domain admin exists.
  • The Development master workspace with the content that needs to be released is created.
  • You have a Data Warehouse (ADS) instance, and the domain admin has admin rights to this instance.

How the Brick Works

The release brick accesses the Development master workspace to retrieve all metadata (for example, logical data model, processes, metrics, reports, and dashboards). On the Data Warehouse instance, the release brick creates the lcm_release table (the table where the latest segment master workspace IDs and versions are stored).

If the user who executes the release brick does not have access to the Development master workspace (for example, it is located in a different domain), use the 'development_client' parameter to specify credentials of a user with access to the Development master workspace.

The brick creates new master workspaces in the domain and copies the dashboards and the objects referenced in those dashboards (reports, metrics, and so on) from the Development master workspace to those master workspaces. If the 'production_tags' and 'transfer_all' parameters (see Parameters) are set up, the brick copies additional objects as well according to how these parameters are configured.

If the segments did not exist before you run the release brick, the release brick creates them according to your specification.

Input

The release brick does not require any input besides the parameters that you have to add when scheduling the brick process.

Parameters

When scheduling the deployed brick (see How to Use a Brick and Schedule a Process on the Data Integration Console), add parameters to the schedule.

NameTypeMandatory?DefaultDescription

organization

string

yes

n/a

The name of the domain where the brick is executed

segmentsarrayyesn/a

The segments that are going to be provisioned in the domain

You must encode this parameter using the 'gd_encoded_params' parameter (see Specifying Complex Parameters).

Example:

"segments": [
  {
    "segment_id": "BASIC",
    "development_pid": "e863ii0azrnng2zt4fuu81ifgqtyeoj21",
    "driver": "pg",
    "master_name": "Master BASIC ##{version}"
  },
  {
    "segment_id": "PREMIUM",
    "development_pid": "fuu81ifgqtyeoj21e863ii0azrnng2zt4",
    "driver": "pg",
    "master_name": "Master PREMIUM ##{version}",
    "ads_output_stage_uri": "/gdc/datawarehouse/instances/kluuu4h3sogai9x2ztn4wc0g8lta7sn8/schemas/default",
    "ads_output_stage_prefix": "out_"
  }
]
  • segment_id identifies the segment to be provisioned (for example, BASIC or PREMIUM). segment_id must match the following regex:
    [a-zA-Z0-9_\-]+
  • development_pid identifies the ID of the Development master workspace.
  • driver: pg indicates that the master workspace will be running on PostreSQL. If needed, you will be able to provision client workspaces on Vertica later (see Provisioning Brick).

  • master_name specifies the name of the segment's master workspace. master_name can contain the ##{version} placeholder.
  • ads_output_stage_uri specifies the URI of the Output Stage to use instead of the Output Stage in the Development master workspace. Use this parameter only when you have different development and production domains. The specified Output Stage must be in the production domain.
  • (Optional) ads_output_stage_prefix specifies the prefix to use in the Output Stage in the released segments that will override the default prefix.
tokensJSONyesn/a

The authorization token to use for creating the new master workspaces on PostgreSQL

If needed, you will be able to provision client workspaces on Vertica later (see Provisioning Brick).

You must encode this parameter using the 'gd_encoded_params' parameter (see Specifying Complex Parameters).

"tokens": {
  "pg": "{PostgreSQL_token}"
}
ads_clientJSONyesn/a

The Data Warehouse instance where the lcm_release table will be created

You must encode this parameter using the 'gd_encoded_params' parameter (see Specifying Complex Parameters).

Example:

"ads_client": {
  "jdbc_url": "jdbc:gdc:datawarehouse://my.company.com/gdc/datawarehouse/instances/kluuu4h3sogai9x2ztn4wc0g8lta7sn8"
}


CLIENT_GDC_HOSTNAMEstringyessecure.gooddata.com

The white-labeled domain name in the format of your.domain.com (for example, analytics.mycompany.com)

The parameter name is case-sensitive and must be written in uppercase.

CLIENT_GDC_PROTOCOLstringyeshttps

The protocol to transfer data over

The parameter name is case-sensitive and must be written in uppercase.

data_productstringno

default

The data product that contains the segments that you want to release. If the specified data product does not exist, it is created.

NOTE: If you have two or more data products, use the 'release_table_name' parameter (see further in this table).

release_table_namestringnoLCM_RELEASE

(If you have multiple data products stored in one Data Warehouse instance) The name of the table in the Data Warehouse instance where the latest segment's master workspace IDs and versions are stored

development_clientJSONnon/a

(If the user who executes the release brick does not have access to the Development master workspace; for example, it is located in a different domain) Credentials of a user with access to the Development master workspace

You must encode this parameter using the 'gd_encoded_params' parameter (see Specifying Complex Parameters).

Example:

"development_client": {
  "server": "https://your.domain.com",
  "username": "john.doe@yourdomain.com",
  "password": "${development_client_password}"
}

Example: Brick Configuration

The following is an example of configuring the brick parameters in the JSON format:

{
  "organization": "myCustomerDomain",
  "CLIENT_GDC_HOSTNAME": "analytics.myCustomDomain.com",
  "CLIENT_GDC_PROTOCOL": "https",
  "gd_encoded_params": {
    "segments": [
      {
        "segment_id": "BASIC",
        "development_pid": "e863ii0azrnng2zt4fuu81ifgqtyeoj21",
        "driver": "pg",
        "master_name": "Master BASIC ##{version}",
        "production_tags": ["transfer_to_basic", "at_release"]
      },
      {
        "segment_id": "PREMIUM",
        "development_pid": "fuu81ifgqtyeoj21e863ii0azrnng2zt4",
        "driver": "pg",
        "master_name": "Master PREMIUM ##{version}"
      }
    ],
    "tokens": {
      "pg": "01234567890123"
    },
    "ads_client": {
      "jdbc_url": "jdbc:gdc:datawarehouse://analytics.myCustomDomain.com/gdc/datawarehouse/instances/kluuu4h3sogai9x2ztn4wc0g8lta7sn8"
    },
    "development_client": {
      "server": "https://myCustomDomainDev.com",
      "username": "jane.dow@myCustomDomain.com",
      "password": "${development_client_password}"
    }
  },
  "development_client_password": "enter_as_a_secure_parameter"
}

Advanced Settings

This section describes advanced settings of the release brick.

Change these settings only if you are confident in executing the task or have no other options. Adjusting the advanced options in a wrong way may generate unexpected side effects.

Proceed with caution.

 Click here to view the advanced settings.
NameTypeMandatory?DefaultDescription
additional_paramsJSONnon/a

Additional parameters that will be added to all schedules in the master workspaces

You must encode this parameter using the 'gd_encoded_params' parameter (see Specifying Complex Parameters).

"additional_params": {
  "{parameter_1_name}": "{parameter_1_value}",
  "{parameter_2_name}": "{parameter_2_value}"
}
additional_hidden_paramsJSONnon/a

Additional secure parameters that will be added to all schedules in the master workspaces

You must encode this parameter using the 'gd_encoded_params' parameter (see Specifying Complex Parameters).

"additional_hidden_params": {
  "hidden_parameter_1_name": "${hidden_parameter_1}",
  "hidden_parameter_2_name": "${hidden_parameter_2}"
}
production_tagsarraynon/aSee production_tags.
transfer_allBooleannofalse

Specifies what objects should be copied from the Development master workspace to the master workspaces when the master workspaces are created

  • If not set or set to 'false', only dashboards and the objects referenced in those dashboards (reports, metrics, and so on) are copied from the Development master workspace to the master workspaces. If the 'production_tags' parameter is set up, the objects with the specified tags will also be copied.
  • If set to 'true', all objects (dashboards, KPI dashboards, reports, AD reports, metrics, and variables) are copied from the Development master workspace to the master workspace. The 'production_tags' parameter is ignored.
exclude_fact_ruleBooleannofalse

Specifies whether to skip number format validation (up to 15 digits, including max. 6 digits after decimal point).

  • If not set or set to 'false', number format validation is used.
  • If set to 'true', number format validation is skipped.

production_tags

By default, when master workspaces are being created based on the Development master workspace, only dashboards and the objects referenced in those dashboards (reports, metrics, and so on) are copied from the Development master workspace to the master workspaces.

If you want to also copy objects that are not referenced in the dashboards, use the 'production_tags' parameter.

To do so, add some tag to the objects that you want to transfer. Then, specify this tag as a value of the 'production_tags' parameter in the release brick:

"production_tags": ["some_tag"]

The brick will look for the specified tag in the objects' metadata and will copy those with the tag from the Development master workspace to the created master workspaces in addition to the dashboards and the objects referenced in them.

You can list multiple tags in the 'production_tags' parameter:

"production_tags": ["tag_1", "tag_2", "tag_3"]

You must encode this parameter using the 'gd_encoded_params' parameter (see Specifying Complex Parameters).


You can set up the 'production_tags' parameter in the following ways:

  • Globally for all segments:

    "gd_encoded_params": {
      "production_tags": ["tag1", "tag2", "tag3"],
      ...
    }
  • Per segment (segment-specific parameters take precedence over the globally set one):

    "gd_encoded_params": {
      "segments": [
        {
          "segment_id": "BASIC",
          "development_pid": "e863ii0azrnng2zt4fuu81ifgqtyeoj21",
          "driver": "pg",
          "master_name": "Master BASIC ##{version}",
          "production_tags": ["tag1", "tag2", "tag3"]
        },
        ...
      ]
      ...
    }

To copy all objects (dashboards, KPI dashboards, reports, AD reports, metrics, and variables) regardless of whether the 'production_tags' parameter has any tags specified or is set up at all, add the 'transfer_all' parameter to the brick's schedule and set it to 'true'.