ChaRM flow

Question

Dear Experts,
We are in the process of implementing ChaRM on our Solution Manager EHP1
system. We have configured ChaRM for our ECC landscape which is a 4
system landscape u2013 development, integration, quality and production.
Integration server is used to import and test the transport of copies.
We have completed the required configuration and are now in the process
of testing various forms of corrections in a maintenance cycle.
We could successfully create an urgent correction, regular correction and
change request and imported to Production System. It will be great if
you could clarify few things regarding the same process.
Here are few questions:
1.     Suppose we have a defect in production system and the project
manager has assigned 5 developers to work on this defect. Therefore, the
5 developers start working on this defect and will create 5 transport
requests. Now, after these 5 transports have been imported till Quality
Server, the project manager would not approve of 2nd and 3rd transports
to go into Production. So, the 2nd and 3rd developer will revert the
changes till QA. At this point, can we make QA the final destination and
leave these two transports in QA? We do not want these to go into
Production, however rest of the three will be imported to Production.
Could you tell if it is possible? If yes, how?
2.     Suppose we want to have one maintenance cycle for all the defects
occurring in Production. Now there are like 20 developers working on the
same maintenance cycle for different defects.
Initially, the change manager sets the project phase to u201CIn developmentu201DE.g. developer 1,2, 3, 4 and 5 have immediately worked on their
respective defects and would like to Test their changes in QA. However
other developers did not complete their work and are still in the process
of developing their changes in DEV. Should the first five developers
wait until all the remaining developers complete their work (cause unless
the project phase changes to u201CTestu201D phase, the first 5 developers cannot
test their changes and if it changes to u201CTest u201C phase, the remaining
developers cannot complete development) ? Is there any solution to this?
Do we have to create separate projects for different defects or can it be
managed with one project and no-wait for all the developers?
3. It will be great if could provide us a scenario that has been
implemented already.  e.g., under which situations will you use normal corrections and urgent corrections.
Thanks,
Ravali

Answer 1

Hi Ravali,
1. In response to your first question, now I may have misread this so please correct me if I have the wrong idea.  But it is bad practice to leave any transports behind anywhere in your landscape (i.e. not ending in Production) as you will end up with inconsistencies in your landscape and will cause long term problems with your development and testing.  Really the two transports you don't want to implement should be reversed in a subsequent sixth transport.  Then all six transports imported into Production, the sixth reversing the actions of the second and third maintaining your landscape consistency.
The whole resolution of a defect would have one change request - normal/urgent change with potentially multiple transports and as such would follow the above.  If it envisaged that the defect will be resolved in multiple drops, it would make sense to have multiple change requests (e.g. Defect XXXX fix A, Defect XXXX fix B etc...) so they can be managed through landscape.
2. I am guessing your second question refers to only normal changes as urgent changes can be imported almost independent of the project phase. In regards to the maintenance phases you can still import normal changes (i.e. transports) through the systems in your landscape in all except Production even at phase "Development with release".  In your scenario transports for developer 1-5 can be released and import job triggered to put them into you test systems (even at phase "Development with release"), whilst your remaining developers can still work on their changes.  Optional but once all changes are developed you can do integration test/UAT, you can update phase to "Test" (defects identified at this phase can still create Test Messages that can allow creation of transport requests) and confirm as a whole your Maintenance Release is successfully tested and ready for import to Production.
3.  We currently have a 7 system landscape, but to keep it simple I will just use top 5.  Take the following landscape:
DEV1 -
> QA1 |> DEV2 -
>  QA2 -
> PRD
Maintenance cycle: source development system is DEV2, testing in QA2. Monthly maintenance releases run for small normal changes, urgent changes as required (as a rough estimate this happens 2 to 3 times a week).  All changes must be retrofitted back into DEV1 to ensure all fixes will end up in all systems.
Implementation project: source development system is DEV1, testing in QA1, Integration and UAT in QA2.  Capability release runs planned these are usually big developments that run 3-12 months. When the implementation is ready for integration test/UAT the "wall" between QA1 and DEV2 is "opened" so testing can be done on QA2 prior to import into PRD.  Note during this period we have another environment that can deliver urgent changes, but these must be kept to absolute emergencies.
Hope this helps
Paul