DEV Community: Oluwagbenga Balogun

Agentic DevOps with GitHub Actions and Microsoft Foundry

Oluwagbenga Balogun — Fri, 25 Sep 2026 11:38:13 +0000

As AI agents become a bigger part of the conversation around software development, I started thinking about what they could mean for my own role as a DevOps engineer. Where could they help in a delivery pipeline? What decisions could they support? And where would I still want myself or someone else to firmly be in control?

For sure we know DevOps already involves a great deal of automation. We build pipelines to test code, check for problems, and move changes between environments. But deciding whether a release should proceed requires context. Passing tests are useful evidence; but they do not answer every question about the risk of a change.

That made release review an interesting place to experiment. Could an agent help explain the evidence, highlight concerns, and prepare better questions for the person approving a deployment? I mean I already interact with agents like they are colleagues and it's been real so far.

I built a small proof of concept with GitHub Actions and Microsoft Foundry to explore that question. I wanted to understand the moving parts for myself, how evidence reaches a reviewer, how a recommendation affects the workflow, and how approval remains under human control.

This article shares that experiment with other DevOps and platform engineers asking similar questions about their roles. It walks through what I built, what it demonstrates, and what would still need to change before using the approach in production.

The implementation has two parts. GitHub Actions runs a deterministic release review and demonstrates an environment approval gate. Separately, a Microsoft Foundry agent reviews the same sample evidence in the playground. The workflow does not yet call Foundry, and its staging and production jobs simulate deployment.

That boundary matters. This is a practical foundation for an agent-assisted release process, with a clear path to integration.

Repository: balop3e/agentic-devops-poc

What this proof of concept demonstrates

The question I wanted to explore was straightforward, how can an AI recommendation fit into a release process without becoming the authority that approves production?

Component	What happens in this demo
GitHub Actions	Runs tests, generates sample evidence, executes the review, and sequences the jobs.
Python review script	Applies fixed rules to produce a risk score and recommendation. It does not call an AI model.
Microsoft Foundry agent	Reviews the same evidence through a separate, manual playground interaction.
GitHub production environment	Pauses the production job for a configured reviewer.
Deployment jobs	Print demonstration messages; they do not deploy an application.

The actual unit tests run before evidence generation. However, the release evidence uses preset low-risk and high-risk scenarios. Its test counts, coverage changes, and vulnerability counts are predefined inputs for exercising the review logic.

How the components connect

Figure 1. The implemented workflow and the separate Foundry experiment. The AI response does not feed back into the workflow in this version.

A push to main or a manual workflow run starts the build and test job. When that job succeeds, the workflow generates a JSON evidence file and stores it as an artifact. The review job reads that artifact and publishes a Markdown report.

The staging simulation runs when the review exposes a proceed decision. The production simulation additionally requires a manual run with deploy_production=true, successful staging, and satisfaction of the production environment's protection rules.

Alongside this flow, I pasted the evidence into Foundry to explore the quality of an AI-generated explanation. This kept the workflow demonstration repeatable while letting me inspect the model's response separately.

Start with structured release evidence

An AI reviewer needs a defined input. Asking whether a release is safe without supplying evidence encourages assumptions.

The demo uses fields for the commit, workflow run, target environment, tests, change size, coverage, vulnerabilities, database migrations, and dependency changes. Here is an illustrative low-risk input, with placeholder identifiers:

{
  "commit_sha": "example-commit",
  "workflow_run": "example-run",
  "deployment_target": "production",
  "total_tests": 24,
  "failed_tests": 0,
  "changed_files": 6,
  "coverage_delta": -1.1,
  "high_vulnerabilities": 0,
  "critical_vulnerabilities": 0,
  "database_migration": false,
  "external_dependency_change": false
}

Note that these numbers are sample data, not measured results. The schema defines coverage_delta as a percentage-point change, a fall from 80% to 78.9% is a change of -1.1 percentage points. The original demo report displays a percent sign, which is less precise.

In a real pipeline, I would populate these fields from the test runner, coverage report, vulnerability scanners, and deployment metadata. I would also include evidence timestamps and an artifact digest so the review can be tied to the exact release candidate.

The repository includes schemas/release-evidence.schema.json. Having that file does not enforce the contract automatically, the current review script loads JSON into a Python dataclass without invoking a JSON Schema validator. Runtime schema validation and consistency checks, such as ensuring failed tests cannot exceed total tests, are next steps.

Separate policy from explanation

The Python review applies fixed scoring rules. Failed tests or critical vulnerabilities produce a block recommendation regardless of the final risk label. Other signals add points, including high-severity findings, larger changes, coverage drops, migrations, and dependency changes.

