What is the standarad or best practice out of following two options for making Patch Code for any customization which includes more number of
components considering there will be more maintainance in future on that customization (approx. 150 compoents have to move from development server to QA/Production Server).

1) Single one patch code(say TEST) which includes all components during the first delivery, and the next consuective number (TEST_1,TEST_2)
for further maintainance issues.
2) Multiple patch codes(say one patch code which includes only tables and labels , another with session,scripts & so on)

It will be helpful if I get the adavantages and disadvantages for both of the above options.

Thanks in Advance,
Prashant

Hi Prashant,

(I assume that you dont want to go for PMC solution way.)

I will suggest you to go for 1 single patch including all the components (tables, sessions, scripts/objects, reports, labels, etc...)for the initial delivery(Patch Code can be say <Proj><ProjPart><CustPart>. e.g. PRJ001_001 where PRJ001 is Project, _ is Project part and 001 is Customization part).

For sub-sequent deliveries you can include only changed components in the patch naming patch as PRJ001_002, PRJ001_003 and so on. This will also help you in tracking the changed components.

The disadvantage of 2nd option can be you will end having too many patches. say for initial delivery you will create multiple patches n again for subsequent deliveries there will be respective patches for each initial patch. doesn't look good to me.

I hope this answers your question.

Thanks Milind for your quick reply.
You assumption is right no PMC solution way.

I just thought that option two will avoid the patch codes for future maintainance by just overwriting respective intial patch code, but that will not keep track on what exact component has been changed.

So Single patch code option looks better.

Thanks & Regards,
Prashant

Customization Mangement can also be used, and it then ties to the Patch.

You can have a project and a project part, the part can be used for the release number.

Internally on the part, there is a customizaiton part. This can include multiple packages, but I suggest if you have multiple VRC's (one for inhouse and one for external) keep them seperate.

Create one for sessions, forms and program scripts, one for dals, labels, and dlls.

Create customization parts for objects 001 and for metadata M01.

Once you create a patch, you can sync the table with production (tties400 ttiex410) and use the patch as a backup. Make sure you point the patch directory into a new "backup" directory.

In the event you have to back out the patch, you can put the original back.