Here we give you a feature-by-feature breakdown of how T&D (Test & Deploy) works in various areas of Pigment. In this article, we refer to source (Dev) environment and target (Prod) environment, and we talk about managed and unmanaged Applications. 

Managed Applications are the Applications in both the Dev and the Prod environments and are managed by T&D. However, unmanaged Applications refer to Applications that exist only in the Prod environment, and therefore they’re not managed by the T&D process.

What changes does T&D support?

Two main types of changes are managed by T&D:

• Structural changes. We talk more about this here, or if you need a refresher, see What are structural changes?
   
• Data changes. Although data isn’t managed through T&D, the data changes we’re referring to here is the data which originates from Dimensions, which is considered structural to the model. These are referred to as connected Lists, and you can read about them in Data Changes in Dimension Lists. 

Most features managed or supported by T&D allow changes such as creation, editing, deletion, or renaming in the source or Dev environment. However, these are not allowed in the target or Prod environment. Any changes made in the source environment appear on the Diff screen during deployment and are applied when the deployment is performed.

In this article, we refer to source (Dev) environment and target (Prod) environment.
 

Workspace-Level Features
 

Workspace and account settings: Workspace and account settings changes are not managed by T&D, and aren’t deployed from the Dev to the Prod environment. This means they can be edited directly in the Dev environment, as well as in the Prod environment.

This applies to:

• Members management:
  • Members along with their Roles, and Groups are managed by environment. This allows you to have different Members per environment, as well as giving them environment-specific roles.
  • Groups are also completely independent, allowing you to make specific decisions related to Groups your environment.
• Colors & Images:
  • All settings applied in the Color & Images section are also environment specific.
• Integration connections and API keys:
  • Changes to integration connections, such as creation, edition, deletion, are not managed by T&D. This means that connections can be set in both environments, and you can have different sets of data in Dev and Prod.
  • Changes to integration connections are not displayed in the diff screen, and are not pushed during deployment.
• Messaging apps:
  • Pigment recommends connecting your corporate messaging apps to the Prod environment, rather than to the Dev environment.
• Member profile, advanced features and notifications:
  • Because Members might not have access to the same set of features across environments, account settings remain environment specific.

Security and Member Management

• Security management:
  • Access rights Metrics, and their respective permissions, are managed by T&D like any other type of Metric or Block.
  • However, access rights and permission rules changes are not managed by T&D. For this reason, they can be created in both in the Dev and in the Prod environments to test different security setups.
  • When you choose a specific security setup, Members need to recreate the rules in Production by using the same Metrics as in Dev. This must be done after deploying the security Metrics.
• Member roles: As a reminder, Metric and Transaction List data isn’t pushed from the Dev to the Prod environment. The exception to this is data in Dimension Lists with the Keep Items in Sync setting enabled. As a result, Application Roles (in a Roles Dimension) are managed by T&D, while role assignments (in a Users Roles Metric) are not.

Application-Level Features
 

Certain Application-level features, in particular those that are managed by the Configure Application, Configure Calendar, and Create & delete folders permissions, are supported by T&D. As a result, they behave differently for Workspaces that have T&D enabled.

• Variables:
  • Variable actions, that is, creating, deleting, renaming and editing of types, are managed by T&D. This means that these actions need to be done in the Dev environment, and they cannot be done in Prod. They’re monitored and appear in the deployment screen, and are pushed when a deployment is performed.
  • However, the editing of variables values depends on the Variable type:
    • Static Variables. You must edit these variable values in the Prod environment. If you edit these Variables in Dev, the variable value in the Dev environment is not pushed to the Prod environment.
    • Dynamic and Member-based Variables. The referenced Metric is managed by T&D. Consequently, any changes made to these variables in Dev are automatically pushed to Prod, preventing direct edits in Prod.
       

      

       

• Folders:
  • Folders creation, deletion, renaming and position are managed by T&D.
• Calendar:
  • Calendar creation is managed by T&D.
  • It’s not possible to delete a calendar from a managed Application in the Dev and Prod environments.
• Library:
  • The Library (sharing Blocks and Views) is managed by T&D, meaning that it can be done only in the Dev environment.
  • Additionally, in Prod, it’s not possible to have unmanaged Applications referencing Blocks & Views from managed Applications. For example, enabling a Library from a managed Application in a unmanaged Application.
  • As a result, it’s very important to correctly define your T&D scope to make sure the correct dependencies are captured. For more information, see Map Out Your Test & Deploy Environments. 

Block-Level Features
 

A certain number of Block-level features, in particular those managed by the Configure Block permission, are supported by T&D. As a result, they behave differently for Workspaces that have T&D enabled. This includes the creation, renaming, and deletion of Blocks. In addition it includes actions that are allowed only in the Dev environment, and those monitored, displayed in the Diff screen, pushed during a deployment, and disallowed in the Prod environment.

• Settings. All Block settings are managed by T&D and changes can be made in the Dev environment.
• Properties. For Dimensions or Transaction Blocks, adding, editing, deleting, and renaming of Properties are managed by T&D. This also includes Item color management. Because this is done through the addition of the color Property, it can only be done in the Dev environment, and pushed to Prod through a deployment.
• List Items in Dimension Lists with Items kept in sync. Adding, removing, editing, and reordering of List Items is managed by T&D for these Dimension Lists. The diff screen indicates when List data has been edited. Actions related to Add List Items, Remove List Items, and Reorder List Items permissions are restricted to the Dev environment only.
• List Items in Dimension Lists with disconnected Items. The actions managed by the Add List Items, Remove List Items, and Reorder List Items permissions are allowed in both the Dev and Prod environments. This ensures that no data changes appear on the diff screen or be pushed during deployment.
   

  

