Open-source alternative to Azure Pipelines release pipelines

Replacing Azure Pipelines classic release pipelines with open source

If your Azure DevOps organization can no longer create classic release pipelines by default, you need a deployment path that you own and can run inside your own infrastructure. Jenkins deployment stages cover most non-Kubernetes releases, and Argo CD covers Kubernetes targets, while the rest of the suite can stay where it is. Your Azure Pipelines YAML definitions and Azure Repos can remain in place during the transition, so you can move releases first and move source control later, or never. Confirm with your Azure DevOps administrator which classic release definitions, task groups and deployment groups actually exist in your organization, because that inventory sets the size of the work.

Map each classic stage to a Jenkins pipeline stage in a Jenkinsfile, with approvals handled by the input step and deployment targets reached through agents or SSH. Deployment groups are the piece most often underestimated: each target machine needs an agent that Jenkins can reach and a credential it can use, and those credentials must be re-created because Azure DevOps does not reveal stored secret values. For Kubernetes targets, Argo CD reads desired state from Git and reconciles clusters, which changes the approval model from a pipeline gate to a pull request review. Check that Argo CD's single sign-on and role settings match your Azure AD groups before any production cluster is connected.

Which open-source option covers each classic release capability

This table maps each classic release pipeline capability to its closest self-hosted open-source equivalent, with a coverage note for every gap. Read the coverage column first, because Argo CD only applies to Kubernetes targets and Jenkins approvals are built from the input step and plugins rather than a built-in release screen.

Classic capability	Open-source option	Coverage note
Release stages	Jenkins pipeline stages in a Jenkinsfile, or Argo CD sync stages for Kubernetes targets	Stages become code in source control. Confirm how your team will map each classic environment to a stage or Argo CD application.
Pre- and post-deployment approvals	Jenkins input step, optionally with plugins for approver groups	No direct equivalent to classic approval records. Confirm who approves, how approvals are logged, and whether your audit evidence needs them.
Gates (automated checks)	Jenkins stage conditions and test steps; Argo CD sync windows and health checks for Kubernetes	Gates must be written as pipeline logic. Argo CD health checks cover only Kubernetes resources, so confirm any non-Kubernetes gate separately.
Task groups	Jenkins shared libraries or reusable pipeline functions	Reusable logic moves into code. Confirm that each task group's inputs and defaults are migrated and reviewed.
Deployment groups	Jenkins Kubernetes agents or SSH-reached agents for non-Kubernetes hosts	Argo CD applies only to Kubernetes targets. Confirm connectivity and credentials for every VM or bare-metal host in the group.
Variable groups and secrets	Jenkins credentials and Configuration as Code for non-secret settings	Secret values cannot be exported from Azure Pipelines and must be re-entered. Confirm ownership and rotation for each secret.
Environments and Kubernetes targets	Argo CD applications and projects with RBAC	Argo CD 3.0 requires repositories as Kubernetes Secrets. Confirm access rules after upgrading, since RBAC changed in the 2.14 to 3.0 line.
Release logs and history	Jenkins build records and Argo CD application history	Azure Pipelines run history and logs must be exported before decommissioning. Confirm retention in your Jenkins and Argo CD controllers.

When Jenkins or Argo CD fits a classic release replacement

Classic release pipelines mixed build, approval and deployment into one tool, so the replacement usually splits in two. Jenkins deployment stages cover VM, bare-metal and mixed estates, while Argo CD covers Kubernetes targets through Git. The cards below set out what each option takes on and what your team must check before choosing.

Jenkins deployment stages for mixed targets

Jenkins is distributed under the MIT License and has more than 2,300 community plugins, so it can run deployment stages against VMs, bare-metal hosts and Kubernetes from one Jenkinsfile. A controller schedules work and dedicated build agents run it, which keeps build load off the controller. The trade-off is that you own every plugin, its upgrade path and the controller's $JENKINS_HOME backup. Confirm which plugins your current release tasks depend on before you design stages.

Agents and controllers for deployment work

