Advanced: Isolating Development, Test, and Production Environments

Information on logically isolating development, testing, and production PixieBrix environments

For enterprises with complex deployment scenarios or strong compliance requirements, PixieBrix's Team Access Controlcan be too permissive/restrictive.

We recommend isolating development, test, and/or production environments using PixieBrix's Teams in these scenarios. PixieBrix teams are logically isolated and roles/authorization can be assigned per-team.

Architecture Overview

• Environments: Create a PixieBrix Team for each environment (see Creating a Team): Development, Test, and Production

  • PixieBrix Teams are logically isolated

• Team Membership

  • Production: User Principals are automatically assigned to the Production Team via SSO/SAML or domain capture.

  • Development/Test: Admin invites users to the team(s) by email address

• Authorization: Production is restricted by default, Development/Test environments are more permissive depending on requirements

• Mods: are developed under the Development team and then copied to the Test/Production team(s) via the Page Editor or Workshop. Shared team mods can only be deployed by the team that owns the mod.

• Package Definitions (e.g., bricks, integration definitions):

  • Developed under the Development team and then copied to the Test/Production team(s) via the Workshop

  • Production Package Definitions are shared with the Development/Test teams to be used in Mods

• Integration Configurations: integrations are configured separately for each team and selected when configuring the deployment

Team Configuration

Production Team Configuration

The Production Team should have production authentication/authorization rules configured:

• Authentication: Authentication

• User Provisioning: Setting Up SAML/SSO and/or domain capture

• Authorization: Default Role: Restricted (see Access Control)

• Package Scope: @myorg

• Integration Configurations: production API environment/credentials

Development/Test Team Configuration

• Authentication: authenticate using the identity provider for the Production Team

• User Provisioning: an Admin/Manager invites users to the team by email address

• Authorization: Default Role: see Access Control

  • Test: Restricted (or Member)

  • Dev: Developer (or Member/Restricted)

• Package Scope: you can choose any scope, but it's common to suffix the production team scope with the environment short name: @myorg-dev, @myorg-test

Mod Deployment Lifecycle Example

Here's an example of developing, testing, and deploying a Mod with a custom enterprise integration:

Integration/Mod Development in the Development Environment

1. In the Workshop, define the custom integration definition under the Development Team scope, e.g., @myorg-dev/integrations/custom

   1. Define an origin input on the integration, and provide that input as the baseURL. See Advanced: Custom Integrations for an example

2. In the Admin Console for the Development Team, configure a Team Integration Configuration on the Development Team, e.g., "My Custom Integration - Dev" and provide the development origin for the API, e.g., https://dev.my-enterprise-api.com/api/

3. In the Page Editor, build the Mod under the Development Team Scope, using the Development Team Configuration. Save the mod under the Development Team Scope, e.g., @myorg-dev/mods/example

Promoting the Integration Definition to Production

This section refers to promoting the integration definition to production for sharing across environments. The definition tells PixieBrix: 1) what information is required for the integration, 2) how to authenticate requests given that information The integration configurations (providing hostnames, API keys, and secrets) will be configured per-environment

In this example, we'll promote the Integration Definition package directly to Production.

1. In the Workshop, open the custom integration definition and copy the YAML

2. In the Workshop, create a new package:

   1. Paste the YAML from the development integration definition

   2. Change the scope to the production scope: @myorg/integrations/custom

   3. On the Sharing tab, share the brick with the Development and Test Teams

   4. Click "Save" to create/share the brick

Promoting a Mod to Testing

In this section, we recommend using the Workshop for promoting mods between environments. It is possible to use the Page Editor's "Make a Copy" feature for the initial promotion, but there's currently no way to transfer updates between existing mods quickly

1. In the Admin Console for the Testing Team, configure a Team Integration Configuration on the Test Team for the Integration Definition, e.g., "My Custom Integration - Test" and provide the testing origin for the API, e.g., https://test.my-enterprise-api.com/api

2. In the Workshop, open the mod definition and copy the YAML

3. In the Workshop, create a new mod package:

   1. Paste the YAML from the mod definition

   2. Change the scope to the testing scope: @myorg-test/mods/example

   3. Find & replace the development integration definition use (e.g., @myorg-dev/mods/example) with the production package id @myorg/integrations/custom

4. Activate/Deploy the mod to test it. During activation, be sure to select your test configuration (e.g., My Custom Integration - Test)

Promoting a Mod to Production

Follow the same instructions as for testing, but use the Production Team's scope. For example, the mod id will be: @myorg/mods/example

Frequently Asked Questions

Do multiple environments cost extra?

Separating environments does not cost additional money on an Enterprise plan. All teams fall under the same billing plan.

How can I call an API in different environments without rewriting mods?

Define a Custom Integration, and expose the base API URL as an option in the definition. The base URL can then be configured at activation/deployment time. For detailed information, see:Advanced: Custom Integrations.

Can I deploy a mod from shared from another team/environment?

No, currently you can only deploy mods that are either 1) public, or 2) owned by the team deploying the mod. The restriction ensures changes in a Dev/Test environment don't break Production mods.

See Deploying Mods for more information on deploying mods