• Formulas:
  • All formula changes, including adding or removing a formula, at the Block or Property level are managed through T&D. One exception to this is non-default Scenarios, which we discuss below.
  • Formulas are also pushed to the Prod environment when a deployment is performed. This means that any previously existing input on the Block is lost if overrides are not allowed on the Block.
  • To add a formula to an existing Block and retain inputs from the production environment, the Member must enable the Allow overrides option in the Block's settings. If not, a warning is displayed in the diff screen to ensure the person performing the deployment is aware of the consequences.
     

    

  • Default View: When you want to define a default View for a Block this should be done in the Dev environment, and then pushed to Prod. Any View that’s intended as the default View of a Block should first be created in Dev.
  • Convert Formula to Values: This feature is managed by T&D, meaning that the T&D deployment will remove the formula from the Production environment without copying its values. The Convert Formula to Values option is unavailable in any Application managed by T&D within the Production environment.

View-Level Features
​​​​​​​

Views features, managed by the Configure Public Views permission, has a specific behavior in T&D. While all View changes are monitored by T&D, the deployment of those, and Member permissions in Prod, behave differently.

• Public Views. Any View configuration change is monitored by T&D. Here’s what happens:
  • General concept. Views can be created in both Dev and Prod environments. Views created in Dev can be optionally deployed and updated, and Views created in Prod only stay in Prod.
  • Diff screen. In the diff screen, any Views that have the status Created, Updated (with the exception of the default View status), or Deleted appear in the Diff screen, provided that the Block to which they belong has also changed. All Views with these changes are automatically selected.
     

    

    The default View status is handled differently and is explained in Block-Level Features.

  • Push. All Views selected in the diff screen are pushed to the Prod environment.
  • Prod environment. All Views, whether there have been created in Prod or in Dev environments can be updated or deleted in the Prod environment. All Members with the Configure Public View permission can still create Public Views in Prod.
  • Views Features. All View features follow the behavior described above. However, there are some exceptions that aren’t pushed correctly to Prod. When using Items from Dimensions with disconnected Items through filtering, formatting, or specific page options (such as available or default Items), these changes won't be pushed correctly. This is because the Item references don’t exist in the Prod environment. In these cases, the Member needs to manually reproduce those specific changes in the Prod environment.
• Personal Views. Personal Views created in Dev are not displayed in the Diff screen and cannot be pushed to the Prod environment. These are considered end Members Views, and are being interacted with in the Prod environment. As a result, all Members can create personal Views in Prod.
• Boards.​​​​​​​ Any Board configuration change is monitored by T&D. Here’s what happens:
  • General concept. Boards can be created in both Dev and Prod environments, as well as a Test environment if you have one. You can select specific Boards that you have created or updated in Dev, and deploy them to Prod as needed. Boards created in Prod only stay in Prod.
  • Diff screen. When selecting a Board for deployment, all modified Views are automatically selected, and cannot be deselected.
  • Push. All Boards selected in the diff screen are pushed to the Prod environment.
  • Prod environment. All Boards, whether they have been created in Prod or in Dev environments can be updated or deleted in the Prod environment.
    ​​​​​​​Boards permissions are managed in each environment. If you want to change a Board in Prod then you need to have the Can Configure Board permission in Prod. This also applies to the Dev environment.
  • Boards Features. All Boards features follow the behavior described above. However, there are some exceptions that aren’t pushed correctly to Prod.
    • When defining or editing Board access configurations, these changes won’t be pushed to the Prod environment. In these cases the Member needs to manually reproduce those specific changes in the Prod environment.
    • When making changes to Action Buttons triggering imports in Boards, these changes won't be pushed to Prod. This is because, currently, import configurations aren't supported during deployment. In these cases, the Member needs to manually reproduce those specific changes in the Prod environment.
    • When using Items from Dimensions with disconnected Items through specific page options (such as available or default Items), these changes won't be pushed correctly. This is because the Item references don’t exist in the Prod environment. In these cases, the Member needs to manually reproduce those specific changes in the Prod environment.​​​​​​​

Imports, Automations & Scenarios

• Integrations. Integration connections are not managed and maintained separately in each environment.
• Import configurations.
  • Import configurations changes such as creating, editing, and deleting are not managed by T&D. This means that they are set in both environments, but are not displayed in the Diff screen, and are not pushed during a deployment.
  • In particular, this allows you to have different sets of data in the Dev and Prod environments.
• Automations. Changes to Automations, such as creating, editing and deleting, are not managed by T&D. This means that they are set in both environments, but are not displayed in the diff screen, and are not pushed during a deployment.
• Scenarios.
  • Changes to Scenarios, such as creating, editing and deleting, are not managed by T&D. This means that they are set in both environments, but are not displayed in the diff screen, and are not pushed during a deployment.
  • In particular, this allows Members to set their own Scenarios, even if they don’t have access to the Dev environment.
  • As a result, editing formulas is only restricted in the Default Scenario within the Prod environment. In all other Scenarios, formula editing is permitted.

Related Information

• Introduction to Test & Deploy
• Map Out Your Test & Deploy Environments
• Understand Structural Changes in Test & Deploy
• Perform a Deployment