Mapping Strategies Using Endevor Bridge for Git
With the award-winning Endevor Bridge for Git, developers can work on their mainframe source code in Git with the assurance their changes are kept up to date in Endevor. Mappings synchronize Endevor inventory locations with enterprise Git repositories (for a full overview of the solution, see the whitepaper).
You may be thinking that there is some complexity involved, that those applications in Endevor are large, spread across different locations, have inconsistent naming conventions, and maybe even have a lot of old and long-untouched code. Several questions suddenly arise:
- What should I consider before creating a mapping?
- What kinds of mapping can I even create?
- What options do I have to limit the scope of a mapping, to ensure better performance and filter out what the team does not need?
Such questions are spot on and need to be addressed. This blog will answer these questions and help you get started creating mappings for your team. Let’s dive in!
Before Creating a Mapping
The goal in using Bridge for Git to create mappings is to provide your team with exactly what they need to complete their development tasks efficiently. As such, you need to consider the structure of the Endevor applications your team works on and their associated processes. In particular, consider the following:
- Do applications span multiple systems and subsystems?
- How many elements comprise a typical application?
- Are certain conventions used for element types and names?
- What is your lifecycle like? Can developers leverage multiple entry stages or parallel lifecycle paths?
Having this information about your Endevor inventory and applications provides a foundation upon which you can then consider the mapping options available in Bridge for Git.
Mapping Options
When you log into Bridge for Git as a mapping administrator and select the “Create new mapping” button, you have the following mapping options.
While the UI provides an overview for each, let’s break them down a bit more with more comprehensive diagrams and descriptions. Note that we will cover the first three types of mappings. The last option, Upload mapping definition, is for creating mappings using an existing JSON definition file.
Simple Mapping
A Simple Mapping synchronizes a Git repository to a single system and subsystem in Endevor, as distinguished by the blue arrows. The following diagram shows a basic mapping that points to the Dev entry stage and synchronizes all elements up the map. In the Git repository the elements are organized by element type in a flat structure under the specified system and subsystem:
We generally recommend that users start with a simple mapping to understand how the structure and synchronization of mappings work.
Basic Multi-branch Mapping
A Basic Multi-branch Mapping associates one Git repository to any number of Endevor systems and subsystems. Multiple synchronized branches can be created that correspond to different Endevor environments and stages.
In the example above, you can see how a team may create a branch upon which to complete normal development from the Dev environment while at the same time having a branch that points to the entry stage in Prod for situations where hotfixes can be applied.
Advanced Multi-branch Mapping
An Advanced Multi-branch Mapping associates one Git repository to any number of Endevor systems and subsystems. Multiple synchronized branches can be created that correspond to different Endevor environments, stages, systems, and subsystems.
Teams may find this mapping model especially helpful for managing regular development, fix, and reference branches within a single repository.
Synchronization Options
Applicable to all of the mapping types are the following synchronization options which affect the scope and behavior of the mapping:
- Read-only branch setting
- Synchronize all stages in the Endevor map
- Synchronize only elements from work environment
- Element Type and Element Name filters for the inventory
The read-only option applies to the branch level and dictates that the branch will only be synchronized from Endevor to Git. This can be especially helpful for creating reference points for developers so they can see what is at a higher stage in Endevor without making changes. Similarly such read-only branches can easily be used for code scanning purposes.
If you have reasonably-sized applications, under several thousand elements, for example, you can consider synchronizing all stages of the Endevor map to your mapping. However very often this is not the case and you will need to limit the scope further. This is where the work environment and filter options come into play.
Narrowing the Scope of a Mapping
While in some cases you may be able to define a mapping that points to an Endevor inventory and brings in elements from all stages of the Endevor map, chances are that the structure of your applications is more complex and you will not want to synchronize such a large number of elements for performance and accessibility reasons. So how can you effectively narrow the scope?
One configuration option that we highly recommend is synchronizing only elements from the work environment, or what we also call lazy initialization. This will pull the elements from the entry stage of the Endevor inventory location that you specify only. For developers, this is likely all they will need to complete the fix or feature work that is planned. Note that when it comes time to build, you can still build with Endevor and any dependent files will be included through concatenation, regardless of whether or not they are in git.
If a developer realizes that they need an element from up the map, we provide them with the functionality in both our Endevor Bridge for Git plug-in for Zowe CLI and our Visual Studio Code extension Bridge for Git Explorer.
Other synchronization options of great value are the Element type and Element name filters for mapping creation. Provided that an application has strict naming conventions or that a team only really works on a COBOL application, mapping administrators can effectively define a properly scoped mapping for their team by specifying such types and naming conventions (standard Endevor wildcards apply) during creation.
After Creating a Mapping
Now you should have enough information to create a mapping, identifying first the application in Endevor and its scope and then connecting it with a git repository. What about the next steps?
The main thing to think about next is the desired workflows of your developers. How will they build their code? What processes do they want around editing and synchronizing to Endevor? Do you want to integrate code scanning and tests?
We intend to cover these topics in upcoming blogs, so continue to follow this space and learn more about Bridge for Git, working with mappings, and continuing on this path of mainframe modernization.
If you have just set up Bridge for Git and are not ready to create mappings and wonder instead about roles, have a look at my previous blog, Understanding Roles in Endevor Bridge for Git.
