Page tree
Skip to end of metadata
Go to start of metadata

Life Cycle Management (LCM) as a feature is enabled for you by GoodData specialists. For more information, contact GoodData Support.

Contents:

Implementation Process

The following is the process that the GoodData specialists follow to implement LCM on your site. The implementation is done using the specific bricks found in Managing Projects via Appstore Bricks.

  1. Initial setup. Based on a predefined template called 'development master workspace', master workspaces are created for segments. If the segments do not yet exist, they are created as well.
    Brick involved: Release brick
  2. Client provisioning. Clients and their workspaces are created under the appropriate segments. The reports, dashboards, filters, LDM, ETL and metadata are deployed from the master workspace to the clients' workspaces within a segment. Obsolete clients and their workspaces are removed.
    Brick involved: Provisioning brick
  3. Synchronization / Release management. The segments' master workspaces and their clients' workspaces are synchronized by propagating the changes that you made in a master workspace (LDM, ETL, dashboards, and so on) to all the clients' workspaces within the corresponding segment.
    Brick involved: Rollout brick
  4. (Optional) User configuration. Users are added to the domain. Users are added/removed to/from a workspace. A user's information and/or role is updated.
    Brick involved: Users brick
  5. (Optional) User filter configuration. User access to the data in a workspace is configured based on data filters.
    Brick involved: User filters brick

This process is the recommended method for Managing Projects via Life Cycle Management.

Brick Configuration

GoodData specialists configure the bricks for you.

So that the GoodData specialists can configure the bricks properly, they will ask you to prepare input data for the bricks (see below in this section) and store it in one of the following locations:

The input data should be stored in the CSV format (when located on the staging area, Amazon S3 bucket or web) or be accessible via a query to Data Warehouse (when located in Data Warehouse).

Input Data for Release Brick

The release brick does not require input data.

Input Data for Provisioning Brick

The brick expects to receive the data about which client should be provisioned under which segment.

Set up your input data in the following way:

segment_idclient_idproject_title
basic_segmentclient_1workspace_one
premium_segmentclient_2workspace_two

If the 'project_title' column is missing from the input data, the workspace name is populated from the data in the 'client_id' column.

Note that client_id format can contain only the following characters:

  • Numbers
  • Lowercase and uppercase ASCII letters (a-z, A-Z)
  • Underscore (_)

With a maximum length of 255 characters. The client_id must be unique within a data product.

Input Data for Users Brick

The users brick expects to receive the data about users and their properties.

Set up your input data in the following way:

client_idloginfirst_namelast_namerole
client_1

john.doe@example.com

John

Doe

adminRole

client_2

anna.doe@example.com

Anna

Doe

adminRole

The values of the 'role' column (that is, the roles that users can have) can be:

  • adminRole
  • editorRole
  • readOnlyUser
  • dashboardOnly

The values in the 'login' column are case-sensitive and must be written in lowercase.

Correct: john.doe@example.com
Incorrect: John.Dow@example.com

Input Data for User Filter Brick

The user filters brick expects to receive data about what user should have what filter or permission.

Set up your input data in one of the following ways:

  • Column-based (the most used)
  • Row-based

To understand these formats, let's use an example.

Imagine that you have two users in your system, and you want to set up the following filters for them:

loginfilter

john@example.com

WHERE city ('San Francisco', 'Prague', 'Amsterdam')

anna@example.com

WHERE city ('San Francisco', 'Dublin')

In the column-based format, you input data would look the following:

logincityother_unused_value
john@example.com

San Francisco

x

john@example.com

Prague

y

john@example.com

Amsterdam

z

anna@example.com

San Francisco

x

anna@example.com

Dublin

z

Notice that multiple values for the filter are expressed by repeating the user. The brick will remove duplicates during processing.

In the row-based format, your input data would look the following:

john@example.com

"San Francisco", "Prague", "Amsterdam"

anna@example.com

"San Francisco", "Dublin"

Notice that this format of input data do not have headers since you do not know how many columns you are going to have.

See also:

  • No labels