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

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


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)
With contributions from pramodh.patil stefankrauth sridhar.natarajan
Thanks
Vinita
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 4246 | |
| 3357 | |
| 2603 | |
| 2153 | |
| 1983 | |
| 1255 | |
| 1164 | |
| 1122 | |
| 1100 |