Using GIT with CA Endevor SCM – An Administrator’s Perspective
Here are some FAQs on using GIT with CA Endevor SCM
I previously wrote about a new offering we are building that allows developers to develop with an Enterprise GIT repository, linked to an inventory location in CA Endevor SCM. With this new capability, developers get all the benefits of using GIT that has made it an almost standard for open systems development. At the same time, they can leverage the build and deployment automation that organizations have invested in Endevor over the years.
If you are a CA Endevor SCM Administrator, I’m sure you have questions about how all this works. Here are some of the most common questions we’ve encountered.
How does the plugin sync changes between CA Endevor SCM and GIT?
Essentially, the plugin will allow the creation of a repository branch in the Enterprise GIT implementation that is linked to a SYSTEM/SUBSYSTEM in CA Endevor SCM. As changes are pushed from individual GIT clones back to the repository branch, they will be sent to a designated entry stage in Endevor. Likewise, Endevor will be monitored for changes being made through other channels and those will be brought back to the Enterprise GIT repository.
How do you reconcile changes being made directly in CA Endevor SCM with those being made in GIT, won’t you get conflicts and sync problems?
Developers who wish to use the ISPF or Eclipse interface can continue to do so. By using creating a SUBSYSTEM that is wholly “owned” by the GIT plugin, we create a work area where we isolate incoming changes from GIT. Work being done directly in Endevor is merged with the incoming GIT changes just as developers doing parallel development today in Endevor do now. They would copy to the “trunk” SUBSYSTEM at some point in the map and merge their changes manually or with PDM. Endevor will alert of sync errors. Alternately, an application team might simply decide to have everyone use GIT, in which case, there will be no need to isolate development between mainframe and GIT.
CA Endevor SCM utilizes a map and concatenation – if you sync from an entry stage, aren’t you only using a subset of the application code?
When we populate the repository, we will give the option to search up the map for code (it would be the same as using the “Search Map” and “Use First Found” options in Quick Edit). This way, you can build a full copy of the application code in GIT. For some shops, there might be thousands and thousands of files and they may prefer to simply keep a copy of the entry stage code and RETRIEVE into the entry stage when needed. Our intent is to add that as a plugin function to keep them from having to do that directly in Endevor.
If I make changes to production through an alternate entry stage (an emergency path to production for example) or if changes are being merged higher in the lifecycle, how will those changes get back to GIT?
Endevor will be monitored for changes being made through other channels. If the repository is using the option to search up the map and a change is introduced into production via a patch process, it will be copied down to GIT and put on the main trunk. If active development was being done in GIT, the conflict will be detected during the GIT pull request and the code will need to be merged with the emergency fix and then it will be added back to Endevor in the regular entry stage. If the search up the map option is not in use, then the change will not be visible until it “copied back” to the entry stage. If it never gets copied back the merge would happen in Endevor higher in the lifecycle (just as it would have had all the development been happening directly in Endevor).
How is parallel development supported?
Parallel development can be supported in several different ways in CA Endevor SCM. Some organizations leverage parallel maps with a merge point at some point higher in the lifecycle. In this case, each parallel stream will have a different entry stage. Each of these in turn can point to a different repository in GIT. Other organizations use the SYSTEM / SUBSYSTEM to denote parallel streams and move code between them to perform merges. Again, since a repository in GIT is associated with a given Endevor SYSTEM / SUBSYSTEM, multiple GIT repositories can be set up for each of the parallel streams.
CA Endevor SCM has lifecycle functions as well – packaging and code promotion for example. How does this map to GIT?
The Enterprise GIT plugin will only allow developers to check in and check out at an entry stage. To perform lifecycle functions, they would use CA Endevor SCM directly. In other words, GIT functions as an additional channel for SCM functions only. Despite that though, many of the developers who would want to use GIT for mainframe development probably also want to avoid 3270 interfaces like ISPF. For those developers, we have a project called Brightside that will provide a command line interface (CLI) for various mainframe sub-system operations, including Endevor lifecycle functions. With Brightside on their laptop, or with lifecycle operations scripted in CI tools like Jenkins via the CLI, they will be able to perform packaging and code promotion without having to use the “green screen”.
Here is a picture of what this all looks like:
As always, we are interested in your feedback. If you are interested in signing up for the beta or have questions or comments, please reach out to me at Vaughn.Marshall@ca.com or sign up directly for the CA Endevor SCM validation project on http://validate.ca.com.