The low-risk fixture produces proceed, a low risk level, and a score of zero. These are outputs of an illustrative scoring model. A zero score is not a guarantee that a release is safe, and the score is not a probability of failure.

One implementation detail deserves attention, assess_release() can return proceed_with_extra_review, but write_github_output() maps every non-blocking recommendation to proceed. The production approval gate still applies, but the workflow does not enforce a separate extra-review process for that middle state.

Before extending this pattern, I would preserve that state explicitly and define the additional review it requires. More generally, policy should make mandatory decisions in code; the model should explain the evidence and surface questions.

Put approval in the deployment platform

Writing “human approval required” in a prompt or report does not enforce approval. The relevant control in this demo is the GitHub environment configuration.

The workflow's production job references production. A required-reviewer rule configured on that environment makes the job wait. The following simplified excerpt illustrates that relationship; it is not a complete workflow:

deploy_production:
  runs-on: ubuntu-latest
  needs: [agent_review, deploy_staging]
  if: >-
    github.event_name == 'workflow_dispatch' &&
    github.event.inputs.deploy_production == 'true' &&
    needs.agent_review.outputs.decision == 'proceed'
  environment:
    name: production
  steps:
    - name: Simulate deployment
      run: echo "Protected job released to run."

The YAML reference alone does not create a reviewer requirement. I still need to configure the environment protection rule separately. For independent review, I enabled prevention of self-review and select another eligible reviewer. Also review administrator bypass settings and restrict permitted deployment branches or tags. GitHub's current documentation says required reviewers on Free, Pro, and Team plans are available only for public repositories. See deployment protection rules.

Figure 2. The production simulation waits for environment review after the deterministic review and staging simulation finish.

As you can see in the demonstration, the workflow waited at this gate and then completed after approval. This shows the gate operating in that run, but does not establish independent approval by a second person or prove that bypass was disabled. A printed log message saying a human approved is not, by itself, evidence that a gate was enforced.

For a production implementation, protect workflow changes and deployment credentials too. A job that omits the protected environment must not have another route to the same production permissions.

Azure Pipelines supports a related pattern through approvals and checks on resources such as environments. That offers another way to keep the approval control outside the AI response.

Explore the AI reviewer in Microsoft Foundry

The Foundry portion gives the reviewer a specific job, interpret the supplied release evidence and prepare useful context for an approver.

The main concepts are a Foundry resource, a project, a model deployment, and an agent. The resource provides the service boundary; the project organises the work; the model deployment supplies inference; and the agent adds instructions and, when configured, tools. The playground provides an interactive place to test the behaviour. Microsoft describes the platform in its Foundry overview.

For this experiment I used gpt-4o-mini and an agent called devops-release-review-agent. That records the demo configuration, rather than recommending a particular model for every release process.

The instructions asked for a risk level, recommendation, reasons, questions for the human reviewer, and a concise approval summary. They also told the agent not to claim production was approved and to recommend blocking when tests failed or critical vulnerabilities were present.

Figure 3. The Foundry agent reviews evidence pasted into the playground. This is separate from the GitHub Actions execution.

For the supplied low-risk evidence, the response recommended proceeding and raised questions for the approver. This is a useful example of explanation, but one favourable response does not establish reliability. The experiment does not demonstrate autonomous remediation, deployment tools, or a multi-agent system.

Prompts describe intended behaviour, they are not access controls. A release-review agent should have no permission to approve its own deployment or alter the approval configuration.

Understand the permissions before connecting the pipeline

During setup, I encountered an important distinction between managing an Azure resource and using the AI service inside it.

The Azure control plane covers management tasks such as creating resources and assigning roles. The data plane covers service operations such as invoking models and working with agents. Subscription Owner does not itself grant all Foundry data-plane permissions, portal setup can add separate role assignments.

Check the specific operations and scope your identity needs in the Foundry RBAC documentation. Current documentation uses names such as Foundry User and Foundry Agent Consumer, older interfaces may still show Azure AI role names. An identity that only invokes an agent should not receive broad management privileges unnecessarily.

For a future GitHub-to-Foundry integration, I would use OpenID Connect with Azure and Microsoft Entra workload identity federation instead of a stored long-lived client secret. The workflow needs id-token: write to request an OIDC token, Azure role assignments determine what the resulting identity can do. Its trust configuration must match the intended repository and workflow context.

The agent-review identity and production deployment identity should have separate responsibilities and permissions.

Reuse the pattern across teams

The repository contains a reusable review workflow and a Team Scaling Demo caller. Two illustrative teams invoke the same implementation with different evidence profiles:

Caller	Evidence profile	Expected review outcome
Payments team	Low risk	Proceed
Identity team	High risk	Block

Figure 4. Team-specific jobs reuse the same review implementation within the demo repository.

A successful review job means the analysis completed. It does not necessarily mean deployment is permitted the script can successfully produce a block decision. A caller must consume that output in its deployment conditions. The scaling demonstration itself has no deployment jobs.

This shows reuse within one repository. Extending it to separate repositories needs additional work. In particular, actions/checkout inside a called workflow normally checks out the caller's repository. The shared review code must be distributed deliberately, for example as a versioned action or package, rather than assuming its scripts exist in every caller. GitHub documents the execution context in reusing workflows.

I would make the platform team responsible for the evidence contract, review implementation, prompt versions, and evaluation cases. Product teams would supply release evidence and retain ownership of their deployment and approval configuration.

What I would add before production use

The next iteration should address several concrete gaps:

Collect and validate real evidence. Parse actual reports, reject missing or inconsistent fields, and bind every review to the commit and deployable artifact.
Integrate Foundry explicitly. Call the selected agent API from the review job and validate the response against an output schema. Preserve a clear distinction between deterministic policy and AI advice.
Define failure behaviour. A timeout, unavailable model, or malformed response must never silently become an approval. Pause for review or follow a documented fallback policy.
Treat release text as untrusted input. Commit messages, pull-request descriptions, and logs can contain instructions aimed at the model. Keep them separate from trusted instructions and prevent the reviewer from changing policy or gaining deployment permissions.
Evaluate difficult cases. Include missing evidence, contradictory signals, failed tests, critical vulnerabilities, migrations, and attempts to override instructions. Recheck behaviour when the prompt or model changes.
Record decisions and outcomes. Retain evidence, policy results, AI output, prompt and model versions, reviewer decisions, and deployment outcomes. Measure review usefulness, latency, and cost before claiming an improvement.

These are proposed enhancements, not capabilities already demonstrated by this repository.

What I learned

It was very important for me to be able to prove or have a first hand experience on how infusing agents into the process will be. This allows me prepare for governance requirements not only for carrying out my work but also when it comes to making business decisions. The most useful result was a clearer separation of responsibilities. GitHub Actions executes the workflow. Deterministic rules evaluate explicit policy. Foundry can help explain the evidence. Environment protection rules control when the protected job may run.

This PoC demonstrates those pieces without claiming a complete AI-operated delivery platform. Connecting the agent is the next technical step; validating its usefulness and keeping the approval boundary intact are the next engineering responsibilities.

If you are exploring this approach, start with a release decision your team already makes. Define the evidence, make the policy explicit, and then test whether an AI reviewer helps people understand that decision better.

Source code and documentation

Implementation and documentation reviewed on 25 September 2026. Screenshots show the original demonstration; product interfaces and access requirements can change.

HOSTING A STATIC WEBSITE ON AZURE STORAGE WITH AZURE CDN

Oluwagbenga Balogun — Wed, 16 Nov 2022 03:16:46 +0000

INTRODUCTION
A colleague reached out to me some time ago and wanted to host a static website on Azure storage. We haven’t had time to go through the steps and achieve his goal which is to host a static website on Azure.
Now I made this demo for those who would like to host a static website on Azure cloud, specifically into an Azure Storage Account using the Azure portal. I would make this demo a step by step walk through so even you that are new to the cloud can easily host your static website on Azure Storage.

WHAT ARE THE BENEFITS OF HOSTING YOUR STATIC WEBSITE ON AZURE?
Okay so why should you host your static website on Azure? there are good reasons for wanting to do this as I have highlighted below;
• Simplicity: All you have to do is upload your web folders and files to a container.
• Saving on hosting cost: Cheaper compared to buying hosting fee from a web hosting company.
• Better Performance: Azure CDN can be configured to get a better performance delivering contents to your end users around the world.
Combining Azure CDN with blob storage provides a low-cost and highly reliable static website hosting solution. These static sites have only CSS, HTML, JS files, fonts, etc.

PREREQUISITES
There are some prerequisites we have to put in place before we proceed with this demo:
• Create a Microsoft Azure account, if you currently don’t have you can create one here
• Create a subscription
• Have a registered domain

NOTE: To those that are new to the Azure platform, when you create a free account, you get a $200 free Azure credit to create resources for 30 days and a subscription is automatically created.

OUTLINE OF WORKFLOW
Below is the workflow of what we would be doing in this demo,

Our static website would have a custom domain with which our end users would be able to access our website from the public web.

After all prerequisites has been put in place, let’s get started.

