This content has been marked as final. Show 2 replies
Although it entirely depend on your org startegy:-
I would suggest:-
1) Patching Instance:- Entire control of DBA(no developer access). Every patch to be applied should be rtested here at first. This will make sure you are testing your patches prior to moving it to any controlled env.Moeover this will give liberty to your DBA's to test various activity like performnace management, propose enhancement etc etc...
2) Development Instance:- Atleast one, can go upto n number depending upon requirment. In some env, i have seen projects where differnet teams are used for different projects or module and they don't want different team to interfere in others work and hence having different dev for different teams. This should be uncontrolled env, developers having all the accesses.
3) PRE-UAT:- In case of multi dev where developers want their changes to be tested wrt changes done by different teams. This should be only One and should be uncontrolled.
4) UAT:- Controlled env, used for business testing. Only DBA's and some business users having access to it.
5) Live:- Controlled env, only super users having access to it.Code movement done only after apporval from CAB.
Some ppl do take startegy of not moving any code to LIve but instead they have PRE-LIVE instances where all codes move into to every month they refresh LIVE from PRE-LIVE.
Typically, you at least have a PATCH, DEV and TEST instance.
Depending on the complexity of your implementation, number of projects going on at any time, the size of your team, the amount of testing you need to do, you may need more instances.
Hope this helps
Independent Techno-functional Consultant