nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OpenDeploy Scheduled Deployments - Performance

Mjit

Hi,

I'm planning a OD 4.5.2 -> 5.6 migration and wonder if anyone has any experience with the performance and scalability of scheduled deployments?

We currently have a custom system for this, based around cron (all Solaris system). In the past I've tried this using sleeping workflow's and it just killed the server - we have a LOT of deployments.

So that's it really. Has anyone tried using OD 5.6's scheduling engine to run scheduled deployes - especially file list deploys - and did it work without killing the server?

NB: OD Server will be running on the same physical hardware as TeamSite 5.5.2

Yours,

Mjit

Find more posts tagged with

Comments

nipper

If you are going to schedule deployments, You will probably want to be certain you are not using file list deployments. (which is common for workflow based deployments). Use either date different or TS based (if you create editions).

Performance should not be a huge problem.

Andy

Migrateduser

The scheduler is a capability that's built into the OD Base Server. So you won't see any additional performance overhead caused by scheduled jobs, other than a new deployment thread spinning up for each deployment as it runs.

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Mjit

A related question (while I'm in re-architecture mode) does anyone know if it's possible to specify a file version in a file list deployment (for what we are doing none of the comparison mode are really practical solutions)?

Can I specify version 334 of index.html (the scheduled for deploy at 3pm version), as opposed to version 335 (scheduled for deploy at 5pm version) and 336 (scheduled for deploy at 9pm version)? In this way the active version in staging at 3pm would be version 337, but version 334 would be deployed - without the need to publish an edition for each deployment.

JonathonG

I don't think this is directly possible, but there is something you could try...

Using the item's objectid and the iwvpath command, you should be able to construct a path to any arbitrary version. At least, I've seen this done in earlier versions of TeamSite, and would expect that you can still do it. If this sounds like a route you might want to go down (some effort required), I might be able to dredge up some more details from my memory (sorry, no example code unfortunately)

Jonathon
Independent Interwoven Contractor

Migrateduser

It may not fit what you want to do, but you could have a unique file list for each version. Then use parameter substitution in the deployment config to specify which file list to use in the deployment when you schedule it (using -k option).

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Mjit

tscallan:
That's basically what we use at the moment for un-scheduled file deployments, the trick with scheduled ones is: What if the version of the file in the STAGING area at the time the deployment schedule executes is not the same as the version that was in STAGING when the deployment was scheduled...

JonathonG:
That's the sort of thing I was thinking about - will just have to play around and see what works I guess ^_^

Adam Stoller

If you're using TeamSite 5.5.2 or later - use editions.

If you're queuing up the deployments from a workflow - have your workflow cut an edition, and then insert the name of the edition (iwlasted branchname) as a parameter to the deployment command (-k ed="$ed") - when the deployment occurs - you will be deploying the versions of the files associated with that edition - not staging, so it doesn't matter how many changes have occurred since you created that edition. However, you may need to enable dateDifferent in the deployment config file - but if you do, you also need to consider the pros/cons of the approach.

If you deploy v. 3 at Noon, and you have v. 2 already queued to be deployed at 17:00 - then if you do not have dateDifferent enabled, v. 2 will not get deployed. If you do have dateDifferent enabled, then v.2 will get deployed but you will lose [from the target-side perspective] any changes that were made in v. 3.

As long as the versions you wish to deploy at later periods of time are themselves, later versions of the file - you will not need dateDifferent.

If you're scheduling deployments directly within the OD Scheduler - it's a bit more difficult - I think you'd have to create a wrapper-deployment that runs a DNR scipt that figures out (based on naming convention?) which editions to use for which deployment, and then kicks off another deployment with the proper edition for the source area.

I can visualize a number of variants of the above to do this - but ultimately it depends on your environment and your needs.

Hope that helps

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

JonathonG

To build on ghoti's idea:

As of TeamSite 5.5.2, every submit ends up creating an implicit edition. You can see these edition names (typically, #nn) in the version history for a file. I'm not sure how, but I would expect that you could get that edition name from the version history somehow, and then use that in your deployment. The only advantage (or possibly disadvantage, depending on your viewpoint) to this approach over ghoti's is that you won't have a visible edition for every deployment.

Jonathon
Independent Interwoven Contractor