Forum Discussion
CI/CD GitHub Deployment from Dev to UAT Synapse Workspace not Picking Up UAT Resources
Hello,
I am setting up CI/CD for Azure Synapse Analytics using GitHub Actions with multiple environments (Dev, UAT, Prod).
My Synapse resources are:
Dev: ************-dev, azcalsbdatalakedev, calsbvaultdev, SQL DB azcalsbazuresqldev / MetaData
UAT: ************-uat, azcalsbdatalakeuat, calsbvaultuat, SQL DB azcalsbazuresqluat / MetaData
Prod: ***********-prod, azcalsbdatalakeprod, azcalsbvaultprod, SQL DB azcalsbazuresqlprod / MetaData
I have environment-specific parameter override files like uat.json and prod.json. My GitHub workflows (synapse-dev.yml, synapse-uat.yml, etc.) deploy the Synapse publish artifacts (TemplateForWorkspace.json and TemplateParametersForWorkspace.json) with those overrides.
Issue:
When I run the UAT workflow, deployment completes successfully but the UAT Synapse workspace still shows Dev resources. For example, linked services like LS_ADLS still point to azcalsbdatalakedev instead of azcalsbdatalakeuat.
What I have tried:
Created overrides for UAT (uat.json) with correct workspace name and connection strings
Checked GitHub workflow YAML to confirm the override file is being passed in the az deployment group create step
Verified that Dev deployment works fine
Tried changing default values in linked services JSON but behavior is inconsistent
Questions:
Is there a specific way to structure override files (uat.json) for Synapse CI/CD deployments so environment values are correctly replaced?
Do I need separate branches in GitHub for Dev, UAT, and Prod, or can I deploy to all environments from main with overrides?
Has anyone else seen linked services or parameters still pointing to Dev even after a UAT deployment?
Any guidance, best practices, or sample YAML and override examples would be very helpful.
Thanks in advance.
1 Reply
hi varsha-ahirwal_calbar Great questions — CI/CD for Synapse via GitHub Actions can be tricky when it comes to parameter overrides and linked service references.
From your description, it sounds like the override parameters aren’t being applied during the deployment phase. A few things to double-check:
Parameter name alignment:
Ensure the keys in your uat.json match exactly with the parameter names defined in TemplateParametersForWorkspace.json. Even minor casing differences will cause Synapse to fall back to default (Dev) values.
Override file usage in the deployment command:
When calling the az deployment group create command, make sure your --parameters argument includes both the template parameters and the override file, for example:
az deployment group create \
--resource-group your-uat-rg \
--template-file TemplateForWorkspace.json \
--parameters @TemplateParametersForWorkspace.json @uat.json
The second file (uat.json) should override values in the first.
Publish artifact validation:
Sometimes the Synapse publish artifacts still carry Dev defaults even after exporting. Try regenerating them from the UAT branch or using the “Manage Hub → Publish” option directly from UAT after applying parameter tokens.
Linked Services behavior:
Linked services are parameterized, so if they aren’t picking up UAT values, ensure they reference workspace-level parameters (not hardcoded strings). You can verify this in the JSON under properties.typeProperties.url or connectionString.
As for branching strategy — both options are valid. Many teams prefer a single main branch with environment-specific parameter overrides, while others maintain separate environment branches for clearer isolation. If your pipelines are already parameter-driven, one branch is perfectly fine.
If helpful, Microsoft’s official reference on Synapse CI/CD provides examples of parameter substitution:
https://learn.microsoft.com/en-us/azure/synapse-analytics/cicd/continuous-integration-delivery
