​
Overview

Preview Environments in KoalaOps provide ephemeral environments that mirror production configurations. They enable developers to test features and validate changes before merging into the main branch.

​
Key Features

  • Manual Provisioning: Environments are created manually through the UI or API.
  • Isolation: Each preview environment runs independently to prevent conflicts.
  • Integration with CI/CD: Seamlessly connects with existing pipelines to deploy test builds.
  • Auto Turn-Off and Removal (Coming Soon): Automatically turns off and removes environments that haven’t been used for an extended period, saving resources.

The Preview Environments interface simplifies environment management. Below are the main components:

  1. Environment List:

    • Environment: The unique identifier for each preview environment (e.g., “preview-20240906t1258”).
    • Namespace: Namespace associated with the environment.
    • Deployed Services: Number of services currently deployed.
    • Actions: Options to delete or manage the environment.

  2. Create New Environment:

    • Input fields include:
      • Environment ID: A unique identifier automatically generated.
      • Environment Blueprint Name: Specifies the configuration template.
      • Cluster: The target cluster for deployment.
      • Top Domain: Domain for ingress routing.

  3. Configuration:

    • Allows users to select the default cluster and ingress domain for the organization.

  4. Environment Variables and Secrets:

    • Blueprint Templates: Every service has a predefined template of environment variables and secrets. These are automatically applied to every new preview environment by default and can be edited in the “Env Vars & Secrets” section of every service.
    • Environment-Specific Overrides: After creating an environment, users can modify its specific variables and secrets in the same section by selecting the relevant environment from the dropdown.

  5. Service Deployment in a Preview Environment:

    • Purpose: This page allows users to choose which services to deploy in the preview environment, offering granular control over testing scenarios.
    • Fields:
      • Service Name: The name of the service available for deployment.
      • Deployed Image: Indicates the specific image currently deployed for the service.
      • Ingress Host: The host URL used to access the deployed service.
      • Config Branch: The branch of the configuration repository used for deployment.
      • Code Branch: The branch of the code repository used for deployment.
      • Image Tag: Specifies the image version for deployment.
      • Build New Image: Option to trigger a new image build for the service.
      • Actions: Includes options to delete or view service details.
    • Batch Deployment: Users can select multiple services and deploy them simultaneously by selecting the desired services and clicking the “Deploy” button.

​
Static vs. Preview Environments

​
Static Environments

Static environments, such as dev, QA, and Staging, are persistent and typically shared among teams. They are used for ongoing development workflows and testing across the organization.

  • Characteristics:
    • Always available and maintained.
    • Shared by multiple developers and QA teams.
    • Used for integration tests, bug fixes, or staging deployments before production.
  • Challenges:
    • Potential for conflicts if multiple teams use the same environment.
    • Limited flexibility for testing unique configurations.

​
Preview (Ephemeral) Environments

Preview environments are temporary, on-demand environments that developers or QA engineers can create to test any combination of services and their versions, including recent changes.

  • Characteristics:
    • Created manually or on demand by individual developers or QA engineers.
    • Isolated to prevent interference with others’ work.
    • Ideal for validating changes without impacting shared environments.
  • Advantages:
    • Test any combination of services and configurations.
    • Ensure recent changes don’t disrupt others.
    • Clean up automatically when no longer needed.

​
Technical Differences

  • Static Environments:
    • Backed by long-lived infrastructure, typically with fixed configurations and shared resources.
    • Changes are incremental and carefully controlled.
  • Preview Environments:
    • Provisioned dynamically.
    • Configurations are highly customizable for specific testing needs.
    • Designed to spin up quickly and tear down after use, minimizing resource usage.

​
How It Works

  1. Triggering a Preview Environment:

    • Preview environments are created manually by the user through the KoalaOps UI or API.

  2. Deploying Services:

    • Services are deployed using predefined configurations, and secrets and environment variables are injected securely.

  3. Collaboration & Testing:

    • Teams can access the preview environment to test changes.

  4. Automatic Cleanup (coming soon!):

    • When the environment is no longer needed, it can be deleted to free up resources.

​
Best Practices

  • Use descriptive and consistent naming for environments to improve organization.
  • Monitor resource usage regularly to avoid unnecessary costs.
  • Integrate automated tests to maximize efficiency.
  • Utilize blueprint templates to ensure consistency across environments while allowing for environment-specific customizations and usage of resources such as DBs and Cache by leveraging prefixes.
Static EnvironmentsControl Plane