Multi-environment Management

A Comprehensive Tutorial

Introduction

Managing multiple environments is a crucial practice for organizations that need to maintain separate spaces for development, testing, and production. This tutorial will guide you through the process of setting up and managing multiple environments in Toucan, helping you ensure good user experience, maintain data security, and establish a reliable workflow.

Understanding Multi-Environment Management

Why Set Up Different Environments?

There are two key reasons to implement multi-environment management:

1. Ensure a Good User Experience

   • Validate changes before they're visible to end-users

   • Test new features without affecting the production environment

2. Ensure Data Security

   • Restrict app-builders' access to sensitive production data

   • Minimize impact of potential data breaches (e.g., if a hacker gains access to an app-builder login)

Types of Environments

1. Development Environments (Test/Dev/Sandbox/Hotfix)

   • Used by app-builders to draft and test solutions

   • Isolated from end-users

2. Beta Environments

   • Used by privileged end-users to test solutions before moving to production

   • Note: One environment can function as both a beta and pre-production environment

3. Pre-Production Environments

   • Used to create the next version of the production environment

   • Should be identical to the next version of the production app before validation

4. Production Environments

   • The final product accessible to all end-users

   • Should be stable and thoroughly tested

Implementation Strategies

We'll explore three main implementation strategies for multi-environment management in Toucan. Choose the approach that best aligns with your organization's needs, infrastructure, and security requirements.

Strategy 1: Duplicated Stories in a Single App

This strategy is ideal for teams that need a simple validation workflow without requiring data isolation.

Implementation Steps

1. Duplicate a story in Staging, and set its visibility to "Hidden in production"

2. Once the story is validated: a. Set the visibility of the copy to "Public" (or "Customized Visibility") b. Delete the original story c. Publish the changes

Pros

• Adds a layer of confirmation for design changes

• Relatively easy to set up and maintain

• Works with any data isolation setup (both Load and Live Data, with variabilized queries or permissions)

Cons

• May lead to human error if there are frequent changes or multiple app-builders working on the same application

• Does not allow for production data isolation

When to Choose This Strategy

Choose this approach when:

• You have a small team working on the application

• You don't need to isolate production data

• You want a lightweight approach to validate changes

Strategy 2: Embedded Dashboards & Variabilized Queries

This strategy uses embedded dashboards and variabilized queries to manage environments, and is suitable for Live Data setups.

Implementation Steps

1. Create a new preproduction story in Staging with a variabilized query that points to the right database depending on user attributes

   • Set default values to display data even without attributes (allows app-builders to visualize their work in staging)

2. Publish the story

3. Add the story to a newly created Dashboard embedded in a pre-production environment

4. Once the new Dashboard is validated, replace the alias of the current embedded Dashboard in production with the alias of the new one

5. Delete the former Dashboard and the stories feeding it

Pros

• Provides a thorough validation process

• Relatively easy to maintain once set up

• Allows for limited updates

• Compatible with beta-users (if they have access to the Client Pre-production environment)

• Compatible with token-in-token authentication for production data isolation

Cons

• Not compatible with platform usage

• More maintenance intensive with single item integration

When to Choose This Strategy

Choose this approach when:

• You need a more rigorous validation process

• You're working with Live Data

• You need to test with beta users

• You need to isolate production data through token-in-token authentication

Strategy 3: Duplicated Apps & Load Data

This strategy involves duplicating applications at various levels (app, instance, or server) and is suitable for Load Data scenarios where production data isolation is required.

Implementation Steps

1. Update the Preproduction App in staging mode

2. Once validated, publish the preproduction App

3. Download the Preproduction App files (front_config in Load data, front_config, etl_config, and queries in Live Data or mixed configuration) from the preproduction environment

4. Upload the files to the production environment to replace the existing production files

   • Note: This step can be automated using Toucan's public API

5. Publish the production App

Variations

• App Duplication: Duplicate apps within the same instance

• Instance Duplication: Duplicate apps across separate instances ($)

• Server Duplication: Duplicate apps across separate servers ($$)

Pros

• Allows for production data isolation in a Load data configuration

• Provides a thorough validation process

• Can be automated using Toucan's public API

Cons

• Infrastructure heavy:

  • App isolation: risk of reaching total data limit on one instance, leading to refresh data issues

  • Instance or Server isolation: additional costs

• Partial updates of the App are maintenance intensive

• May not be compatible with Toucan V3 (to be confirmed)

When to Choose This Strategy

Choose this approach when:

• It's critical to isolate app-builders from production data

• You have validated that your infrastructure can support it

• You have the resources to maintain multiple environments

Best Practices for Multi-Environment Management

Data Isolation

You can variabilize data access at multiple levels:

• Host level

• Database level

• Schema/Table level

• Column level

Naming Conventions

When using duplicated stories or dashboards:

• Establish thorough naming conventions to avoid confusion

• Consider adding environment identifiers (e.g., "DEV_", "PREPROD_", "PROD_")

• Include version numbers when appropriate

User Access Control

• Use user rights to control access to different layouts

• Restrict access to staging/development environments to app-builders only

• Manage access to beta environments for selected testers

Monitoring Data Limits

• Be aware of stored data limits, especially when duplicating dashboards or stories

• Monitor data usage to prevent reaching limits that could affect performance

Conclusion

Multi-environment management in Toucan helps ensure both a great user experience and proper data security. By selecting the right strategy for your needs, you can create a workflow that balances ease of use, security, and maintenance requirements.

Remember that the best approach depends on your specific requirements:

• For simple validation without data isolation concerns: Strategy 1 (Duplicated Stories)

• For Live Data with validation and limited data isolation: Strategy 2 (Embedded Dashboards & Variabilized Queries)

• For complete production data isolation in Load Data: Strategy 3 (Duplicated Apps)

Consult with your Toucan representative if you need help determining the best strategy for your specific use case.