CoderFlow-native build pipeline

In this pattern, CoderFlow owns the whole path from a developer's idea to the production library, with no external build server or change-management product. Agentic development runs on a dedicated development partition. When a change lands on a long-lived branch, a CoderFlow automation fires a deployment profile that runs codermake against the target libraries — building QA from one branch and production from another.

When to choose this

• You have no change-management product, or you are replacing a build server, and you want builds and promotion driven by Git branch merges.
• You want a single tool — CoderFlow — to cover authoring, review, build, and deployment, with one audit trail.
• You are comfortable building QA and production objects from source with codermake (rather than promoting pre-compiled objects).
• You can keep agentic work off the production system by running it on a separate development partition.

At a glance

Aspect	This pattern
Promotion engine	CoderFlow automations + deployment profiles
Long-lived branches	Two — main (production) and qa (QA / UAT)
Feature branches	One per ticket, e.g. feature/<ticket>
Where agents work	Per-task container with a temporary build library, on a dedicated development partition
QA / production build	codermake rebuilds only changed objects on the target, triggered by a branch merge
Promotion trigger	A new commit on qa builds QA; a new commit on main builds production
No agents on the QA/production system	That system only sees codermake invoked by the deployment

How a change flows

Git (one repository)         CoderFlow                              IBM i
─────────────────────        ─────────                              ─────
feature/<ticket> ──► task on the development partition ──► review + approve ──► push
       │                (per-task temp build library, codermake)
       ▼  PR
     qa  ───────────► SCM-poll / webhook automation ──► "qa" deployment profile
       │                                                  (runs codermake) ──► QALIB / QALIBDTA
       ▼  cherry-pick after QA / UAT
    main ───────────► SCM-poll / webhook automation ──► "production" deployment profile
                                                          (runs codermake) ──► PRODLIB / PRODLIBDTA

Authoring happens on the development partition in an isolated task. After approval, the change moves through Git: a pull request into qa, then a cherry-pick into main once QA/UAT is complete. Each merge is what triggers the corresponding build — CoderFlow watches the branches and runs the matching deployment profile.

Branch and library model

Two long-lived branches, each bound to a target the way the deployment profiles are configured:

Branch	Role	Built into
qa	Source that has cleared review and is built for QA / UAT	QALIB / QALIBDTA
main	Production	PRODLIB / PRODLIBDTA

A developer branches from main to a short-lived feature/<ticket> branch. When the work is ready for QA/UAT, a pull request merges the feature branch into qa. Once the change clears QA/UAT, the relevant commits are cherry-picked from qa into main for production.

Libraries:

Library	Role	Where it lives
<task-lib>	Temporary per-task build library during authoring	Development partition (created and dropped per task)
QALIB / QALIBDTA	QA / UAT programs and data	QA/production IBM i system
PRODLIB / PRODLIBDTA	Production programs and data	QA/production IBM i system

The per-task build library is the agentic-development equivalent of a developer's private build library — created when the task container starts and dropped when the task is approved and pushed. See Task Libraries.

The development loop

1. A developer submits a task in CoderFlow (from a ticket or directly). The task launches an isolated container on the development partition with its own temporary build library, the build tools (codermake, Rules.mk), and the configured connections.
2. The agent edits source and runs codermake to compile into the task's temporary library.
3. The developer verifies using the same tools regardless of who wrote the code — changed-file diffs, built-in VS Code for manual edits, interactive 5250 / Rich Display sessions against the task library, and optional AI judge agents. Follow-up instructions send the agent back to work in the same container.
4. The developer approves. Approval commits with a generated (editable) message, pushes to the feature/<ticket> branch, and can open the pull request into qa directly from the approval dialog. The container is torn down and the temporary library is dropped. See Approval & Deployment.

All agentic development runs on the development partition, so production data and the QA partition are untouched during authoring.

Promotion — branch-triggered deployment

Promotion is driven entirely by CoderFlow, with two pieces:

Deployment profiles define the build for each target. They live in the environment's setup repository as a small JSON definition plus a shell script:

environments/
  <environment>/
    deployment-profiles/
      qa.json          production.json
      qa.sh            production.sh

Each script checks out the triggering branch and runs codermake, which reads the Rules.mk files, infers build recipes from file extensions (RPGLE, CL, DSPF, PF/LF, SRVPGM, SQL, and so on), tracks dependencies, and builds only what changed into that profile's configured target libraries. The qa profile targets QALIB / QALIBDTA; the production profile targets PRODLIB / PRODLIBDTA. See Deployment Profiles.

Automations trigger those profiles when a branch changes. Configure one SCM-polling or webhook automation per long-lived branch:

• A new commit on qa runs the qa deployment profile → builds QA.
• A new commit on main runs the production deployment profile → builds production.