• CREATE A RESOURCE GROUP
A resource group is a container where all related resources reside in. Now let’s proceed and create a resource group. See below images for visual guide.

• CREATING A STORAGE ACCOUNT
After creating the resource group static-website-demo-rg for this demo, the next step is to create a storage account inside the static-website-demo-rg RG. See images below,

Goto the newly created storage account resource which is staticwebsitehosting1 for this demo. This is where most of the task would take place. As shown in image below, this is the interface you should see when you goto the storage account.

Click on capabilities and you see that the storage account at the moment is not configured for static website hosting and Azure CDN is also not configured as shown in the image above.

ENABLING STATIC WEBSITE ON STORAGE ACCOUNT
Now click on static website and enable the storage account to host static content webpages.
Enter the index.html inside the index document block, you can also specify a root file for 404 error but we are not interested in that for this demo. Save and when it is enabled a primary endpoint https://staticwebsitehosting1.z13.web.core.windows.net is created automatically this is just a generic URL for your end users to access your website contents.
See images below

Also, after enabling static website a container $web is automatically created, this container would hold your web content files and folders.

If we check capabilities under the storage account overview, we see that static website has been configured.

UPLOADING WEB CONTENTS TO CONTAINER
Now it's time to upload our website contents to the container $web. You might be thinking uploading the web content to the container from the portal should be easy by just clicking the upload button and upload the web folders and files to the container. Unfortunately, you cannot upload folders to the container from the portal directly except for files.
Here is our web content below,

see below image you can only upload files to the container. For our web contents only index.html and README.txt can be uploaded which does not work for us because all folders and files has to be uploaded

• DOWNLOADING AZCOPY
To upload our web contents to the container we would make use of a tool called AzCopy. AzCopy is a CLI (command-line) tool that moves data into and out of an Azure Storage.
Next step is to download the AzCopy tool that best fits your environment here -> https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10#download-azcopy.
Unzip the AzCopy file, for this demo I have the AzCopy unzipped folder copied to a folder "azmove" in my C:\ drive root. You can add the directory location of the AzCopy executable to your system environment variable path for ease of use, but for this I will navigate to the folder where we have the AzCopy executable and copy the file full path somewhere like a notepad. See Image below

• AUTHORIZE AZCOPY TO ACCESS STORAGE ACCOUNT
We would need to authorize AzCopy to access the storage account so we can upload the web contents to the container. We would provide authorization credentials to AzCopy by using shared access signature (SAS) token generated from the storage account. Click on the shared access signature on the left pane under "security + networking".
Explaining the key options
Allowed service - check blob only because we want to take into consideration one of cloud best practices which is least privilege concept. This SAS token is only intended for the blob service and no access should be granted to your file, queue or table service using the generated SAS token.
Allowed resource type - check container as this is the only resource, we want the SAS token to access.
Start and expiry date/time - set the period you want this SAS token to be valid through. Put into consideration security best practices, expiry date shouldn't elapse the period SAS token is expected to be used.
Leave other options as it is and proceed to click on generate SAS and connection string.
See Images below,

SAS token is generated as you can see in the last image above.
Copy the SAS token somewhere like a notepad, once you leave this page you cannot retrieve the token any longer. As you can see in the image below I have copied all important path, urls, token to one point.

AzCopy script
.\azcopy copy "{path to the website folder on your local pc}" "{path to the container hosting the website}{SAS token}" --recursive
Explaining the contents of AzCopy scripts
.\azcopy copy - This command copies source data to a destination location, be it from your local computer to a storage account or from a storage account to your local computer.
--recursive - This flag is necessary because we want to make sure it copies all sub-folders inside folders and files
{path to the website folder on your local pc} - This is the source destination of your web contents, to be uploaded to the container. See image below

{path to the container hosting the website} - This is the target destination which is your container. To get the URL/path to your container see the images below

Now if you remember we are making use of AzCopy because we cannot upload folders to the container using Azure portal, if we copy the source folder to the container, our web content would be nested inside another folder and this would not work. We need all folder and files of the web content to sit at the root of the
container. I have created an AzCopy scripts for each folder and file to be run and pushed to the container. see image below

• RUNNING THE AZCOPY SCRIPT
On your local pc launch cmd or PowerShell to run the AzCopy script. For this demo I am making use of cmd.

Change the current working directory to where you have the AzCopy executable file by running "cd {file path to where the azcopy exec file is}" as shown below

Copy the AzCopy script we coined together on notepad and past the script in cmd and run one after the other.
Note: Do this for all the remaining scripts.

After successfully uploading the web contents, and you refresh your container you would get your web contents inside the $web container.

