# Advanced: Isolating Development, Test, and Production Environments

For enterprises with complex deployment scenarios or strong compliance requirements, PixieBrix's Team [access-control](https://docs.pixiebrix.com/managing-teams/access-control "mention") can 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](https://docs.pixiebrix.com/managing-teams/creating-a-team "mention")): 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](https://docs.pixiebrix.com/enterprise-it-setup/authentication "mention")
* User Provisioning: [setting-up-saml-sso](https://docs.pixiebrix.com/enterprise-it-setup/authentication/setting-up-saml-sso "mention") and/or domain capture
* Authorization: Default Role: Restricted (see [access-control](https://docs.pixiebrix.com/managing-teams/access-control "mention"))
* 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](https://docs.pixiebrix.com/managing-teams/access-control "mention")
  * 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](https://docs.pixiebrix.com/integrations/advanced-custom-integrations "mention") 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

{% hint style="info" %}
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 *configuration*s (providing hostnames, API keys, and secrets) will be configured per-environment
{% endhint %}

*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

{% hint style="info" %}
A Mod Promotion interface is available in early access to Enterprise Customers. Contact your account representative or [support@pixiebrix ](mailto:support@pixiebrix.com)to enable for your team
{% endhint %}

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

{% hint style="info" %}
A Mod Promotion interface is available in early access to Enterprise Customers. Contact your account representative or [support@pixiebrix](mailto:support@pixiebrix.com) to enable for your team
{% endhint %}

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](https://docs.pixiebrix.com/integrations/advanced-custom-integrations "mention").

### 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](https://docs.pixiebrix.com/deploying-mods "mention") for more information on deploying mods