devopsy.kinsta.cloud

Tag: Azure DevOps

Why Old Azure DevOps Releases Survive a Pipeline Cutover
I had finished renaming a set of back-end deployments in a nonproduction environment. The current Azure DevOps release definitions used the new names, the Kubernetes workloads ran under the new identities and every current deployment pointed at the replacement image repositories.

Then I opened an older Azure DevOps Classic release. It still offered Redeploy.

That release retained the inline deployment task captured when someone created it, including the retired Helm release name and image path. About 45 more releases across five definitions held the same task. Nobody redeployed one, but each remained an executable record of the old delivery path.

Figure 1: Editing a Classic Release Definition Leaves Already-Existing Releases Untouched

A Classic Release Stores its Task Graph

Microsoft describes a Classic release as a snapshot of the information required to run its stages and tasks. Azure DevOps can deploy the same release to a stage more than once. Editing the definition changes later releases but does not rewrite the task graph stored in releases that already exist.

The cutover changed four coupled values: The image repository path, the packaged chart name, the Helm release name and the Kubernetes resource names. The current definition showed only the replacement values. Existing releases still stored the old combination, which is why checking the definition alone would have missed the executable path.

The old task called Helm with –install. Its release name no longer existed. Helm documents the flag as an instruction to install when it cannot find that name. A redeploy would therefore attempt a second installation under the retired identity rather than upgrade the current release.

The Forward Rename Exposed the Failure Order

I did not run a stale release. The forward rename had already shown how this chart behaved when two releases wanted the same route.

While the old release still held the host and path, the admission webhook refused the new release’s duplicate ingress. The refusal happened after Helm had created the Secret, ServiceAccount, Service and Deployment. The task used neither –atomic nor –cleanup-on-fail, so those objects remained.

A stale redeploy could have attempted the same installation under the old name. Figure 2 describes that conditional path. The observed event was the late ingress refusal during the forward rename.

The old release also replayed the variable values captured at release creation. I later verified that changing a linked variable group did not change an existing Classic release. A newly created release was required to use the new values. Therefore, I treated database access as unproven unless the captured credentials and network path were checked separately.

The refused ingress did not make the remaining objects invisible or prove that they were isolated. Cluster operators could still see the Secret, ServiceAccount, Service and Deployment, and the Service could remain reachable from inside the cluster. Whether a pod could do useful work still depended on the image and its captured values.

Figure 2: The Conditional Stale-Redeploy Path, Based on the Failure Order Observed During the Forward Rename

The Executable Path Removed in Two Stages

My first containment step was to delete the retired image repositories after confirming that no active workload or current pipeline referenced them. A stale deployment could then create objects, but its pod could not pull the old image and would remain in ImagePullBackOff. This reduced the issue to orphan objects and a confusing failed release.

Deleting those repositories also removed image-level rollback through the retired path, so I checked the current releases and workloads first.

I used the Release API to filter each definition by active status and maximum creation time. The cutover timestamp identified candidates, but each stored task determined whether a release was stale. The five definitions contained a total of 46 stale releases — 25, 8, 8, 4 and 1.

Azure DevOps supports changing an active release to abandoned. I tested one target first, then tried to restore it. The API returned VS402966, stating that a release could not move from Abandoned back to Active. The release remained visible for audit history, but its Redeploy action disappeared.

That test made the next 45 changes a deliberate permanent decision. After abandoning them, I queried the definitions again, compared the Helm release set and checked the live endpoints. Every remaining active release postdated the cutover, and the running workloads had not changed.

Figure 3: The Cleanup Order, Including the One-Release Test That Exposed the One-Way Transition

Checks to Add to a Classic Release Migration
- Query active releases created before the migration boundary and follow continuation tokens.
- Inspect each release payload instead of relying on the current definition.
- Check stored scripts, Helm release names, image paths and captured variable values.
- Check –install, –atomic and –cleanup-on-fail before predicting Helm’s failure path.
- Verify retired images and captured credentials separately.
- Test abandonment on one genuine target and treat it as one-way unless your platform proves otherwise.
A green deployment proves that the new path works. For a Classic pipeline with inline deployment logic, I now consider the migration complete only when historical releases can no longer execute the retired path.
September 25, 2026
How I Consolidated Duplicate Delivery Pipelines With Parameters and Build Tags
Two modules in a repository had near-identical Azure DevOps build and release definitions. A third would have required another pair.

The delivery chain used five definitions: one change decider, two builds, and two releases. I consolidated it into one decider, one generic build, and one release with a deployment stage for each onboarded module. The count excludes package and pull request validation.

Figure 1. The consolidation removed one duplicated build and one duplicated release.

The Decider Passes the Module as a Run Parameter

The old builds repeated the same image and chart tasks with different module values. The releases repeated the same deployment tasks with different variable groups. A shared build change required matching edits in both build definitions, and a shared deployment change required matching edits in both release definitions. Adding another module would have required another build and release pair.

I named the shared definitions by product, service, scope, and kind:
```
<Product>.<Service>.<Scope>.<Kind>
```
The decider holds the only continuous integration trigger. It checks changed paths, then queues the generic build with the module and service as parameters. It also fans out shared build-input changes to every registered pair. An optional module value limits manual diagnostic runs.

The decider pins each child to the branch and commit it inspected. A later push cannot change what that child builds. It compares the current commit with its first parent because the protected branch receives changes through merges. Repositories that accept multi-commit direct pushes need to compare the before and after commit IDs from the build event.

