Git workflows for mainframe source

From library members to repository files

In a classic setup the truth lives in PDS libraries managed by a tool such as Endevor or ChangeMan. In a Git setup the truth lives in a repository and the libraries are built from it. The DevOps and CI/CD course (CI/CD) covers the pipeline itself; here we focus on the developer's side of the move.

Member names are at most eight characters and uppercase, which fits Git fine. The tricky parts are sequence numbers in columns 73 to 80, which change on every renumber and create noisy diffs, and trailing blanks, which some tools strip and others keep. Decide once, document it, and let the migration tool apply it consistently.

Code pages, again

Files in Git on a workstation are normally UTF-8. When files are checked out on z/OS with Git for z/OS, or uploaded through Zowe, they must become the right EBCDIC code page. .gitattributes declares which files are text and which encoding they use on z/OS, as shown in the DevOps course. Characters such as square brackets, the not sign, the vertical bar and currency symbols sit in different positions in different EBCDIC code pages, so a wrong code page often shows up as a broken COBOL or JCL statement rather than obvious garbage.

A simple branch and pull request flow

A pull request (GitHub, Bitbucket) or merge request (GitLab) is a request to merge your branch. Reviewers see the exact lines changed, the pipeline's build and test result, and any comments. It replaces the email or ticket where someone used to say 'please promote PAYCALC'.

1. Create a branch named after the ticket, for example feature/PAY-142-overtime.
2. Edit in VS Code. Use a personal build or a sandbox library so you do not overwrite a shared test load library.
3. Commit small, clear changes and push the branch.
4. Open a pull request; the pipeline compiles, links and runs tests.
5. Address review comments, then merge. Deployment to test, QA and production follows the team's pipeline and approvals.

Where shared libraries fit

Two developers changing the same program on separate branches is normal in Git. It only works if each one builds into their own libraries, for example USER1.PAY142.LOAD, rather than all compiling into one shared test library where the last compile wins. Tools such as DBB and vendor build tools help by working out which programs a copybook change affects.

How this fits CI/CD

Zowe is the glue in many pipelines: a build agent runs the Zowe CLI to upload source, submit compile and bind jobs, and check return codes. Other pipelines run Git and the build directly in USS with DBB. Either way, the developer experience is the same: work in a branch, push, read the pipeline result, merge.