Recommended Git Repository Structure for IBM i Source

Overview

It is important that the combination of each Git repository path and file type distinctly maps to an MDCMS Attribute. Configuring this completely ahead of time ensures that there is no extra effort by developers or AI agents when pushing changes to MDCMS. These recommendations are also to limit exceptions during initial attribute mapping for a Repository and for following general git practices.

Recommendations

Use One Git Repository per MD Application

For performance and scoping reasons, split your Git Repositories by MD Application.

Don't Put Source directly into the Root

Within the repository, have a folder directly under the root named source or src or something similar to that. The source folders/files will then be under the source parent folder. This is because with time you may have other items in the repository that aren't your IBM i source, such as AI skills or other artifacts.

Applications with Multiple Source Libraries

If the production level of your application contains multiple source libraries, have a folder under /source with the name of each library in UPPER-CASE.

Example:

• /source/PRDSRC1
• /source/PRDSRC2

Applications with a Single Source Library

If the production level of your application contains a single source library, it is optional to have a folder of the library name.

Folder per Source File

The next level in the folder hierarchy would be the source file.

Example with library folders:

• /source/PRDSRC1/QCLSRC
• /source/PRDSRC1/QRPGLESRC

Example without library folders:

• /source/QCLSRC
• /source/QRPGLESRC

Distinctions between Programs and Modules

If you keep source for programs and source for modules in the same source file, then create 2 folders under the source file folder. One for programs and one for modules and then move each source file to the appropriate subfolder.

Examples:

• /source/PRDSRC1/QRPGLESRC/programs/MYPGM.rpgle
• /source/PRDSRC1/QRPGLESRC/modules/MYMODULE.rpgle

This ensure that the attribute mapping knows which attribute to assign, based on the sub-folder, since the file types are identical.

Distinctions between SQL entities

Since SQL scripts should have the file type of .sql, it is not clear based on the file type what the entity type will be. For this reason, it is recommended to create a subfolder per entity type and them move the source to the appropriate subfolder.

Examples:

• /source/PRDSRC1/QSQLSRC/aliases/ABC.sql
• /source/PRDSRC1/QSQLSRC/tables/MY_LONG_NAMED_TABLE.sql

The following table shows the subfolder name that the Attribute Mapping configurator uses to automatically allocate the appropriate SQL attribute. You can use Singular folder names or plural folder names dependending on your personal preference:

SQL Entities with Long Names

MDCMS can handle using the short, system name on the source, but it is recommended to use the long name instead, where defined. This makes the file name easier to recognize by other developers and will then be used as the object name on the Object Request for better granularity and clarity for audit logs. If this would be too tedious initially, the files can be renamed during a later phase.

Clean Up the File Types on your Source Members before the Export

It is highly recommended to go through the list of members in each source file that will be exported to Git and ensure that the source type matches the contents of the source. It is common for older source that the type is missing or doesn't match (RPGLE when should be SQLRPGLE, for example).