Auto Publish

Hi-
I have a few content authors that create content. They all work in the same workarea. I am planning on having them use submit direct to push files to staging. I then had planned on having OpenDeploy move files from staging to their respective web servers on a scheduled basis (every night or something). All is fine, BUT, this means I never get editions created. I would like to limit manual tasks, therefore would like to schedule an auto publish (say once a week). I was hoping to avoid using workflows, but I am open to all solutions. I know I could config a workflow to submit and publish, but that means every time a file is modified, an edition is created. Seems like a waste to me. Any ideas? AM I missing something obvious?

Find more posts tagged with

Comments

Migrateduser

if all you want is a single publish once a week then why not use cron/at?

Adam Stoller

What versions of TeamSite and OpenDeploy are you using?
What platform?

If you're using OpenDeploy 5.x - are you scheduling the deployments through there - or are you using cron/at to do the deployments?

If the latter, a modification of the previous suggestion is to just modify the script that you call via cron/at to first publish, and then deploy.

NOTE: OpenDeploy 5.6 will have an increased number of trigger points for DNR scripts and I believe you will be able to specify a publish as a pre-job DNR such that the publish will happen *before* the area=".../EDITION" part of the configuration is processed (that isn't the case in the current version of OpenDeploy 5.5.1 SP2)

NOTE: If you aren't concerned about deploying editions - but rather you are deploying directly from staging - you can use the DNR approach in your deployment configurations today - just run the DNR on the source side before deployment to create the edition.

--fish
(Interwoven Senior Technical Consultant)

DocumentumContentServer6OobjectRelationalDiagram.pdf

Migrateduser

I'd chime in here and put in a plug for *not* deploying from staging, but from your latest edition. Reason: it's extremely useful to know that edition n was deployed at date/time x, and that that edition represents the exact state of the production server at that point in time. You can't get that from staging, 'cause it changes constantly with each submit.

In your place, I'd run a cron/at job nightly, which first calls iwpublish to create a new edition, and then calls iwodstart to run a teamsite-based deployment that deploys the delta between the last 2 editions. Another advantage: very fast deployment, as the temsite-based deployment can simply compare the 2 editions and deploy only the differences between them.

Now, if you ever need to roll your prod server back, you can select the specific edition to roll back to based on time--you have a truely recoverable system.

bw

Bob Walden [bob.walden@interwoven.com]
Interwoven Education Group
IM: Yahoo, MSN bob_walden

Migrateduser

Perhaps in theory that's the smart approach. However, it depends on how you've designed your system. We can safely deploy from STAGING because nothing ever goes to STAGING unless it is being deployed to production. We create editions once nightly for rollback purposes. Plus, we only use filelist deployments. So for us, it is reasonable to always deploy from STAGING.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

MattP

I agree with this approach. All of the above are great suggestions. The downside to creating an edition every night, then deploying, is I may have a lot of editions, with no changes. Only the changed files will be deployed from staging. I have built a similar set-up to Nike's
We are using 5.52 on NT. I assume I can use the publish cmd on an nt scheduled job.
Thanks again for everyones help.

Regards
Matt
matthew.petitjean@us.gases.boc.com

Migrateduser

yes, iwpublish should work fine from the nt scheduler (assuming that the options passed are correct). Just keep in mind that this will only publish a TS edition and not do any actual deployment (though from the sounds of it you have deployments from staging working just fine and there would not be any need to run a separate deployment from the edition being created).