...

Benefits of this approach: testing is not interrupted, testers can continue testing, and developers can focus on fix.

In May 2012, a example of a situation where I recommend this approach for is R812. R812 has a minor defect, (D1031) caught in UAT. D1031 has a known root cause, with a fix unit-tested in DEV. I recommend we apply the D1031 fix to TEST, and if approved, that R812 and the D1031 fix launch on this release.

...

Step two is to create a new version of the broken feature in DEV, unit test for meeting the original functionality, and test that it does not reintroduce the defect, and then coordinate with testing team about appropriate time to introduce the feature fix update set to TEST. If this happens to PRE-PROD, the fix will always be the most recent code, so when the code fix is ready and approved by testers, it can be tacked on to the end of the release in PRE-PROD, no clone needed, and added to set of updates in the release.

This issue happened in December November 2013 or so. We had a Business Rule that broke other functionality in the system. We got TEST working by advancing a small Update Set that disabled the bad code so testing could continue while a fix was prepared. We fixed in DEV, promoted the revised non-broken feature to TEST, and released the requirement and fix on that release cycle.

...

In this situation, the most appropriate fix is to leave the code in the release, and apply just a small update set to disable the code. In the case of a Service Catalog Item, an Update Set that toggles the Catalog Item to inActive is sufficient. When we are ready, we can have a future release where we have a small Update Set that toggles the Catalog Item back to Active.This is my recommendation for R780. The code has no outstanding defects, and successfully passed UAT back in April. It was removed from the release because the stakeholder did not participate in the second round of UAT. This  This has two positive affects: we do have to alter the release notes, but the release itself still gets the code into PROD, and we don't worsen our completed code development backlog. We also don't have to take the perform duplicate work by yanking the code out of the system, only to put it right back in a later release.

We have done this with much of START Replacement. The code was fully UATed by stakeholders, it met formal requirements, and passed testing. It was determined that no START Replacement Catalog Items would be made available to end-users until Trainers develop training materials for the end-users, and there would be one Big Bang training session. When training materials are available we can have a release with small update sets that toggle the Catalog Items to Active.

...

1. Revise release notes to remove requirement.
2. Revise release plan to remove requirement and associated update sets
3. Go to DEV, and mark all associated update sets as Ignore
4. Go to PROD, go to 'Retrieved Update Sets', and delete all associated update sets. We don't want even the chance of accidentally deploying this code to PROD, but it may have gotten copied to PROD back when the update sets were set to Complete. Alternatively, it's also safe in PROD to delete all Retrieved Update Sets, and the next 'Retrieve Completed Update Sets' will not pull the associated update sets that were set to Ignore
5. If this code was already committed to PRE-PROD, we need to clone over PRE-PROD from PROD, and re-deploy the release according to the revised release plan. This is mainly because PRE-PROD is a test of our deployment plan, and we need to do the deployment the same in PRE-PROD and PROD.
6. If this code was already committed to TEST, there's a decision to make. A) If the code can safely be disabled in TEST, we can create one update set in DEV, advance it to TEST, commit it to TEST to disable the code, then set the update set as Ignore in DEV. This will allow other testing to continue in TEST, and TEST will be cloned over after the release, so it's safe to leave the disabled code for the next few days before the clone resets TEST. B) If the code cannot be safely disabled in TEST, TEST will need to be cloned over, and the release re-applied. This will cause disruption in TEST, and should only be performed if A is not possible.
7. Mark the requirement in HPALM with appropriate status, and include comments about why the code was completed and then abandoned.

R1147 is a requirement to resolve issues with customers adding comments to an RITM, and the fulfillment people performing the SCTASK never seeing those comments. The requirement is defect-free, and passed UAT twice. The original fix was envisioned as applying to just one particularly problematic set of customers, but Soren saw that it had benefits for the entire system. The team consensus seems to be that we want to remove this from the release and never apply this fix in the future. Because of this change to the release, and because of other changes to the release, I recommend cloning over PRE-PROD to remove R1147 from the release originally scheduled for April. R1147 can be safely disabled in TEST using the 6A method, and I recommend doing so.

What does this mean for the release originally scheduled for April

PRE-PROD: No matter what, we are not moving this release to PROD as originally planned in April. We will need to at the very least, clone over PRE-PROD, and re-apply the new release. However, the new release is not finalized yet. I don't think we should do the next release to PRE-PROD until we are code complete with any issues we may uncover with our more rigorous testing we have planned for TEST environment. I think we should leave PRE-PROD alone until we have finalized the release, even if that takes a few weeks.

TEST: I think we should try harder with the second UAT approval for R780. If we don't get it, I think we should leave R780 in the release, but apply an additional small update set to disable it until the time when we are comfortable releasing it. R780 cleared UAT once and has no defects. R812 has a minor defect, identified in the second UAT session. I think we should leave R812 in the release, apply the fix for R1031, and have the stakeholders verify the fix after it is blessed by our testers. For R1147, I personally feel we should postpone action until we discuss with Soren, who is the process owner for the Request module. The original scope was just to modify a single Catalog Item, and after explaining the Use Cases she suggested a more cohesive fix would be beneficial to everybody. While the original fix was suggested by one person with a particularly acute issue, the fix can help many people not lose issues between the cracksIn May 2014, this happened with R780. The requirement was completed, testing was complete, and the code was UAT'd successfully. Then the business processes changed, and we needed to abandon the code because the process was going to have such a substantial change it would be better to scrap and start over.