The Azure DevOps Build REST API expects parameters as a JSON-encoded string. This reduced example shows the two routing fields and the escaping that preserves their inner quotes:
```
BODY="{\"definition\":{\"id\":$BUILD_ID},\
\"sourceBranch\":\"$(Build.SourceBranch)\",\
\"sourceVersion\":\"$(Build.SourceVersion)\",\
\"parameters\":\"{\\\"service\\\":\\\"$SERVICE\\\",\\\"module\\\":\\\"$MODULE\\\"}\"}"
```
The variables that receive those queue-time values must also retain Azure DevOps’s Settable at queue time option, stored as allowOverride: true. A cloned definition can lose that flag. The decider may identify the correct change, then fail when it hands the values to the child build.

Both registered modules resolve to the same generic build.

The Generic Build Adds the Routing Tag

The generic build has no continuous integration trigger. It receives the service and module, derives the image and chart names, publishes the artifact, and tags the run with a value such as module-b.

I first tried module:module-b, but Azure DevOps rejected the colon in the request path. The hyphenated form worked.

I kept the decider separate from the build because a combined design had triggered releases from dispatcher runs that contained no artifact. After the split, every successful generic build produced an artifact for the release.

Stage Conditions Select the Module After Release Creation

Azure DevOps supports tag filters on both the continuous deployment trigger and individual release stages. Each filter controls a different decision.

The definition trigger decides whether Azure DevOps creates a release. A module-a filter there prevents a module-b build from creating any release. The build stays green and the chain stops without a release record.

The stage artifact condition decides which deployment stage runs after Azure DevOps creates the release:
```
Release trigger
    tag filter: none

Module A stage
    artifact condition: module-a

Module B stage
    artifact condition: module-b
```
Every qualifying completion of the generic build on the configured branch creates one release. The tag selects the matching module stage. For the nonmatching stage, Artifact conditions not met is an expected skip rather than a deployment failure.

The same status can also describe a malformed condition, so the run summary alone cannot prove correct routing. The branch half adds another ambiguity: the interface displays a short branch name, while the stored condition uses a full refs/heads/... value. I checked the stored condition directly.

Figure 2. The parameter selects what the build produces. The tag selects which stage deploys it.

I Used the Other Workload as a Control

I tested the consolidated chain with a change for Module B in a nonproduction environment. The decider queued the generic build with Module B, the build added module-b, and Azure DevOps created one release.

The Module B stage completed successfully. The Module A stage reported Artifact conditions not met. I then checked Module A in AKS and confirmed that it still used its previous container image.

Renames Preserved Execution and Left Stale Labels

I renamed the definitions using the service naming scheme. Azure DevOps kept their IDs, so execution references remained valid. Seven build validation policies still displayed the old pipeline name, and I updated those labels separately.

A snapshot of the release definition taken one week later still held the former build name in its artifact metadata. The release continued to bind by ID, but its interface displayed stale text.

The duplicate definitions also carried deployment history. Azure DevOps returned HTTP 409 when I tried to delete a build because a release still retained runs from it. I disabled its trigger, removed the remaining references, and archived it.

Another Module Adds Three Configuration Items

Another module now needs one decider map entry, one variable group, and one release stage. The generic build derives its tag from the queue parameter, so the team adds no module-specific build or release definition.

The application and environment still require their own preparation, including code and Dockerfile support, a database, a broker vhost, variable values, and Kubernetes namespace resources.

Figure 3. A new module extends the chain without adding a build or release definition.

This pattern fits modules that share a repository, artifact type, build process, and deployment mechanics. A different artifact or approval process may need its own chain. Here, parameters carried the module values, and build tags selected the correct deployment stage.

References
September 16, 2026
Building CI/CD Pipelines for On-Prem Azure DevOps: What the Cloud Docs Don’t Tell You

When I took on the job of designing and building CI/CD pipelines for a project running Azure DevOps Server on-prem, the community already had pipeline definitions available. I assumed I had a head start. I was wrong. Every one of those pipelines was written for Azure DevOps Services. Cloud-managed agents, public internet access, Microsoft-hosted authentication — none of it applied to our environment.

I could not adapt those pipelines. I had to make deliberate design decisions about how our pipelines would work, what standards agents would follow and how we would validate changes before they reached upstream. A junior engineer worked alongside me to implement these decisions. This article covers the design choices that mattered the most and why they were necessary, specifically on-prem.

The Fundamental Shift: Everything You Relied on is Gone

The first thing to internalize about on-prem Azure DevOps is that Microsoft-hosted agents do not exist. This is not a configuration option. It is an architectural fact. Microsoft’s own documentation states it plainly: Hosted agents are only available with Azure DevOps Services. On-prem, every agent is self-hosted, which means you provision it, configure it, maintain it and manage its tool dependencies yourself.

This has a cascading effect. Cloud pipelines assume a freshly imaged VM for every job, pre-loaded with Node, Python, Docker and dozens of other tools. On-prem, your agents persist between runs and carry only what you install. Every capability your pipeline needs, including compilers, package managers and container runtimes, must be explicitly provisioned and registered as agent capabilities. If a job requires something the assigned agent does not have, it queues indefinitely with no useful error message.

Authentication is also completely different. Cloud Azure DevOps authenticates over the public internet using Microsoft Entra ID or personal access tokens. On-prem, you authenticate against an intranet server using Windows Authentication, Active Directory, NTLM or Kerberos. Service connections, which are the mechanism pipelines use to access external resources, must be manually configured against your internal server and are not transferable from cloud pipeline definitions.

