Cloud deployments typically fail as a result of surroundings configurations are hardcoded into the construct course of. Here’s a sample to decouple your Construct Artifacts out of your Deployment Logic utilizing GitHub Actions and a versatile JSON Configuration map.<\/p>\n

On the planet of Kubernetes<\/a>, we’re used to the separation of considerations: Docker builds the picture, and Helm\/Kustomize handles the surroundings configuration. Nonetheless, when working with serverless (Azure Features) or PaaS (App Service), builders typically fall into the entice of monolithic pipelines. They construct a package deal that solely works in DEV, after which rebuild it for PROD.<\/p>\n

This results in “Artifact Drift,”\u00a0the place the binary operating in Manufacturing just isn’t arguably the identical binary that handed testing in Staging.<\/p>\n

A latest implementation by Fujitsu\u2019s International Gateway Division tackles this drawback head-on. By shifting away from handbook Azure CLI deployments to a strict GitHub Actions workflow, they lowered launch time by 75% (from 2 hours to half-hour) and eradicated handbook configuration errors.<\/p>\n

Right here is learn how to implement their “Atmosphere Configuration Map” sample to realize protected, automated deployments throughout Azure environments.\u00a0<\/p>\n

The Downside: The “Config Matrix” Hell<\/h2>\n
In an Agile surroundings, particularly throughout Proof-of-Idea<\/a> (PoC) phases, property are changed continuously. You may need:<\/p>\n
\n
Azure Features (API logic)<\/li>\n
Cosmos DB (Knowledge persistence)<\/li>\n
Digital machines (Legacy processing)<\/li>\n<\/ol>\n
The problem is that DEV, STAGING, and PROD have utterly completely different Useful resource Group names, Subscription IDs, and tier settings (e.g., Use a less expensive SKU for Dev).<\/p>\n
When you hardcode these into your pipeline YAML, your pipeline turns into brittle. When you attempt to handle them manually, you danger human error.<\/p>\n
The Resolution: The “Construct-As soon as, Deploy-Many” Structure<\/h2>\n
The core philosophy of this sample is straightforward:\u00a0Construct the binary as soon as, model it, after which inject configuration solely in the mean time of deployment.<\/p>\n
The workflow consists of three distinct phases:<\/p>\n
\n
Construct part<\/strong>: Compile code and generate a .zip artifact.<\/li>\n
Launch part<\/strong>: Retailer the artifact in GitHub Releases (immutable versioning).<\/li>\n
Deploy part<\/strong>: A workflow reads a Config JSON, pulls the artifact, and pushes it to Azure.<\/li>\n<\/ol>\n
A pattern workflow to know launch move utilizing GitHub Actions (handbook versus automated execution):<\/p>\n
$\"article$ <\/p>\n
1. The Atmosphere Configuration Map (config.json)<\/h3>\n
As a substitute of scattering variables throughout GitHub Secrets and techniques or Azure App Settings, we centralize the surroundings definition in a JSON file dedicated to the repository. This acts as our “Supply of Reality.”<\/p>\n
File: .github\/config\/config.json<\/p>\n
\n
\n
\n
{\n \"dev\": {\n \"subscriptionId\": \"sub-id-dev-001\",\n \"resourceGroup\": \"rg-app-dev\",\n \"sources\": [\n {\n \"type\": \"function\",\n \"name\": \"func-api-dev\",\n \"slot\": \"staging\" \n }\n ]\n },\n \"prod\": {\n \"subscriptionId\": \"sub-id-prod-999\",\n \"resourceGroup\": \"rg-app-prod\",\n \"sources\": [\n {\n \"type\": \"function\",\n \"name\": \"func-api-prod\",\n \"slot\": \"production\"\n },\n {\n \"type\": \"cosmosdb\",\n \"name\": \"cosmos-core-prod\",\n \"partitionKey\": \"\/userId\"\n }\n ]\n }\n}<\/code><\/pre>\n<\/p><\/div><\/div>\n<\/div>\nKey perception: Discover that dev would possibly deploy to a staging slot, whereas prod deploys to manufacturing. This logic is abstracted away from the construct script.\u00a0<\/p>\n 2. The Deployment “Operator” (Shell + Azure CLI)<\/h3>\nAs a substitute of relying solely on inflexible GitHub Actions plugins, this sample makes use of a Shell script to parse the JSON and execute the logic. This makes the deployment transportable \u2014 you’ll be able to run it domestically or in CI.<\/p>\n File: scripts\/deploy.sh<\/p>\n \n\n\n#!\/bin\/bash\nENV_FLAVOR=$1 # e.g., \"prod\"\nTAG_VERSION=$2 # e.g., \"v1.0.2\"\n\n# 1. Learn Config utilizing jq\nCONFIG=$(cat .github\/config\/config.json | jq -r --arg env \"$ENV_FLAVOR\" '.[$env]')\nRG_NAME=$(echo $CONFIG | jq -r '.resourceGroup')\nSUB_ID=$(echo $CONFIG | jq -r '.subscriptionId')\n\n# 2. Login to Azure\naz account set --subscription $SUB_ID\n\n# 3. Obtain the Immutable Artifact from GitHub Releases\nwget https:\/\/github.com\/my-org\/my-repo\/releases\/obtain\/$TAG_VERSION\/build-artifact.zip\n\n# 4. Iterate by means of outlined sources and deploy\necho $CONFIG | jq -c '.sources[]' | whereas learn useful resource; do\n TYPE=$(echo $useful resource | jq -r '.kind')\n NAME=$(echo $useful resource | jq -r '.identify')\n \n if [ \"$TYPE\" == \"function\" ]; then\n echo \"Deploying $TAG_VERSION to Azure Perform: $NAME...\"\n az functionapp deployment supply config-zip \n --resource-group $RG_NAME \n --name $NAME \n --src build-artifact.zip\n fi\nfinished<\/code><\/pre>\n<\/p><\/div><\/div>\n<\/div>\n3. The GitHub Actions Workflow<\/h3>\nLastly, we tie it along with a Workflow that requires\u00a0handbook approval for Manufacturing environments.<\/p>\n File: .github\/workflows\/deploy.yaml<\/p>\n \n\n\nidentify: Deploy to Azure\n\non:\n launch:\n varieties: [published]\n workflow_dispatch:\n inputs:\n surroundings:\n description: 'Goal Atmosphere'\n required: true\n default: 'dev'\n kind: selection\n choices:\n - dev\n - prod\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n surroundings: ${{ github.occasion.inputs.surroundings }} # Makes use of GitHub Environments for approvals\n steps:\n - identify: Checkout Code\n makes use of: actions\/checkout@v3\n\n - identify: Azure Login\n makes use of: azure\/login@v1\n with:\n creds: ${{ secrets and techniques.AZURE_CREDENTIALS }}\n\n - identify: Run Deployment Operator\n run: |\n chmod +x scripts\/deploy.sh\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 .\/scripts\/deploy.sh ${{ github.occasion.inputs.surroundings }} ${{ github.occasion.launch.tag_name }}<\/code><\/pre>\n<\/p><\/div><\/div>\n<\/div>\nThe Structure Visualized<\/h2>\nThis method separates the lifecycle of the code from the lifecycle of the surroundings.<\/p>\n <\/p>\n Why This Sample Works (The Outcomes)<\/h2>\nWithin the Fujitsu case research, adopting this sample solved three essential points:<\/p>\n \nPrompt rollbacks<\/strong>: As a result of artifacts are saved in GitHub Releases, “rolling again” is simply re-running the deployment job with the earlier Model Tag (e.g., v1.0.1 as a substitute of v1.0.2). No rebuilding vital.<\/li>\n Useful resource isolation<\/strong>: The config.json permits granular management. You’ll be able to outline particular permissions or exclusion guidelines (e.g., ignore: [“iam”]) for Dev environments to forestall unintended permission overwrites.<\/li>\n Eliminating “VM Lock”<\/strong>: Beforehand, deployments required unique entry to VMs, blocking different builders. By shifting to Azure Features and asynchronous Actions, the pipeline turned non-blocking.<\/li>\n<\/ol>\nConclusion<\/h2>\nInstruments like Terraform and Bicep are glorious for Infrastructure as Code<\/a> (creating the sources). Nonetheless, for Deployment as Code (shifting the bits to the sources), a light-weight, configuration-driven method utilizing GitHub Actions and JSON maps gives the pliability wanted for high-velocity groups.<\/p>\n By decoupling the “What” (the construct artifact) from the “The place” (the surroundings config), you flip a fragile handbook launch course of into a sturdy, repeatable engine.<\/p>\n<\/div>\n\n","protected":false},"excerpt":{"rendered":" Cloud deployments typically fail as a result of surroundings configurations are hardcoded into the construct course of. Here’s a sample to decouple your Construct Artifacts out of your Deployment Logic utilizing GitHub Actions and a versatile JSON Configuration map. On the planet of Kubernetes, we’re used to the separation of considerations: Docker builds the picture, […]<\/p>\n","protected":false},"author":2,"featured_media":10114,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[56],"tags":[2469,1126,7112,933,99],"class_list":["post-10112","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software","tag-actions","tag-azure","tag-decoupling","tag-github","tag-releases"],"_links":{"self":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/10112","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10112"}],"version-history":[{"count":1,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/10112\/revisions"}],"predecessor-version":[{"id":10113,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/10112\/revisions\/10113"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/media\/10114"}],"wp:attachment":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10112"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10112"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10112"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

The Structure Visualized<\/h2>\nThis method separates the lifecycle of the code from the lifecycle of the surroundings.<\/p>\n<\/p>\n

The Structure Visualized<\/h2>\n
This method separates the lifecycle of the code from the lifecycle of the surroundings.<\/p>\n
$\"Architecture\"$ <\/p>\n