From 53cf3596b10bfd7e8fe0019ac5231b94e13bab7a Mon Sep 17 00:00:00 2001 From: Oleksandr Pavlovskyi Date: Mon, 8 Dec 2025 12:02:57 +0200 Subject: [PATCH 1/3] feat: environment access --- docs/features/tags-environments.mdx | 9 +++++++++ rspress.config.ts | 2 ++ 2 files changed, 11 insertions(+) diff --git a/docs/features/tags-environments.mdx b/docs/features/tags-environments.mdx index 0fbc34a..3bc5030 100644 --- a/docs/features/tags-environments.mdx +++ b/docs/features/tags-environments.mdx @@ -335,3 +335,12 @@ Tags and environments integrate seamlessly with your existing [CI/CD pipelines]( Many teams configure their CI to automatically update a "latest" tag when tests pass, trigger staging deployments when code merges to main, and provide promotion tools for moving releases to production. Since everything works through Zephyr's API, you can integrate with any CI/CD system and create custom workflows that match your team's processes exactly. Learn more about [automation workflows](/features/automation). + +## Environment Access + +The Zephyr dashboard provides control deploy to environment. You can deploy with Zephyr to specific environment using env variable `ZE_ENV`. +For this you have to create `Application Tag` with condition `environment is {ENVIRONMENT_NAME}` and create `Application Environment` for this tag. +For example `environment is production` and build with zephyr using `ZE_ENV=production`. + +Also you can control who can update an environment using flag `Make environment protected` and section `Members`. +If checkbox is checked only users added direct or through team to members can update an environment. diff --git a/rspress.config.ts b/rspress.config.ts index f2df79f..92a2dad 100644 --- a/rspress.config.ts +++ b/rspress.config.ts @@ -92,6 +92,8 @@ const sidebar: Sidebar = { { text: 'Deployment Hooks', link: '/features/deployment-hooks', + }, + { text: 'Structured File Logs', link: '/features/file-logging', }, From 7ca11f3cb3cdf8b306047a626e39d53018475813 Mon Sep 17 00:00:00 2001 From: Oleksandr Pavlovskyi Date: Tue, 9 Dec 2025 12:32:45 +0200 Subject: [PATCH 2/3] feat: environment access --- docs/features/tags-environments.mdx | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/docs/features/tags-environments.mdx b/docs/features/tags-environments.mdx index 3bc5030..be904d4 100644 --- a/docs/features/tags-environments.mdx +++ b/docs/features/tags-environments.mdx @@ -336,11 +336,24 @@ Many teams configure their CI to automatically update a "latest" tag when tests Since everything works through Zephyr's API, you can integrate with any CI/CD system and create custom workflows that match your team's processes exactly. Learn more about [automation workflows](/features/automation). -## Environment Access +## Deploying to Specific Environments -The Zephyr dashboard provides control deploy to environment. You can deploy with Zephyr to specific environment using env variable `ZE_ENV`. -For this you have to create `Application Tag` with condition `environment is {ENVIRONMENT_NAME}` and create `Application Environment` for this tag. -For example `environment is production` and build with zephyr using `ZE_ENV=production`. +Zephyr now allows you to precisely control deployments to individual environments. To deploy to a specific environment, you can pass the `ZE_ENV` variable during your build process. For example: -Also you can control who can update an environment using flag `Make environment protected` and section `Members`. -If checkbox is checked only users added direct or through team to members can update an environment. +```bash +ZE_ENV=production pnpm nx run team-blue:build +``` + +To enable environment-targeted deployments: + +1. Create an Application Tag with the condition: environment is `{ENVIRONMENT_NAME}` +2. Create an Application Environment associated with that tag. + For example, if your environment name is `production`, you would set the tag condition to environment is production and run the build using `ZE_ENV=production`. + +### Managing Who Can Update an Environment + +You can also control who has permission to deploy or update each environment: + +- Enable the “Make environment protected” option on the environment settings page. +- Add individual users or teams under the Members section. + When protection is enabled, only the users or teams explicitly listed as members will be allowed to update that environment. This is especially useful for safeguarding production environments. From c69d6ef3783a6af3ece6d064052b516dd17e02f1 Mon Sep 17 00:00:00 2001 From: Oleksandr Pavlovskyi Date: Tue, 9 Dec 2025 12:33:11 +0200 Subject: [PATCH 3/3] feat: environment access --- docs/features/tags-environments.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/features/tags-environments.mdx b/docs/features/tags-environments.mdx index be904d4..ed602e7 100644 --- a/docs/features/tags-environments.mdx +++ b/docs/features/tags-environments.mdx @@ -356,4 +356,5 @@ You can also control who has permission to deploy or update each environment: - Enable the “Make environment protected” option on the environment settings page. - Add individual users or teams under the Members section. - When protection is enabled, only the users or teams explicitly listed as members will be allowed to update that environment. This is especially useful for safeguarding production environments. + +When protection is enabled, only the users or teams explicitly listed as members will be allowed to update that environment. This is especially useful for safeguarding production environments.