Visier Development and Production Environments

Learn about the software development lifecycle (SDLC) to make changes in your Visier tenants.

Overview

When making changes in your administrating tenant for your analytic tenants, it's important to test and validate your changes before publishing to production, where changes will take effect in your customers' tenants.

In this article, we recommend how to test, deploy, and maintain the application you've built with Visier.

Environments

Visier provides one development environment, optional validation environments, and one production environment per jurisdiction that you operate in.

  • Development: A safe environment to build and test changes. This environment is separate from your production environment.

    Caution: Do not upload customer data to this environment.

  • Validation: An optional environment to validate changes. If you don't use a validation environment, you can validate changes in the development environment. You may require more than one validation environment. Discuss your validation requirements with Visier during onboarding.
  • Production: The live version of your application. Limit user access to those who are trusted and expected to work in the live customer environment.

We recommend that you limit user access in environments to those who need to perform functions in those environments. You can control access to environments using Visier profiles and single sign-on (SSO). For more information, see Studio Profiles and Set Up Single Sign-On.

Example: Let's say you have 3 developers building your embedded Visier application. Developers A and B are responsible for building and testing their changes in development, and Developer C is trusted to approve the changes and promote them to production. In the scenario, you can give all 3 developers access to the development environment, but only assign Developer C access to production.

Each environment is a unique instance of Visier. Accordingly, each environment has its own SSO, embedded app config, embeddable domains, and API key.

Software development lifecycle

We recommend that you schedule and manage releases as a collection of changes.

  1. Make changes in a draft project in the development environment.
  2. Test your project changes.
  3. Publish the project to the development environment's production version.
  4. Optional: If you have validation environments, export your changes from the development environment and import them to the validation environment for testing.
    • Use the Production Versions API to export production versions from your development environment and then import the committed changes to a draft project in your validation environment. For more information, see Production Versions API Overview.
    • Use the Sources API to export sources from your development environment and then import the ZIP file containing the sources to your validation environment. For more information, see Sources API.
  5. Validate that the new production version is correct and stable.
  6. Repeat steps 1-5 for all projects that you plan to release to your production environment.
  7. Import development production versions to a draft project in your production environment. We recommend that you put all release-related changes in one project in the production environment, and then publish the project at a scheduled release time.
    • Use the Production Versions API to export production versions from your development environment and then import the committed changes to a draft project in your production environment. For more information, see Production Versions API Overview.
    • Use the Sources API to export sources from your development environment and then import the ZIP file containing the sources to your validation environment. For more information, see Sources API.
  8. Test your project changes.
  9. Publish the project to the production environment's production version.

Ideally, you have a change management system to track change requests and ticket numbers. Associating each project revision with a ticket number makes it easier to organize and track changes. Then, when you release a project to production, include a ticket number associated with the release ticket in your change management system.

Example: Let's say you have a scheduled release on August 23, 2024. In Visier, you have two major changes:

  • A new analysis for line managers.
  • A change to a metric's formula.

In this example, we recommend that you build and test each change in the development environment. In Project A, build the new analysis for line managers. After you're satisfied that the changes are correct and stable, publish Project A to the development environment's production version with a ticket number that correlates to a ticket in your release management system. In Project B, edit the metric's formula and validate that the new calculation works as intended. Then, publish Project B to the development environment's production version with a ticket number from your change management system.

After you validate that the new development environment production version is correct and stable, you can copy the committed changes from development to a draft project in your production environment. Again, test the changes in a draft project in the production environment. If all goes well, you'll be ready to publish the release project to production on August 23, 2024 as planned. When you publish the release project, don't forget to include a ticket number for the release!

Project changes

Based on your change management system, use one project per change ticket. For example, if you have a change request for three email push schedules, make all three changes in one project.

To test your changes, we recommend that your development environment has sample data that resembles your analytic tenants' data (but isn't customer data!). In a project, you can preview the project as an analytic tenant to test the changes. For more information, see Preview a Project.

To collaborate with other users on a project, share your project with those users to make changes and review the project. For more information, see Share a Project.

Note: You and other users can work in multiple projects simultaneously. If you make changes to the same objects in different projects, you must resolve conflicts before publishing the project.

To revert project changes, use the rollback feature. If you need to rollback a change in the production environment, rollback the entire release. If you find a blocking issue, we recommend that you reject the project and return to the development environment to correct the issue.

Global workspace changes

In the global workspace, changes take effect immediately. In the development environment, save your changes in the global workspace to test your changes in the production version immediately. For more information about the global workspace, see Studio Navigation.

To test changes to sources, we recommend that you clone the source, rename it TEST_[Source Name], and then, in a project, change mappings to point to the TEST_[Source Name]. This is an efficient way to test source changes without impacting your production sources. For more information, see Clone an existing source.

After validating global workspace changes in the development environment, you must replicate the changes in the production environment. You can use the Sources API to export sources from your development environment and import the sources into your production environment. For all other global workspace changes, you must replicate the changes manually.

To revert global workspace changes, you must manually revert each change.

Publish changes to multiple jurisdictions

To synchronize production environments between jurisdictions, such as US, CA, EU, and APAC, repeat steps 7 to 9 of the Software development lifecycle for all your jurisdictions.