The Jenkins scaling guide recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment. Deployment jobs that need SSH access to production hosts should run on agents placed in the right network zone, not on the controller. Ask who will patch agent images and rotate the credentials they hold. Plan a primary and backup controller if release windows cannot tolerate an outage.

Argo CD for Kubernetes targets

Argo CD is released under the Apache License 2.0 and sits in the Argo project, which reached Graduated status in the CNCF on December 6, 2022. It reconciles cluster state against manifests in Git, so a release is a commit rather than a pushed pipeline step. This suits teams whose classic releases targeted Kubernetes namespaces. It does not run VM or bare-metal steps, so pair it with Jenkins where those targets remain.

Git state instead of pipeline steps

Argo CD works from the desired state stored in Git, so an approval is a reviewed merge and a rollback is a revert. Classic release approvals move into pull request review and branch protection, which changes who can release and how audit evidence is gathered. Check that your change management process accepts Git history as approval evidence. Confirm how the team will handle secrets, since Argo CD 3.0 requires repositories to be defined as Kubernetes Secrets.

Argo CD access and high availability

Argo CD 3.0 changed RBAC so update and delete rights apply only to the application itself, and logs need an explicit permission. Its user management guide recommends disabling the built-in admin user once SSO or local users are configured. High availability manifests need at least three nodes because of pod anti-affinity rules. Confirm your cluster meets that footprint and that your identity provider works with the bundled Dex or direct OIDC.

Keeping Jenkins and Argo CD in step

Using both tools means two release models, two access models and two places to look during an incident. Jenkins can trigger an Argo CD sync, but the boundary between them must be written down so one tool does not deploy what the other owns. Assign an owner for each target type and document which tool owns rollback. Confirm that your team can run both upgrade cycles, since Argo CD ships minor releases every three months.

How deployment groups and task groups become Jenkins agents and shared code

Deployment groups and task groups have no one-to-one Jenkins equivalent, so the first decision is to split them by what they do. A deployment group is a set of target machines that receive a deployment. In Jenkins, each of those machines is usually reached in one of two ways: a Jenkins agent installed on the host, or an SSH step that copies artifacts and runs commands from a build agent. Inventory every deployment group, record its machines, operating systems and the account each deployment uses, and decide per group which pattern fits. Agents suit hosts that need a persistent connection and a local tool chain. SSH steps suit short-lived access to hosts you do not want to run a long-lived agent on. Confirm how your existing targets authenticate before you choose.

A task group is a reusable sequence of tasks. In Jenkins, these become functions in a shared library or reusable pipeline steps that Jenkinsfiles call by name. Service connections and variable groups must be rebuilt as Jenkins credentials, and the values of secret variables cannot be read back from Azure Pipelines, so each one must be re-entered from its original owner. Jenkins Configuration as Code can declare the non-secret parts of the controller, such as folders, agent definitions and credential references, from YAML files located through the CASC_JENKINS_CONFIG variable. The plugin does not install plugins, so pin every plugin version in a Docker image or the Helm chart, and treat that image as the controller's release artifact.

Plugin management needs its own check. Jenkins LTS 2.580.1 stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins, so an administrator who upgrades to that baseline must install them through the plugin manager or the pinned image. Verify that the SSH and JUnit plugins that your deployment steps depend on are present after each upgrade, and run a test deployment to a non-production group before you switch production traffic. Record the pinned plugin list in version control alongside the Configuration as Code files, so the next upgrade is a reviewed change rather than an undocumented drift.

Choosing the target: virtual machines, Kubernetes or both

Teams that deploy to virtual machines or bare metal servers usually replace classic release stages with Jenkins deployment stages. A Jenkinsfile defines the stages, and the deployment step connects to hosts through SSH, configuration management or a vendor tool. Approvals move into the pipeline as input steps, so the person who approves a production stage is recorded in the build history rather than in a release definition. Rollback is a pipeline decision: the previous artifact is redeployed by running an earlier build, which only works if artifacts from prior builds are kept in a location you control.