Agent Design: Stability is the First Problem to Solve

My first week was spent debugging agents that registered successfully and then went offline the moment a job was queued. The root cause was the agent service not recovering gracefully after brief network interruptions. This is a problem that simply does not exist with cloud agents because each job gets a fresh VM.

The fix was configuring the agent as a system service with automatic restart on failure, not as a foreground process. It also required tuning connection retry settings so the agent could survive transient network issues without dropping out of the pool. Do this before writing a single pipeline. An agent that silently goes offline causes jobs to queue indefinitely rather than fail fast. That is far harder to debug than an outright failure.

Explicit capability declarations in pipeline YAML are equally important on-prem. In cloud pipelines, vmImage handles agent selection for you. On-prem, you specify a pool and rely on demands to route jobs to agents that have the right tools. Without precise demands, any available agent picks up the job. If the tool is missing, the failure happens mid-run.

Here’s the pool configuration pattern that worked for us:

pool:

name: OnPremAgentPool

demands:

– Agent.OS -equals Linux

– docker

– make

Artifact Publishing: Not the Same as Cloud

In Azure DevOps Cloud, the publish task automatically uploads artifacts to Microsoft’s infrastructure. On-prem, you need to think deliberately about where artifacts go. Your on-prem Azure DevOps Server manages artifact storage directly, and you need to make sure retention policies, storage limits and feed configurations are in place before pipelines start producing artifacts at scale.

One on-prem-specific issue I ran into: Artifacts published in one stage are accessible to downstream stages using the download task, but the behavior depends on how your server is configured and which version of Azure DevOps Server you are running. Cloud documentation for pipeline artifacts assumes a specific service layer that the on-prem version may implement differently depending on the server version. Test artifact passing between stages explicitly before building multi-stage pipelines that depend on it.

Here’s a minimal multi-stage artifact pattern that worked reliably on-prem:

stages:

– stage: Build

jobs:

– job: BuildJob

steps:

– checkout: self

submodules: recursive

– script: make build

displayName: Build

– task: PublishPipelineArtifact@1

inputs:

targetPath: $(Build.ArtifactStagingDirectory)

artifact: build-output

– stage: Test

dependsOn: Build

jobs:

– job: TestJob

steps:

– task: DownloadPipelineArtifact@2

inputs:

artifact: build-output

– script: make test

displayName: Run Tests

Submodule Validation: Design for Two Tiers

Before I designed the validation pipeline, submodule changes were never tested against the broader system until they were upstreamed. The failure pattern was consistent: A change would pass its own tests, merge cleanly and then break the parent build hours or days later. By then, the connection back to the submodule change was not obvious and the cost of fixing it was high. I designed a two-tier validation system to eliminate this failure category.

The design uses two distinct validation tiers based on how tightly a module is coupled to the rest of the system.

For standard modules, the validation is straightforward: When a PR opens, build the module and run its unit tests. If both pass, the PR can be merged. This keeps feedback fast and the pipeline focused on what changed.

For tightly coupled modules, where a change can ripple across multiple dependents, the validation is deeper. When a PR opens for one of these modules, the pipeline builds every dependent module, assembles the full integration image, replaces the newly built package in that image and runs the full integration test suite. This catches integration failures before merge rather than after, which is the only point at which they are cheap to fix.

The key design decision is treating these as two separate pipeline definitions, not two branches of one pipeline. Each has its own trigger, its own required status check on the PR and its own pass/fail criteria. Mixing them in a single pipeline with conditional logic creates noise and makes failures harder to diagnose.

Network: Mirror Everything Before You Need It

On-prem agents have no assumed internet access. Cloud pipeline YAML that calls npm install, pip install or docker pull against public registries will fail silently or with misleading errors the moment it runs on an on-prem agent in a restricted network.

The right approach is to mirror every external dependency to an internal registry before writing your first pipeline — package registries, base container images and build tools. Configure your agents to use internal mirrors by default, not as a fallback. Two specific patterns that caused the most pain: Package managers that silently fall back to cached or stale versions when a registry is unreachable, producing builds that appear to succeed but use outdated dependencies; and proxy configuration that needs to happen at the agent service level, not just in pipeline environment variables. Some agent operations bypass pipeline-level proxy settings entirely.

Code Coverage Publishing: V2 Won’t Work the Way You Expect

If you are running Azure DevOps Server 2022 on-prem and plan to publish code coverage results, you will likely encounter a frustrating problem: The documentation says PublishCodeCoverageResults@2 is supported on Server 2022, but when you try to use it on a self-hosted agent in a corporate network, it fails. The error points to a connection problem with dev.azure.com. This is not a configuration mistake. The v2 task has a cloud-dependent processing step that makes an outbound call to Azure’s infrastructure to generate its coverage reports. In an on-prem environment without that outbound connectivity, it simply does not work.

The practical answer is to stay on PublishCodeCoverageResults@1. It works reliably on-prem and the constraint is format: v1 only supports Cobertura and JaCoCo. Whatever language your build uses, the coverage output needs to be in one of those two formats before you can publish it to the pipeline UI.

For Go repositories, this requires an extra conversion step. Go’s native coverage tool produces its own format that Azure DevOps cannot parse. The gocover-cobertura converter (github.com/t-yuki/gocover-cobertura) transforms Go’s output into Cobertura XML, which v1 can then publish. The full sequence in the pipeline YAML is:

