---
title: "CI/CD for agentic development: from change to controlled release"
description: "Build a verifiable CI/CD workflow for AI-assisted code: tests, traceable artifacts, protected environments, approvals and checks after deployment."
canonical: https://i8.ro/en/blog/cicd-for-agentic-development-from-change-to-controlled-release
---

# CI/CD for agentic development: from change to controlled release

> Build a verifiable CI/CD workflow for AI-assisted code: tests, traceable artifacts, protected environments, approvals and checks after deployment.

Source: https://i8.ro/en/blog/cicd-for-agentic-development-from-change-to-controlled-release

**Series II: From infrastructure to agentic projects in production. Episode 13 of 20.**

A coding agent has prepared a CSV export, a tabular file with values separated by delimiters, for this series' fictional B2B portal. The code passes the tests, and dependencies have been checked. One question remains: how does this change reach production with the same evidence and someone accepting the release? For an SME, this episode proposes an automated verification and release preparation workflow, followed by explicit approval for installation in production.

## What CI/CD automates

**CI**, continuous integration, means frequently integrating changes into shared code, accompanied by automated builds and tests. A *pipeline* is the sequence of stages and conditions that performs these operations. An automated branch check helps, but the practice also involves actual integration, rather than keeping many separately tested branches.

**Continuous delivery** aims to keep software ready for release through a repeatable process. The release decision can remain human. **Continuous deployment** takes changes that pass the workflow's conditions directly to production, without separate human approval for each release. CD can refer to either, so we specify which approach we choose.

Martin Fowler explains this distinction, which is also addressed in research on continuous practices. Shahin and colleagues' academic review, published in 2017, identifies testing, team transparency and appropriate infrastructure among important factors. It is a conceptual reference predating today's agents, not evidence that automation will deliver a particular gain for our portal.

## A concrete path for the CSV export

We use a hypothetical scenario, with no results attributed to a client. The agent developing the portal proposes the change in a *pull request*, a request to integrate code. The requirement specifies export columns, preservation of diacritics and access limited to requests belonging to the user's organisation. The team defines checks before integration.

| Proposed stage | What we check | What permits continuation |
| --- | --- | --- |
| Integration request | Code changes, tests, dependencies and workflow configuration | Review and successful mandatory checks |
| Building the integrated version | Final commit, application image, component inventory and provenance | An identified and verified artifact |
| Preproduction environment | Export, authorisation and configuration compatibility | Successful integration and acceptance tests |
| Production approval | Evidence, risks and rollback plan | The designated owner's decision |
| Installation and subsequent checks | Installed version and essential functions | Confirmation of operation or stopping the release |

**Preproduction**, also called *staging*, is a verification environment similar to production, without unnecessarily using real data. Tests on the integration request do not replace verification of the final version: merging other changes can alter the result. We build and test the release candidate from the integrated commit, the precise version saved in the code repository.

## The same artifact, with suitable environment configuration

An **artifact** is the package produced by a build, such as the application's container image. We propose promoting the same verified artifact from staging to production. We identify it by a **digest**, a cryptographic fingerprint of its content, and retain its links to sources, tests and the SBOM inventory, the structured list of software components from the previous episode.

We do not rebuild on the production server using dependencies that might have changed in the meantime. Secrets and environment configuration are supplied separately. This strategy requires the application to support configuration at runtime. If some values are fixed during the build, we document the difference and test the artifact intended for production; we do not claim two different packages are the same candidate.

The release record includes the run identifier, commit, digest, environment, tests and approver. After installation, we read the version actually running. A “latest version” label is insufficient to demonstrate which package reached users.

## The platform must enforce approval

The agent can change the application and propose pipeline adjustments, but its permissions must not allow it to remove mandatory checks or change approvers. Delivery configuration is also code requiring review. Team policy establishes who administers protections and who can authorise an exception.

GitLab provides approvals for protected environments in its Premium and Ultimate tiers, according to its documentation. Approval does not automatically start the corresponding job, the installation task; it must be started manually. GitHub's required environment reviewers have availability conditions: on Free, Pro and Team plans, they are available only for public repositories. We check the platform's plan and version before designing a workflow around a feature.

A simple “run manually” button is not equivalent to independent approval. We test who can trigger, approve and bypass each control. If the chosen platform lacks the required protection, we establish an alternative mechanism with limited permissions and approval evidence, then verify its behaviour.

## Separate identities and controlled execution

The stage testing proposed code receives no production credentials. The authorised installation stage receives only the access needed for its environment. A *runner*, the process or computer executing pipeline stages, must be managed as part of the project's infrastructure. A protected environment's name does not guarantee isolation of the computer executing code.

For the portal, we propose clean execution workspaces and separation between work running unverified code and work installing approved releases. We prevent simultaneous deployments to the same environment and check that an older run cannot replace a newer version. These rules apply whether the agent works in an integrated development environment (IDE), a terminal or the cloud.

## A green job is not the end of a release

After installation, we check application startup, service responses and a few essential behaviours. For the CSV export, we check a request containing diacritics, an authorised user and denial of access from another organisation, using appropriate test accounts and data. We retain results and establish who monitors errors during the verification period.

A **rollback** returns to an earlier version. We retain the previous artifact and installation procedure, but rolling back the application does not automatically reverse data changes. A **migration** changes the database's structure or contents; deleting a field can make the older application unusable.

For schema changes, we propose compatible steps: add the new structure, adapt the application, and only later remove the old structure. We test compatibility and the recovery plan before release. Restoring a backup can lose subsequent writes, so it is not an automatic substitute for rolling back code. If verification fails, the owner stops further rollout and chooses a remedy suitable for the actual state.

The outcome is a CI/CD record with stages, evidence and approvals. Agents developing the portal use this workflow; agents later integrated into the application are product components with distinct identities. The next episode explains observability, which helps us understand what happens after release and when intervention is needed.

## Sources

Sources verified on 14 October 2026:

- [GitLab, Deployment approvals](https://docs.gitlab.com/ci/environments/deployment_approvals/), for tiers, approvals and starting the job.
- [GitHub, Deployments and environments](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments), for protections, availability and isolation limits.
- [Martin Fowler, Continuous Delivery, 30 May 2013, updated 12 August 2014](https://martinfowler.com/bliki/ContinuousDelivery.html), for the distinction between delivery and automatic deployment.
- [Shahin, Babar and Zhu, Continuous Integration, Delivery and Deployment: A Systematic Review, 2017](https://arxiv.org/abs/1703.07019), for conceptual foundations and challenges of continuous practices.

Want a verifiable release workflow for code written by people and agents? [Talk to i8 about CI/CD, protected environments and acceptance criteria.](https://i8.ro/en/contact)