I am in the process of trying to architect a new, first-time Endevor implementation for my company as a replacement for Panvalet. As part of the setup I'm trying to decide on the best way to set up the maps. Our business units operate as completely separate entities with their own jobs/applications/systems and have always been completely separate in everything they do. With this implementation I would like to create a more shared environment with the Development(second) and Production(third) Environments being shared among all the units.
My question is around the best setup for the Test(first) environment. Specifically, what is the advantage to using a converging route with separate test environments for each business unit as opposed to a single, shared test environment? Is there a performance benefit one way or the other? The Admin manual has a whole 6 pages where they describe what the options for mapping are, but nothing about why you would use one way or the other. With our separate business unit setup I could see using the converging route method to replicate more of what we have now. However, since I can still differentiate the system and subsystem within a shared environment I am struggling with why I would add that level of complexity. Are there space constraints on the number of elements in an environment that would make a difference one way or the other? Literally the only other thing I can think of that would be different with a converging route is that I would have 3 levels of naming - environment, system, and subsystem as opposed to only the system and subsystem in a standalone route being shared across units. Am I missing something? Does anyone have any suggestions? I glanced through all the existing doc on this community and didn't see anything around this topic, so if I missed something please just point me at it. Thank you!
Hi Meghan, I recommend that you establish your software lifecycle independent of Endevor. Design your software lifecycle so it meets your internal customer's requirements. After all agree on the software lifecycle, Endevor should fit nicely over the software lifecycle you designed. This is a great topic for more discussion. Please let me know if you'd like to discuss via webex. I can get a few CA Mainframe DevOps community members to participate in the discussion. Regards, Phil
consider parallel development requirements.
maybe you business units could have a system each and then multiple subsystems for development expansion.
take a look at the Endevor sand box deployment too as CA are building capability around that.
John Dueckman has a great blog called in-approval that is worth searching out
If you or anyone else is looking for the blog site, it's at "in-approval" – A Blog about CA Endevor SCM by John Dueckman, www.johndconsulting.com
If each business unit's Elements are, and always be, distinct from the Elements maintained by all other business units, then you will not have parallel migration path merging of different versions of the same Element synchronization issues. In that case there is little downside to starting with separate stages for each business unit that later converge, and it makes sense to keep them separate initially if there is also no need to test interactions of applications from different business units until later in the life-cycle. BTW, I think your life-cycle sequence as you characterized it is uncommon, it is probably more common for the life-cycle sequence to be described as development, test, and production.