# Run Go tests and generate native coverage output

– script: |

go test -coverprofile=coverage.out ./…

displayName: Run Go Tests with Coverage

# Convert Go coverage format to Cobertura

– script: |

gocover-cobertura < coverage.out > coverage.xml

displayName: Convert to Cobertura

# Publish using v1 — the only task that works reliably on-prem

– task: PublishCodeCoverageResults@1

inputs:

codeCoverageTool: Cobertura

summaryFileLocation: coverage.xml

A few things worth noting: gocover-cobertura needs to be installed on the agent, which means adding it to your agent-provisioning script rather than installing it inline during the pipeline run. Installing tools inline works in cloud pipelines because each run gets a fresh agent. In the case of on-prem self-hosted agents, repeated tool installs per run accumulate overhead and can cause version conflicts. Treat agent-level tools as infrastructure. Install them once, document them in your agent capability matrix and declare them as demands in your pipeline YAML.

The Takeaway

On-prem Azure DevOps is not a simplified version of the cloud product. It is a different operational environment that requires deliberate design decisions around agents, authentication, artifact storage and network connectivity that cloud users never have to think about. Community pipelines written for cloud Azure DevOps are not a starting point. They are a map of every assumption you need to invalidate.

The most impactful decision I made was the two-tier submodule validation design. Before it existed, upstream breakages from untested submodule changes were a recurring problem with no systematic fix. After it was in place, that entire failure category was caught at PR time before anything reached the main branch. The technical implementation was not the hard part. The design decision to treat submodule validation as a first-class pipeline concern and to direct my team to build and maintain it accordingly was what made the difference.

The engineering that makes on-prem CI/CD reliable is invisible when it works. When it does not work, the failures are subtle and the documentation is thin. I hope this article saves you some of the time it took me to figure these things out.

July 9, 2026
Cyber Threats to DevOps Platforms Rising Fast, GitProtect Report Finds

Software developers, CI/CD pipelines, and the tools they rely on are increasingly becoming attractive targets for threat groups. The number of cyberattacks on code repositories like npm and GitHub continues to mount as threat actors push their supply chain attacks.

Compromising open source packages, fake development tools, and social engineering are among the tactics bad actors use against developers. Researchers with Kaspersky Lab this month wrote that a combination of programmers’ unfounded belief that they are good at spotting threats and jobs that require them to often download and run third-party code “makes them sitting ducks for cyberattackers.”

GitProtect.io analyst this week detailed the mounting and evolving threats facing developers and their operations. In its DevOps Threats Unwrapped Report 2026, the DevOps backup and recovery specialists found that the number of incidents targeting DevOps environments in 2025 grew 21% year-over-year, and that the number of hours of impacted performance those incidents caused doubled to 9,255, costing more than $740,000 in lost engineering productivity.

The numbers in the report are based on publicly available information published by vendors on their status pages, security advisories, databases, and publicly reported incidents, according to GitProtect.

‘A Playground for Cyber Criminals’

“What could we remember 2025 for when it comes to DevOps threats?” Daria Kulikova, head of GitProtect Lab, wrote in the report. “It was a year when trusted development platforms, automation pipelines, and cloud identities became a playground for cyber criminals. Attackers leveraged platforms such as GitHub, GitLab, Atlassian, and Microsoft as part of their malware campaigns – they used trusted DevOps platforms as malware distribution channels, command-and-control infrastructure, and credential harvesting pipelines.”

Kulikova pointed to how various campaigns – such as Shai-Hulud, GhostAction, GPUGate, and GitVenom – abused automation and stole tokens to compromise repositories, listed a range of malware families like PyStoreRAT, SmartLoader, Lumma Stealer, and AsyncRAT that were distributed through fake libraries, poisoned packages, and other means, and noted that AI-generated repositories and dormant accounts were used for credential theft and covert reconnaissance.

“However, attackers werenʼt only limited to distributing the code on DevOps platforms,” she wrote. “Identity was another attack direction. Hackers abused OAuth flows, long-lived Personal Access Tokens (PATs), and MFA-bypassing phishing kits to bypass defenses on Microsoft 365, GitHub, and collaboration tools at scale.”

By the Numbers

The numbers in the report illustrate the turn bad actors are taking toward developers. In 2024, GitHub, GitLab, Azure DevOps and Jira saw a total of 364 incidents, and that number jumped last year to 607, about a 40% rise. Among those incidents, 156 were critical or major events that consumed more than 1,750 hours of downtime, a 69% increase in high-severity disruptions from 2024, when there were only 48 such cases.

The need to patch software vulnerabilities also grew throughout 2025, according to the report. In all, vendors reported 236 security flaws that were patched across DevOps services, with 14 deemed critical, with a CVSS severity score of 9.0 or higher, and another 126 given high-severity ratings.

In addition, there was a 30% increase in patched vulnerabilities between the first and second halves of the year, Kulikova wrote.

Downtime Increases

The downtime caused by the growing number and severity of incidents was significant, according to the analysts. While the while there was the 21% increase in the number of incidents – from 502 in 2024 to 607 last year – and total downtime jumped almost 95%, from 4,755 hours to 9,225. The frequency of the disruptions didn’t just grow, but became more difficult to resolve, they wrote.

About 62% of the outages of DevOps platforms were driven by the degraded performance caused by attacks, according to GitProtect’s numbers. That said, they accounted for only 34% of the total downtime. Maintenance that needed to be done following incidents – which made up only 4% of the total number of outages – consumed 30% of the lost time, showing that planned and unplanned maintenance was the primary reasons for platforms not being available.