Approvals: Pipeline input steps replace classic approval gates. Confirm which groups may approve each environment and how approvals are logged.
Rollback: Redeploy a prior build number or artifact. Retention of old artifacts becomes your responsibility.
Credentials: SSH keys and host secrets move into Jenkins credentials. Confirm how they are rotated, since the old values in Azure Pipelines cannot be read back.
Deployment groups: Agents on target hosts or a configured SSH target list replace deployment group agents. Confirm the host inventory and network paths from the Jenkins controller or agents.
Platform team inputs: Host access, a change window process and a named owner for each server group.

Check whether your target servers can be reached from Jenkins agents under your network policy before writing any stage.

Migrating release stages, approvals and secrets off Azure Pipelines

This sequence moves classic release stages, approvals and deployment secrets into Jenkins or Argo CD in a controlled order, keeping history and evidence before the classic definitions are retired.

Inventory and export classic release definitions
Your release engineers list every classic release definition, task group and deployment group through the Azure DevOps REST API and save each definition as a JSON file in a version-controlled export folder. Record which stages, environments, triggers and approvers each release uses, and note which definitions have no owner. The step is done when every active definition has an exported file and a matching row in an inventory sheet that your team has reviewed.
Rebuild stages as Jenkinsfile deployment stages
Platform engineers translate each exported stage into a stage in a Jenkinsfile committed to the application's repository, using Declarative syntax where it fits. Deployment targets that run on Kubernetes move to Argo CD instead, with the desired state kept in Git. The output is a pipeline that builds, tests and deploys each environment from source control, and a short mapping document that links each classic stage to its new stage.
Re-create approvals as input steps
Pipeline owners add input steps to the Jenkinsfile wherever the classic release required a manual approval, and restrict who may submit each input to the approver groups recorded in the inventory. For Argo CD targets, approvals move to the Git review process or to the sync policy your team chooses. Confirm with a test run that a deployment pauses at each gate and that an unauthorized user cannot proceed.
Re-create service connections and secret variables
Azure DevOps does not return the values of secret variables or service connection credentials, so your security team issues new credentials in the target systems and stores them in Jenkins credentials or the secrets store you have chosen. For Argo CD 3.0 and later, repositories must be defined as Kubernetes Secrets rather than in the argocd-cm ConfigMap, so the platform team creates those Secrets and checks that Argo CD can read each repository. The step closes when each secret has a named owner, a rotation date and a test deployment that succeeds.
Run parallel releases and compare results
Operate the classic release and the new pipeline side by side for a set of non-production deployments, comparing artifact versions, configuration values, deployment logs and final state in each environment. Differences are logged as defects against the new pipeline and fixed before any production change. The check passes when the team signs off on matching outcomes for every environment in the inventory.
Export release history and logs before decommissioning
Before the classic definitions are switched off, your team exports release history, stage logs, approval records and attached artifacts, since these are kept in Azure DevOps and may not remain available once the definitions are removed. Store the export in an archive your audit team can access, and record its location in the migration register. Confirm with your compliance lead that the archive meets your record retention requirements.
Cut over and retire classic definitions
Switch production deployments to the new Jenkins stages or Argo CD applications during an agreed change window, with a tested rollback path to the previous release. Once the new pipeline has run successfully through its normal cycle, disable the classic release definitions first, then delete them after the retention period your team has agreed. The step closes when the inventory shows every release migrated, the archive is verified and the old definitions are gone.

Keeping Azure Repos and YAML pipelines while releases move

Most teams will not move source code, builds and releases on the same day. The cards below cover the integration points that let Jenkins deployment stages or Argo CD take over releases while Azure Repos and YAML builds keep running. Each one names a decision and a check to run in your own environment before you cut over.

Jenkins triggered from Azure Repos

A Jenkins deployment stage needs to start when a build in Azure Repos finishes or when a branch changes. Decide whether Azure Pipelines publishes an artifact that Jenkins pulls, or whether Jenkins polls or receives webhooks from the Azure DevOps repository. Confirm which Azure DevOps webhook events your Jenkins version can consume, and confirm who owns the service account that reads the repository. Record the trigger path in your change plan so a failed webhook does not silently stop a release.

Azure Pipelines kept for build

