Page Comparison

...

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 PREPROD, if we have to actually remove code, there are again two approaches:

There is nothing wrong with the code, we just don't want it available to the customers yet

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 has  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.

There is nothing wrong with the code, we have changed our mind about releasing it, and it probably won't be released in the future

This is extremely rare, but it has happened. We had a situation where we fully developed a Catalog Item, got to UAT, and the customer's process had changed so much that the code needed to be scrapped and the process started over again. In that situation, we need to do several steps:

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 soIn 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.