Some Things Stay the Same

There are some areas that didn’t change much year-to-year, according to the report. The technology and software sectors were still the most targeted, with others like telecommunications, automotive, and education also in the crosshairs, and ransomware and extortion groups, such as Hellcat and Crimson Collective, were behind a large number of data breaches, which targeted high-profile companies like Red Hat, Nissan, and Europcar.

“As attackers blend trusted platforms, hardware-aware evasion, malicious AI-generated code, and phishing-as-a-service into their arsenals, the 2025 threat landscape makes one thing clear: traditional perimeter defenses and reactive monitoring are no longer enough,” Kulikova wrote. “Organizations need to ensure the resilience of their environment.”

April 29, 2026
Qwiet AI Extends Microsoft Support in Platform for Fixing Vulnerabilities

Qwiet AI today extended the reach of its application security platform that uses artificial intelligence (AI) agents to discover and remediate vulnerabilities in code to now provide deeper integrations with Azure DevOps, Azure Boards and GitHub platforms from Microsoft.

The company has also enhanced its support for webhook notifications, automated data export processes, expanded secrets configuration and made minor user interface (UI) enhancements.

Additionally, Quiet AI is also beta testing observability graphs and reports to provide deeper vulnerability trend analysis.

Finally, the AutoFix AI agents developed by Qwiet AI to remediate vulnerabilities have also been extended to add an ability to analyze data stored in a Static Analysis Results Interchange Format (SARIF) for non-Code Property Graph projects and policy support for code built using the Swift programming language used to build macOS applications.

Quiet AI CEO Stuart McClure said integration with the DevOps platforms from Microsoft comes at a time when they are gaining increased traction. Many application developers are increasingly relying on artificial intelligence (AI) coding tools from Microsoft to build software, he added.

The challenge is that much of that code can contain vulnerabilities because the AI models that were relied on by AI coding tools were trained using examples of flawed code. Unfortunately, too many developers put too much faith in the output of AI coding tools. In some cases, the code created by an AI coding tool might be more secure than the code an inexperienced developer might create, but there is no way to tell without scanning it. The only way to address that issue at scale is to make use of an application security platform such as Qwiet AI that has trained AI agents to both discover vulnerabilities and automatically remediate them, said McClure.

It’s not likely that concerns about vulnerabilities might be holding back adoption of AI coding tools so it’s probable the number of them that will find their way into production environments is only going to increase. The best way to proactively address that issue is to use AI to identify and remediate vulnerabilities as code is being written, added McClure.

In the case of Qwiet AI, that means using a platform that makes use of AI agents to run both static assessment security test (SAST) and software composition analysis to discover vulnerabilities that are then remediated using a series of AI agents that create, test and review changes that will be made to the code. In effect, Qwiet AI is making a case for using AI agents to compensate for the security flaws in AI coding tools.

Hopefully, the code being generated by AI coding tools will steadily improve as they are trained using examples of code that have been vetted for security flaws. In the meantime, however, DevSecOps teams should view any code generated by AI coding tools with at least the same level of suspicion as they would code written by human developers.

August 27, 2025
Free Tiers and Open Source LLMs – Mana for Developers, Platform Engineers and QA
Development rarely follows one straight path. You sketch ideas, prototype, test, swap tools, iterate, and repeat. The increasing availability of free, limited-use AI tiers and locally run open-source AI LLMs is accelerating that loop. These tiers are not marketing fluff. They are practical on-ramps for developers and engineers. They offer the freedom to test, compare, and refine without upfront cost.

Free Tiers For The Taking

