Managing different environment

A Comprehensive Tutorial

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 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 work in an embed context

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

• Not compatible with stored data

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: Using Toucan's Import/Export Script for App Migration

This strategy leverages Toucan's internal Import/Export script to transfer applications between environments, providing a robust solution for production data isolation scenarios.

Implementation Overview

1. Update the Preproduction App in staging mode

2. Once validated, publish the preproduction App

3. Ask your CSM to run Toucan's Import/Export script to migrate the application from preproduction to production

   • The process maintains all configurations and customizations during transfer

4. Publish the production App after migration

How to Access the Import/Export Script

Currently, the Import/Export script is an internal Toucan tool that requires assistance from your Customer Success Manager (CSM):

• Reach out to your dedicated CSM when you need to migrate an application

• Provide details about the source and destination environments

• Your CSM will coordinate the migration process with Toucan's technical team

Note: Toucan is considering making this tool directly available to users in the future, which would allow for self-service migrations between environments.

Pros

• Provides complete production data isolation

• Ensures exact replication of your validated application

• Eliminates manual file transfer errors

• Handles complex configurations automatically

• Maintains version history and audit trail

Cons

• Currently requires CSM involvement (not self-service)

• Migration scheduling depends on CSM availability

When to Choose This Strategy

Choose this approach when:

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

• You need an exact replica of your preproduction environment in production

• You want to minimize the risk of manual transfer errors

• You can coordinate migration timing with your CSM

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

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: Strategy 3 (Import/Export Script)

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