Hi all, we're looking to deploy our application of about 3,000+ objects to a new environment for the first time. We've split the application into 3 smaller applications, one which contains the DB objects, one which contains the groups, and the last one which contains the rest.
I'm going to look at deploying the DB changes, then the DB objects, groups, and lastly the rest of the application. My main concern is dealing with timeouts - when we've tried to deploy a lot of objects in the past (using compare and deploy) we've seen an issue where the deployment takes so long that it eventually times out. Is there any way we can split the objects further to deploy them in smaller batches?
Any other advice would also be appreciated.
Thanks.
Discussion posts and replies are publicly visible
In the past few years they've made some quality-of-life changes to the way deployments are handled from the user-facing perspective, to make it a bit less of a hassle when we're talking about potential timeouts for large applications. In the past they used to try and synchronously run the entire deployment then show a success screen, but any deployment larger than "moderately small" (or thereabouts) seemed to hit the timeout limit and you'd be stuck waiting for the error, then crossing your fingers that it worked fine on the remote side. Now, instead, it just takes the deployER to a "deployment in progress, press the Close button then go check the target environment..." form, which you can get out of right away.
For your approach splitting up the packages - that's about what I'd recommend (DB objects, followed by other application pieces). I'm not sure how necessary it is to split out the groups, though it also shouldn't hurt and I guess it's clean from a dependency standpoint, since groups can't really depend on other object types (unless i'm blanking on something).
Maybe it's too late but if you have an empty TEST or UAT environment, it might be the perfect chance to test out your approach there, before trying it for the first time for your PROD deployment. But I understand that circumstances don't always really allow this.
I do not split up apps. This was a best practice from >10 years ago and not necessary anymore. Many people still insist on doing it and when I ask why, I get back: "We've always done it this way. Someone once said that's how it should be."
I try to build my best practices on facts, not on legends.
And yes, I know, there are certain situations in which splitting up CAN help.
IIRC it helps to stratify and specify where something went wrong if something goes wrong. Appian handles this better now but I don't pretend it handles it perfectly yet.