Promote a Design from Staging to Production
Categories:
A pipeline is only as trustworthy as its boundaries. In this tutorial you build two stages of one in a single organization: a staging workspace and a production workspace, each with its own team and its own environment. You put a design in staging, promote it to production, deploy it to the production environment from Kanvas, and read the production workspace’s activity log to confirm every change and who made it.
By the end you know what each object controls:
- A workspace is a boundary. It decides where a design lives and which teams reach which connections.
- An environment is a deploy target: a named group of connections.
- A team assignment gives read-only access to connections. It does not give access to designs.
Before you begin 🔗
- You have a Layer5 Cloud account and work in an organization where your role holds the permissions below. Organization Admin and Workspace Admin hold all of them.
- The organization has at least one connection, such as a Kubernetes cluster. Two connections, one per stage, make the separation clearer, but one works: a connection can belong to more than one environment.
- The organization has a team for each stage, or one team you assign to both. To create teams, see Manage Teams.
- To complete step 7, you run a Meshery Server that holds the cluster connection. The hosted kanvas.new site does not deploy designs.
- You own a design. If you do not, clone one with Start from a Catalog Design.
Each step needs a specific permission. The table shows which built-in roles hold each one:
| Permission | What it allows | User | Team Admin | Workspace Admin | Org Admin | Provider Admin |
|---|---|---|---|---|---|---|
| Create Workspace | Create new workspace | Not granted | Not granted | Allowed | Allowed | Allowed |
| Assign team to workspace | Add new team to workspace | Not granted | Not granted | Allowed | Allowed | Allowed |
| Create Environment | Create a new environment | Not granted | Not granted | Allowed | Allowed | Allowed |
| Assign connections to environment | Add new connections to environments | Not granted | Not granted | Allowed | Allowed | Allowed |
| Assign environment to workspace | Add new environment to workspace | Not granted | Not granted | Allowed | Allowed | Allowed |
| Assign Designs to Workspaces | Assign designs to workspaces | Not granted | Not granted | Allowed | Allowed | Allowed |
Confirm that the organization switcher shows the organization you intend. Every workspace and environment you create belongs to that organization permanently.
1. Create the staging and production workspaces 🔗
Create two workspaces in your organization and name them staging and production. Layer5 Cloud does not require unique names, so check the workspace list first and pick names nobody else in the organization uses.
Each new workspace starts empty: no teams, no environments, no designs. Every member of your organization can already see both workspaces in the list. Visibility is organization-wide; what a workspace grants comes from what you assign to it next.
2. Create an environment for each stage 🔗
Create two environments named staging and production. Assign a connection to each: your staging cluster to the staging environment and your production cluster to the production environment. If you have one connection, assign it to both.
An environment is the unit you deploy to. Grouping connections this way means that later, choosing where a design runs is one choice, not a list of clusters.
3. Give each workspace its environment 🔗
Assign the staging environment to the staging workspace and the production environment to the production workspace.
A workspace never holds connections directly. It holds environments, and the environments hold connections. This step makes each stage’s connections reachable from its workspace.
4. Assign a team to each workspace 🔗
Assign your staging team to the staging workspace and your production team to the production workspace. Each team must belong to the same organization as the workspace.
Assigning a team completes a chain: team member, to team, to workspace, to environment, to connection. Every member of the production team can now read the production connection and its credential. That access is read-only; only the connection’s owner can modify or delete it. Remove any link in the chain and the access ends.
5. Put your design in staging 🔗
Assign your design to the staging workspace. When you look for designs to add, the list offers only designs you own that are not already in the workspace.
The design is now listed under your organization through the staging workspace. The staging team cannot open it, though. A team assignment grants connection access, not design access, so a private design stays private. Keep that in mind for step 8.
6. Promote the design to production 🔗
Assign the same design to the production workspace.
Now look at the staging workspace: the design is gone. A design lives in at most one workspace, so assigning it to production moved it there. Promotion is a move, not a copy, which means there is exactly one current version and one place to find it.
Layer5 Cloud checks one permission for this move: Assign Designs to Workspaces in the production workspace’s organization. Anyone who holds it can promote, so grant it only to the people who should decide what reaches production.
7. Deploy to the production environment 🔗
Open the design in Kanvas and deploy it. The deploy action offers environments from your organization’s whole list at the moment you deploy. It does not limit the list to the design’s workspace, so select the production environment yourself. For the deploy options, see Deploy a Design.
The workspace decided where the design lives. The environment you choose now decides where it runs. Those are two separate decisions, and keeping them separate is what lets one design move through stages.
8. Let the production team read the design 🔗
The production team can reach the production connection but still cannot read your private design. To give them access, share the design with the people who need it. See Share a Design.
9. Confirm who did what 🔗
Open the production workspace’s recent activity. It lists each change recorded against the workspace, including the environment assignment, the team assignment, and the design assignment from this tutorial, each with the email address of the person who made it. Reading the activity log requires the View Workspace permission.
Use this log whenever you need to answer who promoted a design and when.
Roll back 🔗
To roll back, assign the design to the staging workspace again. It leaves production the same way it left staging, and the staging workspace’s activity log records the assignment.
What you built 🔗
| Object | Staging | Production |
|---|---|---|
| Workspace | staging | production |
| Environment (deploy target) | staging, with the staging connection | production, with the production connection |
| Team access | Read-only access to the staging connection | Read-only access to the production connection |
| Design | Lived here first | Lives here now, deployed to the production environment |
Next steps 🔗
- Workspaces explains the full access chain and lifecycle rules.
- Environments explains deploy targets and connection access.
- Manage Workspaces covers editing, removing members, and deleting workspaces.
Related Reading
- Build a GCP Data Pipeline Design
- Collaborative Editing
- Deploy AWS EC2 Instances
- Deploy Azure Resources
- Deploy Cassandra with a StatefulSet
- Deploy WordPress and MySQL with Persistent Volumes
