# Advanced: Isolating Development, Test, and Production Environments For enterprises with complex deployment scenarios or strong compliance requirements, PixieBrix's Team [Access Control](/managing-teams/access-control.md) 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](/managing-teams/creating-a-team.md)): 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](/enterprise-it-setup/authentication.md) * User Provisioning: [Setting Up SAML/SSO](/enterprise-it-setup/authentication/setting-up-saml-sso.md) and/or domain capture * Authorization: Default Role: Restricted (see [Access Control](/managing-teams/access-control.md)) * 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](/managing-teams/access-control.md) * 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](/integrations/advanced-custom-integrations.md) 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](/integrations/advanced-custom-integrations.md). ### 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](/deploying-mods.md) for more information on deploying mods --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.pixiebrix.com/managing-teams/advanced-isolating-development-test-and-production-environments.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.