Introducing Team Build
IDC concludes that organizations that modernize their mainframe software and processes have much better outcomes than those that choose to leave the platform altogether¹. This data includes adopting modern practices such as DevOps and Agile for maintaining mainframe application code. However, while the outcomes of modernization vs re-platforming are clear, determining the best way to modernize is not. Should an organization migrate to open source tools that their distributed counterparts use? Should they consider migrating all their code to a modern VCS like Git, or are there ways to modernize processes in-place and use new tools without such costly lift and shift migrations? To give our clients optimum flexibility when making these decisions, we’ve introduced a new tool: Team Build.
Endevor Team Build lets developers create a build project based on existing Endevor build automation, but which runs outside the traditional Endevor infrastructure. All that’s needed is a lightweight engine that can be deployed to any LPAR, including virtual LPARs, without the need for system programmer assistance. This is significant because there are situations where modernization-in-place doesn’t fit so flexibility to address all scenarios is key. Endevor Team Build, in conjunction with tools like Bridge for Git and Zowe CLI, gives Endevor that flexibility.
Let’s have a look at the different approaches and where each might fit.
Endevor Bridge for Git and Zowe CLI allow modern DevOps tools to be used as interfaces to underlying traditional Endevor repositories. This means the years of investment in automation such as complex build processes continues to deliver value uninterrupted. In fact, you can add new automation right on top of the old to take advantage of modern practices like static application analysis. There are other concrete advantages — because it’s only adding a new interface to existing technology, the risk and cost of changing tools is avoided. For monoliths that would be difficult to unwind or which have poorly defined application boundaries, even if there are hundreds of thousands of files — have only the working set of files made available to Git while the other build dependencies come from within the traditional repo. Most importantly, organizations don’t need to mandate any particular way of working. Are you a traditional developer who would much prefer to use ISPF and 3270 interfaces? No problem — work the way you always have. The tools allow collaboration with next generation developers and those who prefer to use tools like Git without forcing traditional developers to change the way they work.
So there are clear pros to modernizing in-place, but is that always going to be the right choice? The answer is not always cut and dried. What should developers do if they want to build on virtual LPARs? Tools like zD&T let developers access their own virtualized mainframes running on x86 hosts to build and test their code. Use cases featuring browser-based IDEs paired with virtualized workspaces are becoming more common, including options for virtualized z/OS workspaces. Many of the enterprise Git providers are now hosting a browser based IDE that can be launched to work on your code branch. So while building on zD&T may not be common right now, this is definitely something we will see more of in the near future. Does that mean that the full Endevor application, along with all its infrastructure, application code and dependencies, needs to be installed on the virtual LPAR to do builds? In this instance, it clearly doesn’t make sense.
What about other developer-centric use cases? Sometimes developers want to have more control over their builds, to change compiler options on demand as an example. While that can be accommodated in a traditional Endevor setup, it involves work and maintenance by the Endevor administrator. Bridge for Git also has a couple of limitations. In particular, there are lifecycle considerations that need to be observed to set it up for developer builds of their working directories. In some cases, organizations may not wish to make the necessary changes but with the introduction of Endevor Team Build, these use cases are covered as well.
Modernization decisions can be made on an application-by-application basis. One size does NOT need to fit all! Some applications are rarely if ever updated. Why invest any effort in modernization? Probably not much ROI there and you can continue to use traditional methods. Application monoliths or a team with a mix of developers who want to use traditional interfaces vs Git? If so, no problem — leverage Bridge for Git. Or, if there’s a need to build on zD&T or to perform developer builds using Bridge for Git without lifecycle constraints, Endevor Team Build is there to help.
Hybrid use cases are also supported. If there are application dependencies maintained by teams using Endevor in traditional ways, Bridge for Git can be used to feed those dependencies to Team Build projects. Teams can also choose to use Team Build for Git-native collaboration until the code is ready to go to production. By merging on to designated branches, Bridge for Git can feed Endevor for the “production” build which is especially relevant if your change control processes are heavily tied to Endevor automation.
In the end, the answer to the question “Which is the best way to modernize?” is that it is up to the teams to decide. There is no one clear direction to take — it depends on the makeup of the application team and their specific requirements. That’s why our tools need to support a wide array of options. I’ve always liked to compare Endevor to a toolbox — sometimes you need a screwdriver to build your solution and other times you’ll need a hammer (and more often than not you need both!). With the introduction of Endevor Team Build, you now have one more tool in the most comprehensive toolbox on the market.
To see Team Build in action, watch this GitHub for Mainframe Demo.
If you have any questions or feedback or would like to talk about any of your Endevor use cases, please feel free to contact me at Vaughn.Marshall@broadcom.com.
