Git Branching:
Moving to recommended model

Theory, practice and demo

Ian J Mitchell

Dennis Behm

(Mathieu Dalbin)

Agenda

Setting the context
- Aims and Assumptions
Fundamentals of the branching strategy
- Supported workflows
The pipelines in action - demo time!

Setting the context

Devops is foundational to modernization.
Modernization of Devops is no longer a voyage of exploration.
- (But plenty people will still try to convince you otherwise!)
No single tool or approach covers the entire journey to the destination.

We have a Guide… yes, it would be better if it were a map!

The Guide

Sneak-peek - new Guide landing page

Today’s topic - Branching Strategy for Mainframe Teams

… don’t just take our word for it

Microsoft Azure Devops Services

Lifecycle and terminology comparison

Code storage and developer experience

Developer Experience	Old	New
Source Code Storage	PDS Members	UNIX/Linux Filesystem
Editing	ISPF	IDEs: IDZ, VSCode
Versioning	Package IDs	Git branches/commits

Processes and Automation:

Process	Old	New
Building	JCL	Automated Pipeline scripts
Approval	Proprietary	Pull Requests
Deployment	JCL	IBM Wazi Deploy, IBM Urban Code Deploy

Aims and Assumptions

Some aims and assumptions that guide our recommendations…

No baggage

Well… travel light perhaps!

Are we prescriptive or just opinionated?
- Aim to be git-native!
We start with a recommendation
- Confidently
We question everything
- YAGNI - “you aren’t gonna need it”
We strive for simplicity
- For each user’s experience

Scaling

The workflow and branching scheme should both scale up and scale down.
- Small teams with simple and infrequent changes will be able to easily understand, adopt, and have a good experience.
- Large, busy teams with many concurrent activities will be able to plan, track, and execute with maximum agility using the same fundamental principles.

Planning

Planning and design activities as well as code development aim to align to a regular release cadence.
The cadence of the next planned release is defined by the application team.
Planning assumptions should aim as much as possible to complete changes quickly, ideally within one release cycle.
- DevOps/Agile practices to break down larger changes into sets of smaller, incremental deliverables that can each be completed within an iteration.

The Branching Strategy

Starting Simple

Every change starts in a branch.

---
config:
  fontFamily: "IBM Plex Sans"
  gitGraph:
    showCommitLabel: false
---
gitGraph
  commit
  commit
  branch feature/001
  commit

Developers work in the branch to make changes, perform user builds and unit tests.
A branch holds multiple commits (changes to multiple files).

Starting Simple

Every change starts in a branch.

---
config:
  fontFamily: "IBM Plex Sans"
  gitGraph:
    showCommitLabel: false
---
gitGraph
  commit
  commit
  branch feature/001
  commit
  commit

These changes on these branches are

built,
tested,
reviewed and
approved before merging to main.

Preparing to Merge into `main`

Feature Team/Developers will:

Build
- Builds may be done to any commit on any branch
- Feature branch must build cleanly for a Pull Request
Test
- To prove quality of the changes in their feature branch

---
config:
  fontFamily: "IBM Plex Sans"
  gitGraph:
    showCommitLabel: false
---
gitGraph
  commit
  commit
  branch feature/001
  commit
  commit
  checkout main
  merge feature/001

Merging into `main`

Create a Pull Request (PR) to signal to Team Leaders/Release Controllers to:

Review
- Code and Test results
Approve
- Safeguard the quality of main

---
config:
  fontFamily: "IBM Plex Sans"
  gitGraph:
    showCommitLabel: false
---
gitGraph
  commit
  commit
  branch feature/001
  commit
  commit
  checkout main
  merge feature/001

main and other long-lived branches are protected (not everyone can push or merge to them).

Before you ask… no, there is no Production branch

CI/CD decouples the building and deploying to test environments and production.

We have no branches named prod (or test or QA)

Those are environments to which builds can be deployed
Such extra branches:
- are unnecessary
- cause ambiguity
- impose merging and building overheads
Deployment manager is maintaining what is deployed where and provides traceability from developer to production deployment

Testing a release candidate

Any point in the history of main can be declared a release candidate.

Build a release candidate package
Deploy it
Test it

---
config:
  fontFamily: "IBM Plex Sans"
  gitGraph:
    mainBranchOrder: 2
    showCommitLabel: false
---
gitGraph
  commit
  commit
  branch feature/001 order: 3
  commit
  commit
  checkout main
  merge feature/001
  commit tag: "RC1"
  branch maintenance/release1.1
  commit tag: "Build, deploy, test"

Tag the commit (point in main’s history) with a release name.

Deploying to production

When…

all the committed work items for the next planned release are ready to be shipped, and
all quality gates have passed successfully and the required approvals have been issued by the appropriate reviewers,

the release package can be deployed to production…

Deploying to production

---
config:
  fontFamily: "IBM Plex Sans"
  gitGraph:
    mainBranchOrder: 4
    showCommitLabel: false
---
gitGraph
  commit
  commit
  branch feature/001 order: 4
  commit
  commit
  checkout main
  merge feature/001
  commit tag: "RC1"
  branch maintenance/release2.2-RC1 order: 3
  commit tag: "Build, deploy, test"
  checkout main
  branch feature/002 order: 4
  commit
  checkout main
  merge feature/002
  commit tag: "RC2"
  branch maintenance/release2.2.0-RC2 order: 2
  commit tag: "Build, deploy, test"
  checkout main
  commit tag: "Rel2.2"
  branch maintenance/release2.2.0 order: 1
  commit tag: "Build, deploy, test, release"

Release maintenance branches

