---
sidebar_position: 5
title: Environments and controlled rollout
sidebar_label: Environments & rollout
description: Release components through your own environments, see drift from production at a glance, and target versions to user segments with A/B splits — all without deploying your application.
keywords: [release environments, staged rollout, feature rollout without deploy, ui a/b testing, user segmentation, deployment drift, release management, controlled release]
---
# Environments and controlled rollout

A change to your UI should go through the same gates as any other release. Myop gives every component a
release path through **your environments**, and lets you decide **who sees which version**, with no
application deploy at any step.

## Your environments, one board

Define the environments your organization uses (for example development, staging and production). The
**Rollout** board shows every component and the version deployed to each environment in one table.

- **Choose and batch-deploy.** Pick a version per environment, queue several changes, deploy them
  together.
- **See drift.** Environments whose version differs from production are flagged, so nothing reaches
  production by accident and nothing is forgotten in staging.
- **Recent and pending changes** are marked, and you can flag an issue on a specific deployment.

## Target versions to segments

With **Experiences**, the version a user sees can depend on who they are:

- **Segments** with rule-based targeting, for example by country, device or user group.
- **A/B splits** inside a segment, by percentage.
- **Sticky assignment**, so a user stays in the same group across sessions.
- **Fallback versions** for users who match no segment.
- Each published experience is an **immutable release**.

## Learn more

- [Rollout](/docs/dashboard/rollout): the deployment board, step by step
- [Experience Builder](/docs/dashboard/experience-builder): segments, A/B splits and variants