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

 

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

 

/wp-content/uploads/2016/07/1_1000274.png

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 of your release, 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 development

 

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

/wp-content/uploads/2016/07/2_1000275.png

/wp-content/uploads/2016/07/3_1000276.png

Approach 2: When New BOs are created in the existing solution (Next Blog)
Recommendations for addressing the n+1 landscape – Approach 2

This is a 4 part blog series with the following links:


Recommendations for addressing the n+1 landscape – Approach 1(This Blog)

 Recommendations for addressing the n+1 landscape – Approach 2(When new BOs are created in the existing solution)

Recommendations for addressing the n+1 landscape – Approach 3 (Switch Option)

Recommendations for addressing the n+1 landscape – Approach 4 (Commenting out Code)

 

With contributions from Pramodh Patil Stefan Hagen Sridhar Natarajan

 

 

Thanks

Vinita

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply