Environment
An Environment manages and isolates resources for different stages of the Software Development Lifecycle (SDLC). Each Environment contains resources specific to that stage, and also allows you to configure specific security boundaries for resources external to Ascend, like any User-managed Vaults you may be connecting to.
Purpose​
Environments are essential for maintaining a structured workflow across different stages of the software development lifecycle. They allow teams to develop, test, and deploy data pipelines and other components without compromising the stability or integrity of the production environment.
Environment types​
Within Ascend, you can customize your environments based on your organization's needs. Commonly used environments include:
-
Development (dev): Used for building and testing new features or changes. This environment is the most flexible and is often used by developers to experiment, test code, and make adjustments without impacting live operations.
-
Staging (stage): Mirrors the production setup and is used for final testing and validation before deploying changes live. It helps catch issues that might not be visible in development but could affect production.
-
Production (prod): The live environment where actual data processing occurs and final outputs are generated. This environment is tightly controlled to ensure stability, performance, and reliability.
You can create as many environments as you need, and you can configure each environment to have its own set of Vaults, Workspaces, and Deployments. You may, for example, have a SOX and non-SOX setup in your company, each of which requires its own set of development, staging, and production environments.
Configuration and management​
Environments have very few configuration options, and are primarily used to manage the security boundaries for your resources. Rather, the configuration options are generally dictated by what you give that environment's Identity access to, such as a User-Managed Vault or Data Plane.
Clear separation between environments mitigates risks by isolating changes, allowing safe testing, and ensuring new features do not disrupt live processes. This separation supports robust Continuous Integration/Continuous Deployment (CI/CD) pipelines, improving development speed and quality.
Key features​
Environment identity​
For each Environment, Ascend provides a Service Account or Service Principal you authorize to access resources in your cloud account. These identities are available for AWS, Azure, and GCP. You can manage the resources accessed by each Environment through these Environment identities, allowing for explicit separation between development, staging, and production resources.
An example of this is if you are setting up an User-Managed Vault in your Environment. You would grant the Ascend identity access to the Vault in your chosen cloud provider. When Ascend needs to access secrets at runtime, Ascend will assume the Environment identity to access the Vault and retrieve the secret.
Vaults​
-
Environment Vaults: Environment Vaults are vaults that are managed by Ascend and are created alongside your Environment.
-
User-managed Vaults: You can also choose to manage your own User-Managed Vault by granting the Ascend identity access to a Vault in your cloud provider.
Workspaces and Deployments​
Workspaces and Deployments are launched in a specific Environment, and cannot be moved to another Environment once they are created. Typically, you will launch Workspaces in your Development Environment, as that is where you will build out your Ascend Flows. Deployments are typically launched in higher-level Environments, like Staging and Production, as these Environments are for either testing changes, or for running live Flows.
In rare cases, you can launch a Workspace in a Staging or Production Environment to make hotfixes or quick changes. However, it is generally recommended to follow the steps of the Software Development Lifecycle and promote changes from Development to Staging to Production.