Docs: Recommend environment & branch protection for deploy/delivery targets

Scenarios/DeliveryTargets.md

@@ -347,6 +347,12 @@ You can configure multiple trusted NuGet feeds for dependency resolution:
 - **Token expiration**: Regularly rotate your personal access tokens
 - **Compressed JSON**: Always use compressed JSON format for secrets to avoid masking issues
 
+#### Protect the environments used for delivery
+
+GitHub *environments* are the security boundary around the context secrets that AL-Go uses to publish your apps (for example `GitHubPackagesContext`, `NuGetContext`, `StorageContext`, `AppSourceContext`, or any custom `<DeliveryTarget>Context`). When a `DeliverTo<Target>` configuration targets an environment - or when you store the context secret as an *environment secret* - restrict which branches are allowed to deploy to that environment and require reviewers for sensitive targets (production feeds, AppSource, customer-facing storage). The `Branches` list on `DeliverTo<Target>` should match the environment's allowed branches so the two reinforce each other.
+
+For the available controls and step-by-step instructions, see the official GitHub documentation: [Managing environments for deployment](https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) and the [Deployment protection rules](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments#deployment-protection-rules) reference (including [Deployment branches and tags](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments#deployment-branches-and-tags) and [Required reviewers](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments#required-reviewers)).
+
 ### Limitations
 
 - **Fine-grained tokens**: GitHub Packages doesn't support fine-grained personal access tokens yet

Workshop/ContinuousDeployment.md

@@ -29,6 +29,12 @@ If your actual Business Central environment has a different name than your GitHu
 
 At this time, these settings cannot be added as environment variables, we might add this in the future.
 
+## Securing your deployment environments
+
+GitHub environments are the security boundary around your deployment credentials (the `AUTHCONTEXT` secret) and the workflow jobs that use them. Before you point an environment at a real tenant - and especially before you point it at production - configure *deployment branch restrictions* and other environment protection rules so that only approved branches can deploy and (for production) a human must approve each deployment.
+
+For the available controls and step-by-step instructions, see the official GitHub documentation: [Managing environments for deployment](https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) and the [Deployment protection rules](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments#deployment-protection-rules) reference (including [Deployment branches and tags](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments#deployment-branches-and-tags) and [Required reviewers](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments#required-reviewers)).
+
 ## Creating an AUTHCONTEXT that uses impersonation
 
 Easiest way to create an authentication context with impersonation for AL-Go for GitHub is to use the following PowerShell line from a machine with the latest **BcContainerHelper** module installed:

Workshop/PublishToProduction.md

@@ -7,8 +7,8 @@ If you follow the same process and setup an environment called PROD and add the
 | ![image](https://github.com/microsoft/AL-Go/assets/10775043/1008fcf4-ed2a-4cc1-a786-3b5cf6692266) |
 |-|
 
-> [!NOTE]
-> You can add protection rules to environments in GitHub, like which branches can deploy to this environment and which users should review every deployment to this environment as well.
+> [!IMPORTANT]
+> Before you point an environment at a real production tenant, restrict which branches are allowed to deploy to it and require reviewers for each deployment. See the official GitHub documentation on [Managing environments for deployment](https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) and the [Deployment protection rules](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments#deployment-protection-rules) reference (including [Deployment branches and tags](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments#deployment-branches-and-tags) and [Required reviewers](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments#required-reviewers)).
 
 By default, all environments will be picked up for **continuous deployment**, but production environments will be skipped unless you add the ContinuousDeployment setting from the previous chapter. The Deployment job will succeed, but looking into the step, you will see that the PROD environment is ignored: