IBM i Workflow Patterns

A workflow pattern is a reference configuration for how CoderFlow fits into an IBM i shop's change-management and promotion process. Every pattern uses one Git repository as the source of truth, isolated per-task build libraries, codermake builds, and the same review-and-approve gate. What differs is how approved source reaches the QA and production libraries, and which system owns promotion.

Pick the pattern closest to your setup and adapt it. Branch and library names (main, qa, dev, DEVLIB, QALIB, PRODLIB) are generic placeholders — map them to your own.

Patterns

• Vendor change-management promotion — One long-lived branch (main = production) plus a feature branch per change. An existing change-management product stays authoritative for dev → QA → production; CoderFlow replaces the edit/compile/test loop and feeds the developer's dev library. Choose when you already run a change-management product and want to keep it authoritative.

• CoderFlow-native build pipeline — main (production) and qa (QA/UAT) plus feature branches. CoderFlow owns build and promotion: SCM-triggered automations run deployment profiles that rebuild the QA and production libraries with codermake on each branch merge. Choose when you want CoderFlow to own build and promotion with no external CI or change-management server.

• Minimal: dev + main — Two branches and no pull requests. Developers approve straight onto dev, which builds a shared development/test library; promoting to main builds production. Choose when you have no formal change-management or QA process and want the least ceremony.

Pull requests are optional in every pattern — each page shows both the with- and without-pull-request flows. This catalog will grow as more configurations are documented.