With SCM polling, CoderFlow watches a branch and runs the linked profile only when the branch's commit SHA changes; the watched branch and SHA are passed into the deployment so the build is pinned to the exact observed commit. With an inbound webhook, your Git host posts a push event and CoderFlow runs the linked profile immediately. You can enable both — webhook for immediacy, polling as a backup — and CoderFlow deduplicates the two when they see the same SHA.

No human intervention is required for a build once a commit lands on qa or main. Every run is recorded in the automation and deployment history with the triggering commit, branch, output, and status.

Pull requests are optional

The review gate in this pattern is CoderFlow task approval — changed-file diffs, 5250 / Rich Display sessions, and the optional AI judge. A pull request is an optional second gate and a branch-merge record, not the quality gate. You can run the whole pattern with or without pull requests.

With pull requests (the default above). Base each task on main, choose Create new branch at approval to push a feature/<ticket> branch, then Create pull request into qa. You get branch protection, a Git-host review record, and a clean merge history.

Without pull requests. Base the task on qa itself and push straight to it:

1. Create Task — set the branch to qa (instead of the default main). The agent checks out qa and works on top of it.
2. Review as usual.
3. Approve — adjust the commit message, check Push to branch (leave Create new branch and Create pull request unchecked), and commit. The commit pushes to qa, and the SCM-poll/webhook automation runs the qa deployment profile to build QALIB.

Two things to know about the direct-push flow:

• The Approve dialog pushes to the branch the task was based on, or to a brand-new branch — not to a different existing branch. So "no pull request" means basing tasks on the target branch and pushing to it (trunk-style on qa), not starting on main and diverting the push to qa.
• Every approval rebuilds QA. Without the pull-request buffer, each direct push to qa triggers a QA build, so push finished work — or keep a pull request gate on just the qa step while leaving everything else direct. (If you instead want a shared line that builds a dev library before anything reaches QA, that is the minimal dev + main pattern, not this one.)

Production stays gated either way. Promoting qa → main is a separate step: a task based on main that cherry-picks or merges the qa commits and pushes to main, or a pull request for that step. If main is branch-protected on your Git host (common for production), that push needs a pull request or an allowed push identity — so production is usually where a gate stays even in an otherwise no-PR flow.

Concurrent development

Feature branches are independent, and each task gets its own temporary build library, so two developers never collide during authoring. Integration happens in Git: each feature/<ticket> branch merges into qa through a pull request, and codermake rebuilds only the changed objects on the next QA build. Because the QA build runs from whatever is on qa, the qa branch is the single integration point — resolve overlapping changes there (an agent can perform the merge in a task, with human review) before the build runs.

Database file (DDS) changes

codermake can create new physical files (PFs) and logical files (LFs) from DDS using CRTPF and CRTLF, but it does not modify a PF or LF that already exists in the target library. If the DDS for an existing file changes, codermake will fail to build that object. This applies everywhere codermake runs: the per-task temporary library, QALIB, and PRODLIB.

Implication. Any change to an existing physical or logical file must be handled by a developer- or DBA-supplied migration step — typically a CL that uses CHGPF, or recreates the file and preserves data with CPYF, then rebuilds dependent objects. The agent does not perform this automatically; run the migration as part of (or before) the deployment that depends on it. This is a property of codermake itself, not of the CoderFlow integration. (In the Vendor change-management promotion pattern this limitation does not gate promotion, because the change-management product compiles QA and production rather than codermake.)

Re-runs and changes made outside CoderFlow

• Re-run a build without a new commit. Run a deployment profile manually from the environment's Deploy tab — useful to recover from a transient failure or to rebuild a target on demand.
• Source edited directly on IBM i. Bring it back into the repository by re-running Import IBM i Sources, which opens a task with the discovered differences for normal review and approval.

Setup and invariants

To stand this up:

• One CoderFlow environment for the application repository, with IBM i connections to the development partition (for tasks) and to the QA/production system (for deployments).
• Rules.mk build rules generated from existing objects (see Generate IBM i Build Rules) and committed to the repo.
• Two deployment profiles — qa and production — in the setup repo, each configured for its target libraries, with any deploy-scoped secrets (for example, an SSH key for the QA/production system).
• Two automations — one watching qa, one watching main — each linked to the matching deployment profile via SCM polling or a webhook.

Invariants this pattern depends on:

Invariant	Why it matters
One repository holds all IBM i source	codermake dependency tracking and the build rules cover the whole tree
qa builds QA, main builds production	Each long-lived branch maps to one set of target libraries
Agentic work runs only on the development partition	Keeps agents off the production system; that system only runs codermake
Existing-file DDS changes have a migration step	codermake will not alter an existing PF/LF
Build rules live in the repo	The same codermake build works for the task library, QA, and production