A release maintenance branch will be used if hot-fixes must be developed and delivered.

---
config:
  fontFamily: "IBM Plex Sans"
  gitGraph:
    mainBranchOrder: 2
    showCommitLabel: false
---
gitGraph
  commit
  commit tag: "rel2.1.0"
  branch maintenance/rel2.1.x order: 1
  commit
  checkout main
  commit
  branch feature/001 order: 2
  commit
  checkout main
  commit
  branch feature/002 order: 1
  commit
  checkout main
  merge feature/001
  checkout maintenance/rel2.1.x
  branch hotfix/001 order: 0
  commit
  checkout maintenance/rel2.1.x
  merge hotfix/001
  commit tag: "rel2.1.1"
  checkout main
  merge feature/002

Scaling up

Concurrent feature branches scale very well, but assume short cycle times.

Ideally live within a release delivery cycle
But no big deal if they don’t

Epic branches can collect multiple features

Before going to main
When the delivery is planned beyond the next release

(Epic branches are a form of integration branch.)

Integration branches

---
config:
  fontFamily: "IBM Plex Sans"
  gitGraph:
    mainBranchOrder: 2
    showCommitLabel: false
---
gitGraph
  commit
  checkout main
  commit
  branch epic/proj001/001 order: 3
  commit
  branch feature/proj001/004 order: 4
  commit
  checkout epic/proj001/001
  branch feature/proj001/005 order: 5
  commit
  checkout feature/proj001/004
  commit
  checkout main
  commit
  branch feature/001 order: 2
  commit
  checkout main
  branch feature/002 order: 1
  commit
  checkout epic/proj001/001
  merge feature/proj001/004
  checkout main
  merge feature/001
  checkout epic/proj001/001
  merge feature/proj001/005
  checkout feature/002
  commit
  checkout main
  merge feature/002
  branch feature/003 order: 2
  commit
  checkout main
  merge feature/003
  commit tag: "rel2.2.0"
  checkout epic/proj001/001
  commit tag: "continue-epic"

Convention over configuration

The principles are more important that the tools and names.

Naming conventions - making purpose obvious:

main : single source of truth. The only long-living branch.
release/rel-2.0.1 : explicit versioning numbering to identify releases maintenance branch.
epic/47-ai-fraud-detection : development initiative identified by epic id and description.

Convention over configuration

Changes are implemented on feature branches:

feature/<jira-id|servicenow-id>-new-mortgage-calculation : references to other planning tools for new features for the next planned release.
feature/47-ai-fraud-detection/refactor-mortgage-calculation: feature implemented for development initiative
hotfix/rel-2.0.1/fix-mortgage-calc: fix implemented for release rel-2.0.1

Names of branches and tags flow through to builds and deployments.

Workflows supported by the strategy

How do teams work with and benefit from the branch strategy?

The types of workflows

Work and focus on the next planned release via the main branch. After planning the work items for the next release, the development team is adding changes to the main branch.
Resolution of a production problem in the currently-released version of the application by leveraging a release maintenance branch that is used for maintenance purposes,
concurrent development activities for significant development initiatives, which include multiple planned work items for a later delivery (including starting development of a future release) by creating an epic branch from a commit point in the history of main.

The following narratives complement the structure.

Features for the next planned release

Developer activities:

Take item from backlog
Create feature branch
Code locally
Build with DBB User Build
Commit into feature branch, build and test feature functionality
Create Pull Request for review and approval

Features for the next planned release

Release control activities:

Merge approved branches to main and build
When planned features have merged, build and tag Release Candidate package
Deploy Release Candidate to test environments
(Release candidate can be superceded)
Finalise Release package in Artifactory (or equivalent)
Tag commit from step 8 as the production release and deploy

Simplifying pipeline implementations

Plan your Pipeline Architecture

Different pipelines orchestrators are used by customers
Principle implementations need to safeguard discussed principles and rules

Common needs across all implementations

Computation of a unique build high-level qualifier
Set build configuration depending on the lifecycle the user is in
- Compile with test options
- Compile with optimize options
Enforcing a common strategy to store packages in your enterprise binary repository

Pipeline templates and common backend services

Pipeline templates for the various pipeline orchestrators + common set of services that implement the recommended workflow.

Collateral

References

zDevOps adoption enablement website - Git branching for mainframe development
A no-baggage approach to new Mainframe development practices
Pipeline templates - IBM DBB Community Repository
Videos
- Using the branching model (4 short videos)
- Day in the life of a mainframe developer using Git

Check out this presentation in Github!

THANK YOU!

Submit your feedback at:

https://conferences.gse.org.uk/2025V/feedback/AG

(Make sure you are signed into MyGSE)

Git Branching: Moving to recommended model

Agenda

Setting the context

The Guide

Sneak-peek - new Guide landing page

Today’s topic - Branching Strategy for Mainframe Teams

… don’t just take our word for it

Lifecycle and terminology comparison

Code storage and developer experience

Processes and Automation:

Aims and Assumptions

No baggage

Scaling

Planning

The Branching Strategy

Starting Simple

Starting Simple

Preparing to Merge into main

Merging into main

Before you ask… no, there is no Production branch

Testing a release candidate

Deploying to production

Deploying to production

Release maintenance branches

Scaling up

Integration branches

Convention over configuration

Convention over configuration

Workflows supported by the strategy

The types of workflows

Features for the next planned release

Features for the next planned release

Simplifying pipeline implementations

Plan your Pipeline Architecture

Common needs across all implementations

Pipeline templates and common backend services

Collateral

References

THANK YOU!

Git Branching:
Moving to recommended model

Preparing to Merge into `main`

Merging into `main`