During the transition, many teams keep YAML builds in Azure Pipelines and move only the release step. The handoff is the artifact: a versioned package, container image or Helm chart that Jenkins deploys without rebuilding. Confirm that the artifact version recorded in Azure Pipelines matches what Jenkins deploys, and confirm where artifacts are stored after the build. Azure Pipelines retention settings should be checked so that releases can still be traced to a build during the overlap.

Jenkinsfile beside YAML pipelines

Two pipeline definitions for the same application create drift risk. A Jenkinsfile that deploys the same artifact as an Azure Pipelines YAML release stage can end up with different approval gates, environment names or variable sources. Decide which system owns each environment, and document the single owner for each stage. Review both definitions at each change so that a deployment approved in one tool is not run from the other.

Service connection and credential handoff

Azure DevOps service connections and variable group values cannot be read back after they are set, so the Jenkins credentials store must be populated again from the original sources. Confirm which deployment credentials have rotated since they were created, and issue new scoped credentials to Jenkins rather than copying old ones. Plan the cutover so that the old and new credentials are not both valid for longer than the overlap requires.

Azure AD SSO for Argo CD

For Kubernetes targets, Argo CD can authenticate users directly through an existing OIDC provider such as Microsoft, or through its bundled Dex with connectors. Choose one path, map Entra ID groups to Argo CD roles, and confirm that the mapping works before disabling local accounts. Argo CD user management documentation recommends keeping the built-in admin user only for initial setup and disabling it with admin.enabled set to false once SSO works. Confirm the group claim your tenant emits, because role rules depend on it.

What do buyers ask before replacing classic release pipelines?

What does replacing classic release pipelines actually cost?

The cost is mostly people and running infrastructure, not licences, because Jenkins is MIT-licensed and Argo CD is Apache 2.0 licensed. The main components are the time spent inventorying stages, approvals and deployment groups, the Jenkins controller and build agents, the Kubernetes clusters that host Argo CD, storage for artifacts and logs, and the migration work itself. One-time costs include discovery, pipeline conversion and secret re-entry. Recurring costs include upgrades, plugin maintenance and on-call operations. Ask any quote to split these components so you can see who is paid for what.

What drives the cost and timeline up or down?

The biggest drivers are the number of classic release definitions, how many stages and approval gates each one has, how many deployment groups point at physical or virtual machines, and how many secrets must be re-created by hand because their values cannot be exported. Integrations with ticketing or change systems also add work. Fewer, well-documented pipelines with standard deployment targets move faster. Your written scope should list these counts so the estimate reflects your estate rather than a generic template.

How long does a migration take?

No general duration is given here because it depends on the release inventory and the target. A small set of pipelines deploying to one Kubernetes cluster is a different job from dozens of release definitions spread across Windows servers and multiple environments. Plan the work in phases: discovery, a pilot pipeline, parallel runs against non-production environments, then cutover. Ask for a fixed-scope timeline in writing that names each phase and the environments it covers.

What does our team need to provide before work starts?

Prepare a complete release inventory: each classic release definition, its stages, pre-deployment and post-deployment approvals, variable groups, task groups and deployment groups. You also need named approvers and their approval rules, read access to the Azure DevOps organization, and a test environment for parallel runs. For Kubernetes targets, you need cluster access with rights to create namespaces, service accounts and Argo CD resources. Confirm with your own security team how secrets will be handed over, since values cannot be read back from Azure Pipelines.

Can our own engineers do this migration without a partner?

Yes, if you have engineers who know Jenkinsfiles or Kubernetes GitOps and can run a pilot first. Many teams do the simplest pipelines in house and bring in outside help for approvals, secret handling, cluster hardening or the stages that span several environments. The deciding factors are the team's skills, the number of production pipelines and how much audit evidence you must produce. A fixed-scope engagement with DeployOpen starts with a written scope, so you can compare it with an internal plan.

Will Argo CD's upgrade cadence change how we operate it?

