Vendor change-management promotion

In this pattern, an existing change-management product remains authoritative for moving objects from development to QA to production. CoderFlow replaces the manual edit / compile / test loop and feeds the developer's dev library; the change-management product promotes from there exactly as it does today. The goal is to add agentic development with the smallest possible change to an established promotion process.

When to choose this

• You already run a change-management product that compiles in QA and promotes objects to production, and you want it to stay authoritative.
• Your auditors or committees rely on that product's request tracking and approval gates, and you do not want to move those into a new tool.
• You want CoderFlow to change how source is produced, not how it is promoted.
• A single shared QA library is part of your current process.

At a glance

Aspect	This pattern
Promotion engine	The existing change-management product (unchanged)
Long-lived branches	One — main, which mirrors production
Feature branches	One per change-management request, e.g. feature/<request-id>
Where agents work	Per-task container with a temporary build library; approved source syncs to the developer's own dev library (DEVLIB)
QA / production build	The change-management product compiles in shared QA and promotes the object to production
main merges	Only after the change reaches production
Contention point	The single shared QA library

How a change flows

Git (one repository)                 CoderFlow                IBM i
─────────────────────                ─────────                ─────
main  = production
  │
  └─ feature/<request-id> ──► task ──► review + approve ──► Sync ──► DEVLIB  (per developer)
                                                                       │
                                              change-management product promotes
                                                                       ▼
                                                                     QALIB   (shared QA)
                                                                       │
                                              approved object cloned to production
                                                                       ▼
                                                                     PRODLIB (production)
  ▲                                                                    │
  └──────────────── PR merges only after production is reached ────────┘

Source enters the repository two ways: through Import IBM i Sources (initial and incremental) and through CoderFlow tasks (new work). Approved task changes sync to the developer's dev library. The change-management product handles dev → QA → production, unchanged. The pull request merges to main only after production.

Branch and library model

One long-lived branch. main mirrors production. Every change is a short-lived feature/<request-id> branch off main, with a pull request that stays open for the life of the change and merges only after the change reaches production. Because main always equals production, any developer with an open pull request can tell at a glance whether their branch has fallen behind.

Libraries:

Library	Role	Owned by
<task-lib>	Temporary per-task build library during authoring	CoderFlow (created and dropped per task)
DEVLIB	A developer's own dev library for unit testing	CoderFlow sync target; the change-management product promotes from here
QALIB	Single shared QA / UAT library	The change-management product
PRODLIB	Production	The change-management product

A single Git repository holds all IBM i source. One repository (rather than one per project) keeps shared tables, subprocedures, and widely-called programs in one place, keeps cross-program dependencies visible, and lets the build rules in the repo be inherited by every branch and future project.

The development loop — single developer

When no one else is touching the same program, a change looks like this:

1. The developer starts a task from main.
2. The agent edits and compiles source in the task's container and temporary build library.
3. The developer reviews (diffs, 5250 / Rich Display sessions, optional AI judge) and approves. Approval creates the commit and opens the pull request.
4. CoderFlow syncs the approved source to the developer's dev library (DEVLIB).
5. The developer unit-tests in DEVLIB.
6. The change-management product promotes dev → QA.
7. The business tests in QA.
8. The committee approves.
9. The change-management product promotes QA → production.
10. The pull request merges to main.

The pull request stays open through the entire test-and-promote cycle and merges at the end, after production. Nothing in this loop changes the change-management product's role.

Re-sync after every merge. Whenever the agent merges other work into a branch (see below), sync the result to the dev library before re-testing. Otherwise the dev library still holds the pre-merge version and testing happens against code that does not match the pull request.

Concurrent development — two changes to one program

Git branches are independent, and per-developer dev libraries do not collide. The collision is at the shared QA library. If the change-management product is configured to clone the QA-compiled object directly to production (no recompile at promotion), then whatever sits in QALIB at the moment of promotion is what goes to production — so only one developer's compiled copy of a given program can be in QALIB at a time.

This is handled by serialization, which is the same practice a shared-QA shop already uses:

1. Both developers work their own feature/<request-id> branch from main, approve, and sync to their own dev library.
2. Both promote through the change-management product. QALIB holds whichever was promoted most recently; the other developer's compiled object is overwritten. Both requests remain tracked as open.
3. Before the first developer's change can go to production, the second developer rejects their request back to their dev library, and the first developer re-promotes so that QALIB holds their object at the moment of promotion.
4. The committee approves and the object is cloned to production. The first developer's pull request merges to main.