GitHub provides a free Copilot tier: up to 2,000 code completions per month, plus 50 premium requests (chat / “agent mode”) interactions. Available in VS Code, Visual Studio, JetBrains IDEs, and more. It includes access to Claude 3.5 Sonnet and GPT-4o models. (https://github.com/features/copilot/plans, https://docs.github.com/copilot/concepts/copilot-billing/about-individual-copilot-plans-and-benefits)

Anthropic’s Claude is free to use on the web, iOS, Android, and desktop with usage limits. Its API is not free. (https://www.anthropic.com/pricing, https://docs.anthropic.com)

OpenAI’s GPT-5 is available to free ChatGPT users with strict usage caps. Its API requires prepaid credits, minimum $5. (https://www.wired.com/story/openais-gpt-5-is-here, https://help.openai.com/en/articles/8264644-how-can-i-set-up-prepaid-billing)

New AWS accounts get up to $200 in credits valid for six months. Generative AI services like Bedrock move to pay-as-you-go after that. (https://aws.amazon.com/about-aws/whats-new/2025/07/aws-free-tier-credits-month-free-plan)

Google Cloud AI Studio and Firebase are free to access. The Gemini API has a free tier with lower rate limits; paid tiers offer higher capacity. (https://ai.google.dev/gemini-api/docs/pricing)

Cursor offers a free plan with usage limits. Windsurf provides monthly prompt credits across free and paid plans. (https://cursor.com/pricing, https://docs.windsurf.com/windsurf/accounts/usage)

Why This Matters to Developers

Flexible Model Switching: You can test multiple models (GPT-4o, Claude) without changing workflow or integration. That removes friction from choosing the best fit for your task.

Rapid Prototyping: No billing setup. You can try ideas, logic paths, and prompt styles immediately.

Cost-Effective Scaling: Validate with free tiers. When it works, choose paid tiers intentionally, not by guesswork.

Hybrid Model Approaches: Use GPT-5 or o1 for reasoning tasks, then cheaper models like Llama for bulk processing. Free access to each lets you refine that pipeline.

AI in Your DevOps Pipeline

Free models pair neatly with toolchains:
- GitHub Actions could use a free model to auto-generate release notes, analyze test failures, or lint code.
- Microsoft Azure DevOps can use GitHub Copilot Chat and Azure OpenAI Service to assist in pipeline creation, YAML authoring, and automated documentation generation.
- Google Cloud Build can use Gemini to generate deployment docs or config templates.
- AWS CodePipeline could incorporate Bedrock calls for compliance checks or IaC validation.
- CLI tools across platforms can invoke these models for tasks like refactoring YAML, generating manifests, or annotating dashboards.
These are just a few examples of how these tools can be used with AI models. Running these in staging pipelines gives you low-risk experimentation before you roll out to production.

Go Local

Open-source and locally run LLMs such as OpenAI’s GPT-OSS, Meta’s Llama 3, and Mistral’s Mixtral are giving developers new options for building AI-driven applications without relying entirely on cloud APIs. These models can be downloaded, hosted on personal hardware, or deployed within private infrastructure, allowing full control over data, latency, and customization.

Running models locally means teams can experiment with fine-tuning for domain-specific tasks, integrate AI into environments with limited internet connectivity, and meet strict compliance or privacy requirements.

While local models may not match the scale or capability of their largest cloud-based counterparts, they offer a powerful balance of cost efficiency, adaptability, and independence that can be especially valuable for development, testing, and edge computing scenarios.

Who Else Should Care

It’s not just about developers: Test Engineers can generate synthetic test data, edge-case inputs, and test scripts. DevOps Engineers can automate pipeline scaffolding, log review, and incident summaries. Platform Engineers can prototype developer automation, self-service templates, and internal documentation.

Getting early hands-on experience helps you understand where AI adds value and where it doesn’t.

If you code, automate, build pipelines, test, or run platforms, start exploring these free AI tiers today. Plug models into your editor, Actions workflows, test frameworks, and CLI tools. Use them on real tasks, not just sample prompts. Track what works, what stumbles.

Experimentation costs almost nothing. Delay could cost your team time and innovation.

Recent articles by Mitch Ashley:
Kubernetes, AI, APIs, and YAML – A Future 2.0?
We’re Not Being Replaced. We’re Inventing What Comes Next, Including Ourselves
AI and You: Don’t Wait… Or Be Weight

Mitch Ashley is VP and Practice Lead of Software Lifecycle Engineering at The Futurum Group. The voice of “AI across the SDLC”, Mitch is a serial-CTO, speaker, advisor, entrepreneur, and product creator. He leads analyst coverage of the Software Development Cycle (SDLC), with emphasis on AI-native and agent development, cloud-native, DevOps, platform engineering, and software security.

See Mitch’s analyst research on the Futurum website.

Subscribers can access Mitch’s Software Engineering Lifecycle practice, decision-maker data, insight reports, and advisories through the Futurum Intelligence Platform.
August 10, 2025
Google Calls Microsoft Azure Anti-Competitive ¦ Gen-Z Can’t Email

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Google complains to the FTC about Microsoft market abuses, and new graduates don’t know how to office. (more…)

June 22, 2023
DevSecOps in Azure
DevSecOps is everywhere, and chances are your organization is shifting toward this convergence of development, security and operations. In an on-premises environment, you build your own DevSecOps process by mixing and matching existing and new tools. However, in the cloud, much of the environment is determined by your cloud provider. Microsoft’s Azure cloud is known for its robust security capabilities. Specifically, Microsoft has developed a set of capabilities and services that can help you ease into a DevSecOps workflow without much effort. The tools are pre-integrated and support everything from CI/CD to identity management. Let’s see how they work.

What is DevSecOps?

Security is an important part of DevOps. But it can be challenging to ensure that software developed in a CI/CD process is really secure.

DevSecOps is an organizational pattern that can make this possible, even at high development velocity. It is an approach the DevOps team can use to prevent security issues from the outset of the development life cycle, ensuring their software is not only high quality but also secure and resilient to failure.
DevSecOps is a discipline that combines application development, security, operations and infrastructure-as-code (IaC) with an automated continuous delivery cycle. Here are three practices that can help a team move towards a DevSecOps process:

Focus on average detection and recovery times—These metrics show how long it took to detect a breach and how long it took to recover. This can be tracked through continuous field testing. Improving these indicators should be an important consideration when evaluating potential policies.

Defense in depth—Every component in the architecture should be secure so that if and when attackers manage to compromise the system, there are multiple security measures and controls holding them back. This puts an end to the notion of a ‘secure perimeter’ that the organization must defend at all costs. Each component must have its own secure micro-perimeter—this is a zero-trust approach.

Continuous learning—Teams should conduct regular assessments of security practices and their environment, especially after security incidents. Every time a security incident is discovered and resolved, the team must evaluate what went wrong in the development life cycle, explore how it enabled the incident and identify ways to improve the process.

Features and Services That Enable DevSecOps in Azure

The Azure cloud provides several built-in capabilities that make it possible to adopt a DevSecOps process.

1. Azure DevOps

Azure DevOps provides developer services that enable teams to plan tasks, collaborate on code development and build and deploy applications. Azure DevOps supports a collaborative culture and process in which developers, project managers and contributors work together to develop software. You can use Azure DevOps Services in the cloud or Azure DevOps Server on-premises.

2. Build and Deploy Containers With Azure Pipelines

You can integrate Azure Pipelines, the Azure cloud’s CI/CD solution, with your Kubernetes clusters. Use the same YAML document to build multi-stage CI/CD pipelines.

Azure Pipelines lets you track metadata, such as commit hashes and issue numbers, from Azure Boards into container images. This provides direct traceability from any security issue to a specific change made in development. It also provides clear, easy-to-read documentation that can improve the feedback loop between development, operations and security teams.
3. Run and Debug Containers with Dev Spaces

When developing Kubernetes applications, there is a need to test applications locally and understand how they interact with dependent services. You may need to develop and test multiple services in collaboration with other developers or teams.

Azure provides Bridge to Kubernetes, which lets you run and debug code on your development machine while connecting to your Kubernetes cluster. You can test your code end-to-end, set breakpoints on code running on the cluster and share your development cluster among team members. This makes it possible to test and resolve Kubernetes security issues in a realistic environment before deploying to production.

4. Manage Identities and Access with Azure AD

The Microsoft Identity Platform takes the Azure Active Directory (Azure AD) developer platform one step further. It allows applications to accept logins from any Microsoft identity, and obtain tokens that can be used to call Microsoft APIs or APIs created by other developers. This creates a large, interoperable ecosystem.

Azure Active Directory B2C provides B2C identity services—customers get single sign-on (SSO) access to applications and APIs using their preferred social, enterprise or local account ID. Another option is to integrate Azure AD with on-premises Active Directory for hybrid and Azure migration scenarios.

You can also use Azure Role-Based Access Control (RBAC) to manage access to cloud resources. RBAC lets you manage who can access your Azure resources, what they can do with them, and which regions can access them.

You can also use the Microsoft Identity Platform to protect DevOps tools themselves, including native support for Azure DevOps and integration with GitHub Enterprise.

5. Manage Keys and Secrets with Azure Key Vault

Exposed secrets are a severe security issue that is very common in modern applications. Azure Key Vault lets you manage the distribution of secrets by storing them centrally in Azure Key Vault. Key Vault greatly reduces the chance of accidentally disclosing secrets. With Key Vault, application developers no longer need to store credentials or other sensitive information in their application code.

6. Azure Policy and Azure Security Center

Azure Policy lets you specify a default allowed configuration that is automatically applied to all cloud resources. This can avoid misconfigurations that violate security policies. Azure Policy works on the basis of desired state configuration (also known as declarative configuration), letting you specify to what degree resources and services should be secured and whether to alert or block/modify deployments in Azure if they don’t meet the policy.
When using Azure in multi-tenant mode, policies can be applied at the management group, subscription or resource group level. You can define specific policies and enforce compliance requirements for test, staging, and production environments.

The Azure Security Center (ASC) and Advisor can also be easily integrated into the DevOps process. ASC makes it possible to augment event streams in Azure with threat intelligence or analysis by third-party security tools.

7. Penetration Testing

Penetration testing is the recommended method for examining your environment for infrastructure or application configuration vulnerabilities that could create vulnerabilities that an attacker could exploit.

An Azure penetration test should check for vulnerabilities on endpoints, apply fuzzing (malformed input) to discover business logic vulnerabilities, and perform port scanning to identify network vulnerabilities.

Microsoft provides specific guidance for penetration testing in Azure with recommended products and penetration testing service providers.

8. Configuration and Infrastructure Scanning

To ensure security for cloud subscriptions and resource configuration across multiple subscriptions, you can use the tenant security solution part of the Secure DevOps Kit for Azure (AzSK).

In addition, you can leverage Microsoft security technologies like Microsoft Defender for Cloud and Microsoft Sentinel. These solutions provide monitoring and security features designed to detect and alert on unusual events or configurations that require investigation and possible remediation.

Conclusion

In this article, I introduced DevSecOps and showed how the Azure cloud provides a range of services that let you easily implement DevSecOps practices. These include:

Azure DevOps: The venerable toolset with strong support for DevSecOps environments.

Azure Pipelines: The home-grown CI/CD product.

Azure AD: A comprehensive zero-trust identity management solution.

Azure Policy and Security Center: Enables unified control over security policies for cloud automation and security visibility over cloud workloads.
I hope this will be useful as you take your first steps to practice DevSecOps in the cloud.
April 8, 2022
A Closer Look at Azure DevOps
Microsoft’s Azure DevOps Server is emerging as one of the most popular cloud application development environments. Like most continuous integration/continuous delivery (CI/CD) platforms, it provides features such as version control, reporting, project management, automated builds, and testing. It covers all aspects of the application life cycle and enables DevOps. Here’s a closer look at this cloud computing environment.

Azure DevOps provides a number of different developer services that allow DevOps teams to plan work, collaborate on code development and build and deploy applications. It is highly collaborative and brings together developers, project managers and individual contributors to develop software. It allows organizations to create and improve products much faster than with traditional software development approaches.

Services or Server?

Teams can work in the cloud using Azure DevOps Services or on-premises using Azure DevOps Server.

The cloud offering, Azure DevOps Services, is a scalable, reliable and globally available hosted service. It’s backed by a 99.9% SLA, is monitored by Microsoft’s 24/7 operations team and is available in local data centers around the world.

The on-premises offering, Azure DevOps Server, is built on a SQL Server back end. The on-premises version is preferable when organizations need their data to stay within their network or when they want access to SQL Server reporting services that integrate with Azure DevOps Server data and tools.

Although both offerings provide the same essential services, Azure DevOps Services offers some added benefits:
- Simplified server management.
- Immediate access to the new features and updates.
- Improved connectivity with remote sites.
- A transition from capital expenditures (servers, etc.) to operational expenditures (subscriptions).
There are also some other key differences depending on your organization’s or your team’s needs. These can also be helpful if you’re migrating from on-premises to the cloud:
Differences in Specific Feature Areas

Although Azure DevOps Services is a hosted version of Azure DevOps Server, there are some feature differences. Some Server features aren’t supported in Services; for example, Azure DevOps Services doesn’t integrate with SQL Server Analysis Services to support reporting. Process customization and reporting also differ in their support.

Integrated Features

Azure DevOps provides integrated features that can be accessed through a web browser or an IDE client. One or more of the following standalone services can be used based on your organization’s business needs:
- Azure Repos: Azure repos provides Git repositories or Team Foundation Version Control (TFVC) for source control.
- Azure Pipelines: This service provides build and release services to support continuous integration and continuous delivery of applications.
- Azure Boards: This suite of Agile tools supports planning and tracking work, code defects and issues using Kanban and Scrum methods.
- Azure Test Plans: Azure Test Plans provides several tools to test applications, including manual/exploratory testing and continuous testing.
- Azure Artifacts: These allow teams to share packages such as Maven, npm, NuGet and more from both public and private sources and integrate package sharing into pipelines.
Use of the following collaboration tools is also supported:
- Customizable team dashboards with configurable widgets to share information, progress and trends.
- Built-in wikis for sharing information.
- Configurable notifications.
Azure DevOps supports adding extensions and integrating with other popular services, such as Campfire, Slack, Trello, UserVoice and more. In addition, DevOps teams can also develop their own custom extensions.

Azure DevOps Services supports integration with GitHub and GitHub Enterprise Server code repositories. Azure DevOps Server supports integration with GitHub Enterprise Server repositories.

Getting Started

When you sign up for Azure DevOps, you must first register an organization, project and version control type. DevOps teams can create multiple projects and differentiate them with separate names and access permissions. Projects can be set to public or private. Teams can also use Azure Boards for collaboration and project management, and can also configure use of Agile practices. After setting up your team, you can use the platform to begin deploying your applications to Azure.

In addition to a collaborative environment, Azure DevOps provides access to an Azure Pipeline service that supports multiple languages and platforms. The Azure DevOps pipeline is a set of services that are grouped into individual projects.

Additionally, Azure Test Plans feature facilitates automated testing. It is also possible to set up deployment pipelines with different components for multiple applications.

Azure Pipeline can track work status, manage backlogs and create custom reports. With the help of the Azure DevOps pipeline, developers can create, manage and deploy their projects in a single environment. With this solution, DevOps teams will have a single point of contact and can communicate with each other.
March 18, 2022
WhiteSource Tightens Code Scanning Tool Integration with Azure DevOps

WhiteSource has added the Microsoft Azure DevOps platform to the list of continuous integration/continuous delivery (CI/CD) platforms its open source vulnerability scanning tools natively supports.

Susan St. Clair, director of product management for WhiteSource, said while developers are always encouraged to scan for vulnerabilities, it’s more effective if organizations implement scanning by default every time there is a merge request. That approach reduces friction because organizations become much less dependent on developers to scan for vulnerabilities within the context of a larger DevSecOps workflow, she added.

WhiteSource also provides a merge confidence feature that uses crowdsourced data to show how likely it is that an open source component can be updated without breaking the build. Merge confidence includes data on upgrade age, adoption and compatibility to create a confidence score.

The WhiteSource integrations make it possible for DevOps teams to detect all open source components being used and automatically enforce security policies directly from their repository. DevOps teams are provided with vulnerability and misconfiguration alerts and license violations along with detailed remediation guidance, including suggested fixes and prioritization advice, within an existing workflow versus being required to switch to a tool that has a separate user interface (UI) they need to learn.

Should a merge request introduce a new error, the developer is given immediate feedback to resolve any newly introduced vulnerabilities before the request is completed. That approach to separating feature branches and mainline branches prevents interruptions to workflows. The enterprise edition of the WhiteSource tool also automatically generates pull requests in the repository to update vulnerable open source components to the lowest non-vulnerable version.

WhiteSource also supports code repositories such as GitHub, GitHub Packages, JFrog, Bitbucket and GitLab. The Azure DevOps platform is gaining traction as more application development projects are being managed via the cloud following the onset of the COVID-19 pandemic, noted St. Clair.

As more organizations begin to embrace DevSecOps workflows each of them will need to decide how far left they want to shift responsibility for application security. In theory, each developer is now being held more accountable for every one of their applications that gets deployed in a production environment. In practice, most developers lack the expertise required to ensure applications are secure.

There are, of course, more concerns being raised about the security of software supply chains that include open source software in the wake of the recent disclosure of zero-day vulnerabilities in the widely-used Log4j logging tool. Many of the maintainers of smaller open source projects lack the resources required to ensure there are no inadvertent vulnerabilities that could be exploited by cybercriminals. More challenging still, many developers may have used an older version of that software that has known vulnerabilities.

It’s not clear how open source software will ultimately be made more secure. In the meantime, however, it’s clear the onus for ensuring the security of that software is on the DevOps teams that employ it.

February 4, 2022