Addressing the n+1 landscape dilemma

Approaches to address continuous development on objects across releases

This blog series talks about the scenarios in C4C where you need to address the following:

- Phase 1 (P1): You have a Dev -> Test -> production landscape where you have done PDI developments on Dev, tested on Test, deployed it to Production and gone Live

- Phase 2 (P2): Now, you need to fix bugs that arise in the P1 environment, plus you also need to do additional NEW developments to

- SAME objects that are there in P1

- NEW objects introduced only with P2

This can be a challenging scenario depending upon how your project was structured – in terms of identifying the release timelines and gaps between the releases, the extent to which you do ‘continuous’ development across releases on the same objects, if you are mainly introducing new functionality only with new objects, and the time you allocate to tests and bug fixes before starting with a new release

Also, do remember that in general, PDI should be used for the Last Mile scenarios and development. For full fledged development, you can use HCP

Typically, we have the standard 3 tenant landscape as such:

Develop on Dev1, deploy to Test1 for testing in an Integrated environment and deploy to production

The approaches that we discuss in this blog series depending on the scenario are:

1. Do limited Production Bug Fixes directly, and continue development on standard 3-tenant landscape

2. New BOs created in the existing solution

3. The SWITCH option

4. Commenting out code

Approach 1: Recommended: Do limited Production Bug Fixes directly, and continue development on standard 3-tenant landscape (this blog)

Scenario: In Phase 2, you may have a situation where there are bug fixes that can be identified by a concerted early test process

Objective: In this approach, the objective is to address the bug fixes early on, BEFORE we get into a Phase 2 development cycle. In case still needed, for Very High issues, address them directly on production

Continue with the existing 3-tenant Landscape
Perform thorough testing in the Test tenant to identify and fix issues early
After Go-Live, have another – at least 2 weeks’ window to see if any high prio issues are reported and fix them with the normal patch process. Most critical issues are generally reported in this window and get corrected early on. Till this time, no new developments should start for Phase2
Later, during the course of Phase2 development, if there are still urgent and Very High Prio issues, fix them (absl only) directly in the production tenant using the Production Bug Fix Feature, and double maintain that code in the Dev tenant. Hence, no further patches are introduced for taking care of bug fixes, instead we did direct production bug fix only. The next patches will only come with Phase 2 completion.
With 1608, you now have the production fix in the Pre-production tenant as well so that you can test it before doing this on the production. For details, you can refer to the PDI rollout of 1608
All other issues with a lower priority can get clubbed with the Phase 2 release/go-live

The tenant landscape doesn’t change in the above scenario. With the same 3 tenant landscape, Phase 2 new development also comes in as a regular patch as well as low priority issues of Phase1 that didn’t get addressed through the Production bug fix.

In general, if there is a lot of new functionality for a subsequent release, it is more advisable to have a shorter release in between to ensure that bugs to be fixed get minimized for that release, since lesser functionality gets introduced. Also, the fact that testing and correcting a huge chunk of development can be reduced and be made more effective

Below: Production Bug Fix Method explained