Endevor

We have parallel migration paths to production.  If a package cast fails due to an out of synchronization problem then the developers will add an OPTION SYNC to the failing move action and cast the package again.  Some developers add the OPTION SYNC to all of their move actions to bypass the failure and some developers also specify WITH HISTORY for all of their move actions.  An out of synchronization condition implies there is a risk of a unwanted code regression.  We want to require our developers to check for code regression whenever there is a out of synchronization condition before adding an OPTION SYNC to a move action.  Does anyone have suggestions regarding how to enforce such a policy and the contents of such instructions?

Version B+1 cannot be moved to production, where version B resides, without an OPTION SYNC.

Suggested instructions:  Reviewers will deny all packages containing MOVE actions with OPTION SYNC.  The developers will be expected to use PDM to eliminate the OPTION SYNC from the package move actions.  Version B will the base.  Version B+1 will be deriviaton 1.  Create a B+2 as deriviation 2 from version B to re-introduce the changes found in B+1.  When the results in PDM look good delete B+1 from ENDEVOR and replace it with B+2.

Any opinions on whether this procedure is a good idea or bad idea or could be improved?

If you really want to stop people using WITH SYNC then put an SCL override in Exit 2. E.g. we use this to force SIGNIN/NOSINGIN and HISTORY/NOHISTORY at different stages.

However this still won't stop users doing the wrong thing, not doing the required analysis and just doing 'whatever' to get rid on the SYNC error. Better education and holding users responsible for implementing incorrect versions to production (as well as better testing/reviews) will help as well as proper change control (essential with parallel environments) and review boards etc.

We agree that education followed by holding the developers responsible is the correct approach.  It will take time for us to write the course and for all of the developers to take the course (we have no control over whether or not their management pays for ENDEVOR training, so we will need to do this ourselves).  So we are considering blocking use of WITH SYNC until then.  I have reservations about our doing this but I am not the decision maker. A SYNC associated code regression resulted in a big kerfuffle (it appears that the developers incorrectly blamed ENDEVOR) and I think my management puts priority on avoiding repeating that kind of kerfuffle.  I did not participate in that discussion with the upset developers and I do not why it led to this conclusion.  I passed on your suggestion that we do this in EXIT 2.  Thank you.

Unfortunately Endevor always get the blame, right up to the point when I ask "Oh, you did your Final (or User Acceptance Testing etc.) in Stage 'x' before you implemented didn't you?", pointing out that proper testing should have identified the code regression. Stage 'x' being the stage were the paths/code merge.  

You might also want to point out that Endevor did the right thing and alerted the application team to the problem via the SYNC error. The fact that the application team did not react correctly is not Endevor's fault.

As to education, Change Control, Configuration Item  Control and Standard Testing practices are not Endevor training but should be part of every Application Team skill set. I was doing these over 20 years ago without Endevor, and while Endevor makes these a lot easier it should not remove responsibility from the Application Team. Perhaps you should suggest ITIL training etc.

You may also want to review who can perform OVERRIDE SIGNOUT and restrict this access as well.

It seems many groups want Parallel development, thinking it'll be easier, without understanding the risks and the costs involved. We get the occasional request for parallel environments but most requests are withdrawn after we carefully explain the risks, management and overheads and we make 'retrofitting' and re-testing of code a mandatory task of the Application Team. The few that still go ahead are the ones that really 'need ' (rather than 'want') parallel development and I can tell you they spent  many hours on analysis and retrofitting code (some use PDM and some don't) and that it's a significant part of their workload.

For some teams, we have introduced 6 stage environments and this seems to satisfy their need for multiple releases but keeps the release order in place (as well as SIGNIN/SIGNOUT processing).

Oh, and your site should have a "Configuration Management Plan" and Endevor should be configured to support that plan. If you have one then I suggest you become very familiar with it, as It should provide much needed ammunition. If you don't have one then you should ask for one to be provided.

Good luck.