Source code management

A source code management (SCM) tool manages and stores different versions of your application configuration such as source code files, application-specific configuration data, test cases, and more. It provides capabilities to isolate different development activities and enables parallel development.

In our described continuous integration/continuous delivery (CI/CD) implementation, we showcase Git as the SCM when applying DevOps to IBM Z®. Our Git basics documentation covers the essential concepts and vocabulary for understanding and working with Git.

Why move to Git?

Git is the de facto industry standard SCM for the open source community and is growing in popularity among major organizations. It is a central part of the modern developer’s toolkit, and provides a common SCM tool for hybrid application architectures that can span across components ranging from those implemented in traditional mainframe languages such as COBOL, PL/I, or Assembler, to components for the service layer such as z/OS® Connect, and components in Java™ and Go, to reflect the architecture of the business application.

Git integrates with most modern DevOps tools and pipeline processes to support the full development lifecycle from continuous integration (CI) to continuous delivery (CD). By migrating to Git as the enterprise SCM, mainframe application development teams can then take advantage of the open source community's modern tooling.

Use a Git-based service

Choosing Git as the foundational tool presents some choices - Git's flexibility to be used in many different ways is a major reason why it is so widely adopted.

• Using just Git by itself allows developers on a shared system to collaborate at a very basic level using their own copies of the source code. This can work well for very small and informal projects and a few contributing developers (like Alice and Bob in the tutorial).
• Using Git and a patch-based workflow extends the collaboration to developers spread across different locations. This relies on a high level of trust and out-of-band communication between the contributors, as well as a strong leadership and governance process. It is how the Linux kernel continues to be maintained under the leadership of Git's inventor, Linus Torvalds.
• Git-based service providers such as GitHub, GitLab, and Azure DevOps include most of the additional capabilities enterprises need (for example, security, review processes, and governance) and are the most familiar to the overwhelming majority of developers today.

This guide is based on the use of a Git-based service provider. We strongly advise against choosing the "just Git" or "patch-based" styles of collaboration for mainframe teams. It may seem that these options could provide an entirely "z/OS-resident" solution, but they do not support the typical full set of needs for mainframe teams and development lifecycles, and they still demand adoption of and proficiency in additional z/OS facilities such as UNIX System Services.

Common Git provider options

• GitLab
• GitHub
• Atlassian Bitbucket
• Azure Repos

Best practices

Sharing code

It is a common practice that mainframe applications share common code. For example, COBOL copybooks are typically shared across applications that process similar data.

The following diagram illustrates how teams can define repos to securely share common code. In this example, App Team 1 has common code that App Team 2 can clone and use in their build.

Another example (also illustrated in the following diagram) is that an enterprise-wide team can maintain source that is common across many applications.

Branching conventions

• Follow the IBM-recommended Git branching model for mainframe development, which provides guidance on branch naming conventions, branch management, and Git workflows to support various steps in the software development lifecycle.
• Define and communicate the Git workflow being used by the team/organization.
• Commit related changes. A commit should be a wrapper for related changes.
• Write good (descriptive, concise) commit messages.
• Work with small incremental changes that can be merged, tested, and deployed in short sprint cycles.
• Communicate with peers when working on common code.
• After releasing a hotfix, merge it into the main branch for integration with ongoing work.
• Clean up short-living branches (such as features, hotfixes, and so on).