Minimal: dev + main

The least-ceremony configuration: no external change-management product, no pull requests, and no separate QA/UAT stage. Two long-lived branches do the work — dev, where developers approve their changes directly and which builds a shared development/test library, and main, which builds production. It is the CoderFlow-native build pipeline stripped to its minimum: a good starting point for a small team, or for getting moving before a heavier process is warranted.

When to choose this

• A small team or a single shop, with no formal change-management tool and no committee-gated QA/UAT.
• You want the fewest moving parts: two branches, no feature branches, no pull requests.
• A shared development/test library is enough of a staging step before production.
• You expect to graduate to the CoderFlow-native build pipeline (add a qa stage and pull requests) or the vendor change-management pattern as the team and governance needs grow.

At a glance

Aspect	This pattern
Promotion engine	CoderFlow automations + deployment profiles
Long-lived branches	Two — dev (shared test build) and main (production)
Feature branches	None — developers work directly on dev
Pull requests	None
Where agents work	Per-task container with a temporary build library
dev / production build	codermake rebuilds only changed objects, triggered by a branch commit
Promotion trigger	A commit on dev builds the shared test library; a commit on main builds production

How a change flows

Git (one repository)         CoderFlow                          IBM i
─────────────────────        ─────────                          ─────
dev  ──► task ──► review + approve (Push to branch) ──► push
  │           (per-task temp build library, codermake)
  │                                          SCM-poll / webhook automation
  │                                             └─► "dev" profile (codermake) ──► DEVLIB (shared dev/test)
  ▼  merge / cherry-pick to promote
main ─────────────────────────────────► automation ──► "production" profile (codermake) ──► PRODLIB

Developers integrate continuously on dev; promotion to production is a single deliberate step from dev to main.

Branch and library model

Branch	Role	Built into
dev	Shared integration line; everyone approves their work here	DEVLIB (shared development/test library)
main	Production	PRODLIB

Libraries:

Library	Role
<task-lib>	Temporary per-task build library during authoring (created and dropped per task)
DEVLIB	Shared development/test library, rebuilt from dev
PRODLIB	Production, rebuilt from main

The development loop

1. Create a task based on dev.
2. The agent edits source and runs codermake to compile into the task's temporary library. Review with changed-file diffs, 5250 / Rich Display sessions, and an optional AI judge.
3. Approve and choose Push to branch — no new branch, no pull request. The commit lands on dev.
4. The dev automation runs the dev deployment profile, and codermake rebuilds the changed objects into DEVLIB. Test there.

CoderFlow task approval is the only review gate, so push finished work: every approval onto dev rebuilds DEVLIB.

Promotion to production

When a change is good in DEVLIB, promote dev → main by merging or cherry-picking the commits onto main — a lead pushing directly, or a short CoderFlow task based on main that performs the merge. The main automation then runs the production deployment profile and codermake rebuilds production into PRODLIB.

If main is branch-protected on your Git host, this is the one place you might keep a pull request, or grant CoderFlow's push identity an exception. It is also the natural seam to grow into a heavier pattern later: insert a qa branch and pull requests for a real QA/UAT stage.

Database file (DDS) changes

codermake creates new physical and logical files but does not modify a PF or LF that already exists in the target library. A change to an existing file needs a developer- or DBA-supplied migration step — typically a CL that uses CHGPF, or recreates the file and preserves data with CPYF — run as part of (or before) the build, in both DEVLIB and PRODLIB. See the fuller explanation under CoderFlow-native build pipeline.

Setup and invariants

To stand this up:

• One CoderFlow environment for the application repository, with an IBM i connection.
• Rules.mk build rules generated from existing objects (see Generate IBM i Build Rules) and committed to the repo.
• Two deployment profiles — dev (targets DEVLIB) and production (targets PRODLIB) — in the setup repo.
• Two automations — one watching dev, one watching main — each linked to the matching 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
dev builds the shared test library, main builds production	Each branch maps to one set of target libraries
Push finished work to dev	Every approval rebuilds DEVLIB; there is no pull-request buffer
Existing-file DDS changes have a migration step	codermake will not alter an existing PF/LF