HI Guys,

i would like to know, Which is better deployment practices b/w patch deployment and full package deployment.

Specially when you using IS and TN only.

hopefully wish to get some quick answer

Hello Vipin,

It is always good to deploy only the delta changes instead of full deployment. Both Repository and Runtime deployments supports this.

With the full deployment, if you have to perform post installation steps you need more things to cover.

Again, for any approach I would highly recommend the automated deployments with sanity performed automatically.

Hi Srikanth,

You have mentioned ‘both repository as well as runtime supports’ partial/patch deployment. Where exactly we specify full package deployment or patch deployment in repository based setup

Regards,
Ketan

It depends on your use case basis, say you have a package X on Prod already. You want to add/delete some flow in it then I would suggest you to go with Patch deployment and not full (make sure you select the right .idf/.ndf/.java files for patch release). However full deployment will also work which will just replace the package from source server to target server.

For more details refer the Deployer guide and also IS administration guide.

I echo with @Mahesh and it’s all depends on the case by case basis with unique deployment environment’s.

Please follow the Deployer guide and steps to consider patch/full package deployment’s (best practices and cautions)

HTH,
RMG

Thanks Mahesh, Srikant and RMG!!! Replies are good, actually we are working on Production environment and we working on enhancement and code fix, would you suggest with Path Deployment ?

Meanwhile i will go through with Deployer’s Guide for find more details…

Thanks in advance!!!

Here i would need to know, what are the elements cant be migrated as patch deployment???

Yes, you should always promote delta changes (patch) to production.

For example, consider you are deploying a full package which has properties files/connections which will have different values in Production.

You really do not want to deploy these as the deployment involve substitutions or manual changes.

Product deployments should be quick and should not cause issues that are not related to what you are deploying.

Hi Srikanth,

exactly for this reason we have separated the Adapter Connections and Listeners to a dedicated package which will never get deployed, but will be maintained manually on each instance/environment.
For the same reason we have separated the business implementation for the BPM Models from the generated package.
So we can delete and regenerate the Process Runtime services without losing the internal logic.
Or if there are changes to the internal logic we do not need to redeploy the complete PRT services but only the affected implentation service.

Regards,
Holger

Saved in the “best practices” folder

As far as I know, repository based deployment does not allow partial / patch deployment. Only full packages can be deployed.

And it wonders me that patch deployment is praised as the recommended way (well, time has passed since then, so the same people might recommend different things today). We always used full package deployment (we adopted repo based deployment early). We also did not separate connections/listener into separate packages, and used the variable substitution feature to adjust the values to the target environment. And never experienced problems.