Remember the primary endpoint link https://staticwebsitehosting1.z13.web.core.windows.net/ that was generated when you enabled static website on your storage account? now that is the link for your end users to access your content on the public web. See image below

CONFIGURING AZURE CDN
Now it's time to configure Azure CDN, firstly let's try to understand what Azure CDN is and its benefits to our end users.
Azure Content Delivery Network (CDN) is designed to send web contents such as audio, video, images, and other files faster and more reliably to your end users using servers that are closest to the end users. This helps to increase speed and availability, resulting in significant user experience improvements.
Below image shows Azure CDN is not configured yet.

Click on Azure CDN on the left pane under the “security + networking” and create a new endpoint.
Give it a CDN profile name, select the pricing tier "select Microsoft CDN (classic)" give the CDN endpoint a name.
Origin hostname - you have to select the origin server from which CDN endpoint pulls content from. I would be using my primary endpoint which is "staticwebsitehosting1.z13.web.core.windows.net" now proceed to create the CDN. See image below,

The last image above shows our CDN endpoint is ready and running.
Click on the newly created CDN endpoint, you can see 2 URLs one is the CDN endpoint and the other is the origin hostname aka primary endpoint for our static website. See image below,

Now that Azure CDN has been successfully configured for our setup, we can proceed to load the URL of the CDN endpoint which is https://swcdn.azureedge.net
Note: It would take some time for Azure CDN to load your content you might get the blue screen error or "the account being accessed does not support http" error. Just give it sometime and refresh after some minutes. See Images below

CONFIGURING A CUSTOM DOMAIN TO YOUR AZURE CDN ENDPOINT
Now can you imagine your end users accessing your webpage using the URL https://swcdn.azureedge.net of course you wouldn’t want that, you would want them to access your webpage using your preferred domain name which can be an existing one for your business or a newly registered domain name.
For this demo I would be using an existing domain I registered on Azure "theproliproject.com" and another registered on Namecheap “mast***.org”. I will be making 2 demonstrations for domain registered on Azure portal and domain registered by a different registrar.
• Domain registered on Azure portal.
Goto App Service Domain and select the domain. See image below

What we want to do? we want to create a CNAME record with the DNS provider for "theproliproject.com" that points to "swcdn.azureedge.net" doing this we would be able to associate the domain to the CDN endpoint. After selecting the domain, click on manage DNS records and click on record set.

For this demo I am making use of a sub domain staticweb.theproliproject.com
• Enter the name i.e. the subdomain name
• Enter the type - you are creating a CNAME record, this is because you are mapping/pointing your host name to another name record which is "swcdn.azureedge.net"
• Leave Alias record set to No
• TTL - leave at default
• Alias - is the CDN endpoint "swcdn.azureedge.net"
Click ok after entering the appropriate information’s. See images below

After successfully creating the DNS record, we can proceed to Azure CDN and map our custom domain to Azure CDN. Goto the Azure CDN and click on custom domain
Enter custom hostname - enter your subdomain here for this demo "staticweb.theproliproject.com" click add

If you load the staticweb.theproliproject.com in your web browser you would get the warning: potential security risk ahead warning message. If you proceed to accept the risk and continue the website loads but with the SSL certificate missing as shown in image below

Now let us proceed to enable https which enables you to deliver your web contents to your end users securely over the public web.
To enable https, click on the custom domain just created and toggle the enable https feature.
See image below

After enabling https, Azure then undergoes the following processes;

Submits your https request
Validates your domain.
Provision a certificate for your domain. See image below,

After the process is completed, you can reload the URL in your browser and your website should be secured with a SSL certificate.
Note: it might take up to 5 minutes for this process to get completed.
See image below

• Domain registered with another registrar
Login to your account dashboard of your registrar/host account and navigate to where you can manage your domain.
Enter a CNAME record with the host name which is your preferred subdomain name e.g., for this demo "staticweb" and the value which is the Azure CDN endpoint "swcdn.azureedge.net". See image below,

Once the CNAME record is successfully added, proceed to Azure portal and add the custom domain under the Azure CDN configuration as shown in the image below,

If you proceed to load the website without enabling https you would get security warning error as shown in the image below

Now proceed to enable https

Now your website is secured proceed to reload the URL.

RESOURCES
https://github.com/balop3e/static-website-demo
https://aka.ms/downloadazcopy-v10-windows
https://mega.nz/file/YKdBXYIQ#nBlYomzljIKF9QXLmdvQwhA45iKLOw-lNXyuaJ6uPVU

CONCLUSION
In this demo we just saw how to host a static website on Azure using the Azure portal. In future posts, I will be hosting this static website using Azure DevOps Pipelines, Git, GitHub and Terraform.