Yes. Argo CD ships a minor release four times a year, roughly every three months, and only the three most recent minor versions receive patch releases. That means you need a repeatable upgrade routine and must not fall behind on minor versions. Plan a regular maintenance window and test each upgrade in a non-production cluster. Ask any provider how they will track releases and when they will apply patches in your environment.

What changes in Argo CD 3.0 access control and repository setup?

Argo CD 3.0 changed RBAC in ways that affect your access model. Update and delete permissions now apply only to the application itself, logs access needs an explicit logs, get permission, and Dex-based RBAC uses the federated_claims.user_id claim. Repositories must be defined as Kubernetes Secrets because repository configuration was removed from argocd-cm. Review the 2.14 to 3.0 upgrade notes before you migrate, and test that each team can still see and act on only its own applications.

Running Jenkins and Argo CD after cutover

After cutover, the work shifts from migration to routine operation, and the first thing to plan is the Jenkins upgrade rhythm. Jenkins picks a new LTS baseline every 12 weeks from a recent weekly release, then ships three LTS releases for that baseline in four-week cycles that contain only backported fixes. Plan a standing upgrade window that follows this cadence rather than waiting for a breaking change. Check the Java support policy before each upgrade: it lists Java 21 with a planned end of support in September 2027 and Java 25 with a planned end of support in September 2029, and it names 2.541.3 as the final LTS release for Java 17. Also confirm which plugins the current LTS line still bundles, because the 2.580.1 changelog says several, including the SSH server and JUnit plugins, must now be installed through the plugin manager. Test the upgrade in a non-production controller first.

Everything that defines the Jenkins controller lives in $JENKINS_HOME, including configuration, plugins and secrets, so that directory is the core of your backup and recovery plan. Back it up on a schedule, encrypt the copies, and restore a copy to a scratch host at least once to prove it works. If you adopt Configuration as Code, keep the YAML under version control, but remember that the plugin itself does not install plugins, so pin plugin versions through your Docker image or Helm chart. For availability, the Jenkins scaling guide describes a primary and backup controller behind a proxy such as HAProxy or F5, which routes traffic to the backup if the primary fails. Confirm with your platform team how failover affects in-flight builds and credentials, because the guide does not replace testing that arrangement in your own environment.

Argo CD, which handles the Kubernetes deployment targets, follows its own cadence. A minor release ships four times a year, roughly once every three months, and only the three most recent minor versions receive patch releases, so schedule an upgrade at least once a year to stay within support. For access control, use the Dex-based SSO or an external OIDC provider, then set admin.enabled to false once local users or SSO are configured, keeping the built-in admin account only for initial setup. High availability needs at least three nodes because of the pod anti-affinity rules in the HA manifests, and IPv6-only clusters are not supported. Argo CD keeps its state in Kubernetes objects and treats Redis as a disposable cache, so back up the cluster resources that define your applications and repository Secrets, and verify the node count with your infrastructure team before enabling HA.

How DeployOpen scopes and delivers a classic release replacement

DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, including the deployment stages and approvals that classic release pipelines used to hold. For this topic, the work starts with an inventory of existing stages, approvals and deployment groups, then maps each one to Jenkins deployment stages or to Argo CD for Kubernetes targets.

How we scope

The written scope lists each classic release stage, approval gate and deployment group to be mapped.
Scope states which targets move to Jenkins deployment stages and which Kubernetes targets move to Argo CD.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Pipelines are defined as Jenkinsfiles committed to the project's source control repository.
Jenkins is configured through Configuration as Code YAML files, with plugins pinned in the deployment image.
Argo CD repositories and credentials are defined as Kubernetes Secrets, with SSO connected to the client's identity provider.

How we hand over

Handover covers the runbook, the mapping from each classic release to its replacement, and the backup of $JENKINS_HOME.
Secrets are re-created in the new platform's credential store, since existing values cannot be read back for transfer.
Clients receive documentation of approval steps, rollback procedures and the list of plugins and Argo CD versions in use.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover Jenkins LTS upgrades and Argo CD patch releases in the client's maintenance window.
Ask in the quote which upgrade cadence, testing and response arrangements are included in a retainer.

Open-source alternative to Azure Pipelines classic release pipelines