Understanding Roles in Endevor Bridge for Git
Have you recently set up Endevor Bridge for Git to synchronize enterprise Git repositories with Endevor inventories? Are you wondering about how to bring teams on board, what roles to designate for certain tasks, and how to manage those roles? Or are you just curious about the latest news from Bridge for Git and some of the features of recently released version 2.11.0? Whatever the case, this blog is for you!
Roles and Responsibilities
There are three primary roles in Bridge for Git: Administrators, Mapping administrators, and Developers. Each role has a certain knowledge base and the authority to complete particular tasks. *Asterisks* denote the new capabilities the roles have that were introduced in the recent 2.11.0 release.
Administrators set up, configure, and manage the Bridge for Git server. They understand how Bridge for Git communicates with both Endevor and the enterprise Git server. Once they have Bridge for Git running, administrators are able to:
- Configure a sync-back schedule, the period for which Bridge for Git synchronizes changes from Endevor to git
- Configure an email server for notifications
- Create and manage Endevor Connections, which point to specific instances of Endevor Web Services that are used in the creation of mappings.
- Manage roles and privileges and upload mainframe users
- *View and manage activity of mappings in Bridge for Git*
- *Download and view logs*
- *Set up webhooks to send information about the Bridge for Git server or mapping events to the endpoint of their specification.*
Mapping Administrators are tasked chiefly with the creation of Git-Endevor mappings and working with their teams to ensure that workflows are managed properly. Once they create a mapping, they are able to:
- Manage ownership of the mapping and transfer to another mapping administrator if needed
- Add branches to the mapping using the Endevor Bridge for Git plug-in for Zowe CLI
- Commit a work areas file with information about build locations for developers
- *Specify CCID, Comment, and From-location values for element changes in a mapping*
- *Set a mapping-specific sync-back interval at which to pull in changes from Endevor*
- *Set up a webhook to send mapping event information to a specified endpoint*
Developers are those who will log in to Bridge for Git in order to clone repositories and work with the elements. Their primary responsibility is to manage their credentials for the Endevor Connection(s) that are used by their mappings.
Administrators and Mapping Administrators alike are able to provide and manage their credentials for Endevor Connections as well.
Managing Roles
When an Administrator configures the application.yml file for the Bridge for Git server, they need to specify users that will be administrators of the server. At the same time, they can specify a default role for those that log into Bridge for Git for the first time.
In previous versions of the application, those that logged in for the first time were by default Mapping Administrators. If you have upgraded to the newest version and configure the default role to be Developer, those that had previously logged into the application will retain their previous role. So there is flexibility here.
That all said, if you need to elevate the privileges of users, you can manage roles on the User Management page under Settings.
If a particular developer becomes a team lead and needs to be able to manage and create mappings, an Administrator can change their role to Mapping Administrator. Similarly, if you need to have more people managing the Bridge for Git server, you can also elevate particular users to Administrator. In the opposite way, an administrator can demote any of the roles.
One Additional Role
There is one other role that may be grayed out, which is MF Developer. For traceability purposes, administrators can add the information about their mainframe developers using the Upload mainframe users button. These are people in the team that will not work with Git-Endevor mappings, but instead only interact with elements directly on the mainframe. With their information loaded to Bridge for Git, developers working with mappings can see who has made changes to elements in mappings from the mainframe side.
If one of these mainframe developers ever does log in to Bridge for Git, their role on the users page will change to whatever default role the administrator set in the application.yml. They can then provide their credentials for the Endevor Connections that they will use and begin working with Git-Endevor mappings
A Word about Credentials
Users of Bridge for Git mappings need to ensure that they provide their credentials for the Endevor Connections that are used for their mappings. Their credentials are used to synchronize their changes to Endevor.
When a mapping administrator creates a mapping, their credentials are used for the read access to Endevor, to retrieve the elements to the repository. If you do not want mapping administrator credentials to be used in this case, you can provide a certificate for the Endevor Connection. Currently, certificate support is handled through the use of the Zowe API Mediation Layer. For more information, see https://docs.zowe.org/stable/extend/extend-apiml/onboard-overview
Summary
Hopefully you now have a better grasp of the roles and responsibilities in Bridge for Git. At the same time, I hope that in seeing the new capabilities released as part of version 2.11.0, you get an idea of how our team keeps the roles in close focus as we put out new features for Bridge for Git.
For more information about Bridge for Git in general, have a look at our updated whitepaper or at the documentation.
For a broader overview of the modern DevOps solutions that we provide, have a look at our Modernization Roadmap
Special thanks to Cosmin Terpez for his contributions to this blog.