Catching the second developer up. main now has the first developer's change; the second developer's branch does not. With CoderFlow the catch-up is a Git merge performed by an agent, not a manual source merge on IBM i:

1. The second developer starts a new task from fresh main and instructs the agent to merge their prior branch on top of it — for example: "Merge <my-branch> on top of current main, which already has <other-branch> (PR #N). Keep both sides' intent. Ask if unclear. Compile to verify."
2. The agent merges in the task's working directory — applying non-overlapping changes automatically, proposing a resolution that preserves both sides' intent for real overlaps (or pausing with a specific question), and compiling the merged programs in the task's temporary library to confirm the build. Nothing is committed yet.
3. The developer reviews and approves. Approval creates the commit and opens a new pull request, and the sync refreshes the dev library, replacing the stale copy.
4. The developer re-tests and promotes through the change-management product to production, and the pull request merges to main.

The merge is done by the agent with human review — no manual text-merging across IBM i libraries — and the "reject back to dev" step is already part of a shared-QA shop's current practice. The change-management product still sees one request at a time moving dev → QA → production.

Pull requests are optional

The review gate in this pattern is CoderFlow task approval together with your change-management product's request tracking and committee approval — not the pull request. Here the pull request mainly does bookkeeping: it keeps main equal to production and records the merge that happens after production. You can run the pattern without pull requests, with one adjustment to how main stays equal to production.

With pull requests (the default above). Each change is a feature/<request-id> branch with an open pull request that merges to main after production. The open pull request also gives every developer an at-a-glance signal of whether their branch has fallen behind production.

Without pull requests. Keep working on a feature/<request-id> branch. At approval choose Push to branch (or Create new branch on the first task) instead of opening a pull request, sync to DEVLIB, and let the change-management product promote as usual. Because no pull request is merging to main after production, keep main equal to production another way:

• Deferred merge. After the change reaches production, an agent merges the branch into main in a short task and pushes directly (or you merge from the CLI). main still updates only after production — the invariant holds; only the mechanism changes from a pull-request merge to a direct push.
• The catch-up merge described above (when another developer's change reaches production first) works the same way: the agent performs the merge in a task and approval pushes the result directly, with no pull request.

Two caveats: pushing to main may be blocked by branch protection on your Git host (allow the push identity, or keep a pull request for just the main merge), and without an open pull request you lose the at-a-glance "is my branch behind production?" signal — compare against main, which equals production, instead.

Database file (DDS) changes

Because the change-management product compiles QA and production in this pattern, schema changes to existing physical and logical files are handled by that product's compile sequence and related-object processing (and by your DBA practices) exactly as they are today. codermake runs only in the task's temporary build library, giving the agent a fast, dependency-aware test compile before approval; it does not gate promotion here. Sync writes source to the dev library, where compiling it for unit test stays the traditional, change-management-product-driven step it is today. (This is the main practical difference from the CoderFlow-native build pipeline, where codermake builds QA and production and existing-file changes need an explicit migration step.)

Changes made outside CoderFlow

If a source member is edited directly on IBM i — an emergency patch, an external tool, or periodic reconciliation — bring it back in by re-running Import IBM i Sources. Re-import compares the library's current source against the repository, opens a task with the discovered differences, and proceeds through the normal review-and-approve flow. It runs only when a developer initiates it; there is no background process.

Setup and invariants

To stand this up:

• One CoderFlow environment pointing at the single source repository, with an IBM i connection that has Sync enabled.
• Rules.mk build rules generated once from existing objects (see Generate IBM i Build Rules) and committed to the repo.
• A first batch of source imported — typically whatever is on the active change-management request queue — with more imported incrementally as scope grows.
• A branch naming convention, commonly the change-management request id.

Invariants this pattern depends on:

Invariant	Why it matters
One repository holds all IBM i source	Prevents duplication and drift
main merges only after production	Keeps main equal to production, which makes "merge in the other change" safe
The change-management product owns dev → QA → production	Minimizes process change
Build rules live in the repo	Shared by every branch, task, and project
The shared QA library clones to production	Makes "reject back to dev" mandatory when two changes to one program are in flight
The dev library is re-synced after every merge	Prevents testing against stale, pre-merge code