Git to Code Pipeline synchronization

To demonstrate Git to Code Pipeline Integration, we have created a Git repository connected to Code Pipeline that shows some of theadvantages moving to this combination may bring to a development team:

• Storing mainframe code and distributed code for the same application in the same location
• Storing Total Test assets in the same location as the mainframe code

While the former two address the problem of keeping code for different platforms or tests and code "in synch", the last point is more a question of "esthetics". The folder structure in use is more resembling a structure developers may be used from coding Java applications and therefore may not be as "alienating" to these developers than the rather flat structure provided by the "default".

Repository and folder structure recommendations

When synchronizing Git with Code Pipeline, BMC recommends adopting a structured repository layout rather than relying on the flat container view of Code Pipeline.  This approach is more conducive to Git Native development and will work better in a Git repository.

Example folder structure:

(root)

  +- Sources                           Mainframe Source Code

  |   +- COB                            Sources of Code Pipeline type, e.g. COB for COBOL

  |       +- sourceFile1.cbl        Extension, indicating the local type (refer to Type mapping to Code Pipeline below)

  |       +- sourceFile2.cbl

  |       ...

  |   +- CPY                              Sources of Code Pipeline type, e.g. CPY for COBOL copybooks

  |       +- sourceFile1.cpy        Extension, indicating the local type (refer to Type mapping to Code Pipeline below)

  |       +- sourceFile2.cpy

  |       ...

  |   ...

  +- .project

  +- ispwconfig.yml

  +- Git_To_Ispw.Jenkinsfile      Jenkinsfile

Branching model and Code Pipeline lifecycle

In addition to repository structure, defining a branching model that aligns with the Code Pipeline lifecycle is essential. This ensures that work done in Git branches flows seamlessly into Code Pipeline levels for development, testing, bug fixing, and production release.

Depending on the requirements of a given development team you may decide to:

• Setup a fixed amount of parallel paths within Code Pipeline that the different Git branches map onto
  
• Setup one “main” and one “emergency” path and use Code Pipeline “sandboxes” to dynamically create code paths in Code Pipeline onto which you map corresponding Git branches
  

Git branching strategy

BMC does not recommend any specific branching model. Nevertheless, in a typical situation you will come across one or more of the following types of branches:

• Long-lived branches (like development, integration, main).
• Short-lived branches
  • feature branches (feature/…) for the duration of implementing a new feature
  • bugfix branches (bugfix/…) for the duration of fixing a production issue
  • Release branches (release/…) for the duration of releasing larger sets of changes into production

Each branch type maps directly to a Code Pipeline lifecycle level through branch mapping rules defined in the configuration.

Branch to lifecycle mapping

Branch mapping rules may consist of the following (depending on needs and requirements, actual implementations may differ):

• Feature branches (feature/<branch_name>)
  • Used for implementing user stories and new functionality
  • Should be mapped the first HOLD levels in the Code Pipeline lifecycle
  • Example: feature/FT1/payment-api -> Code Pipeline level FT1.
• Bugfix branches (bugfix/<branch_name>)
  • Used for corrective changes and patches.
  • Should be mapped to the first HOLD level of a hotfix path in Code Pipeline.
  • Example: bugfix/incorrect-tax-calc -> Code Pipeline level HFIX.
• Development branch (development)
  • Long-lived branch for ongoing development.
  • Feature branches are branched from and merged into development.
  • Should map to a HOLD level higher up in the life cycle of Code Pipeline
  • Example: development -> Code Pipeline level DEVL.
• Release branch (release/<branch_name>)
  • Represents production-ready code.
  • Branching a release branch of development prepares the application for release.
  • Maps to the pre-production HOLD level in Code Pipeline lifecycle.
  • Example: release/v23.05.07 -> Code Pipeline level RLSE.

Production and Other lifecycle levels

• Production (PROD)
  • Represents live production code in Code Pipeline.
  • After a promote from pre production into production (PROD) the code from the release branch gets merged into the main branch.
• Lowest levels (UT<n>, BUG1, etc)
  • These do not directly map to Git branches.
  • They are managed locally via the Git Integration with Code Pipeline in either the Eclipse or the VSCode IDE.
  • Target lifecycle levels (for load, generate, build) are set when connecting the local project to Code Pipeline and can be adjusted in project properties.

With this branching model, customers can ensure a consistent mapping between Git development practices and Code Pipeline lifecycle controls, reducing conflicts and enabling seamless CI/CD across mainframe and distributed teams.

Branch Mapping to Code Pipeline

Mapping Git branches onto Code Pipeline levels happens in two different ways depending on the stage of the development process.

• During “local” development within Eclipse/VSCode, the target level is being controlled by the project’s properties.
  
• During pipeline execution to synchronize pushes/merges in to the central Git repository with higher levels of the Code Pipeline life cycle, the target level is set via the parameters of the synchronization CLI.

Type mapping to Code Pipeline

To connect Git folders and files to Code Pipeline, define mappings in an ispwconfig.yml file. This file ensures the correct relationship between Git paths and file types, and Code Pipeline component types.

Example