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; } } }

Deploy a specific edition with time deploy

SethHickel

My users want to use time deploy to depoy specific editions. They often have multiple versions of the same file(s) in process at the same time, , something like multiple versions of a home page, that they want to time deploy over a series of days.

I read the following suggestion from a thread:

"another alternative is to use editions - when your workflow submits the files to staging, cut an edition and store the edition name in a job variable - when it comes time to perform the deployment - do so from the edition rather than from staging."

Can someone provide guidance on how to capture and store this value so that I can allow my users to time deploy a spefic edition? I'm having difficulty finding help on that task.

We currently deploy the latest version. Our workflow submits to staging and builds the edition.

Thank you.

Find more posts tagged with

Comments

nipper

You could do this with a custom menu item, have the user select the appropriate edition (either through the TS GUI or a custom applet) to setect the edition ID and then run OpenDeploy.

Now, this needs to be *really* well thought out. What happens if Adam pushed Edition 1234 and I come by later and push Edition 1233 ? Should it roll it back ? Is that allowed ?

Adam Stoller

You could do this with a custom menu item, have the user select the appropriate edition (either through the TS GUI or a custom applet) to setect the edition ID and then run OpenDeploy.

Now, this needs to be *really* well thought out. What happens if Adam pushed Edition 1234 and I come by later and push Edition 1233 ? Should it roll it back ? Is that allowed ?

Right - do you provide dateDifferent="yes" (allow any difference in time to be deployed) or "no" (allow only newer files to be deployed).

A more confusing issue is whether you allow concurrent deployments, are they transactional, and/or could you have both older and newer versions of the same file being deployed concurrently.... bug I digress ...

RonaldV

Hi Seth,

technically your requirement is simple. crontab or at will do the job.

BUT, BUT, the problem is really what you do do in unexpected (or not thought off) situations? F.i. what do you do when a todays edition is scheduled for deploy next week and this afternoon create a new edition scheduled for tommorrow morning?

AND ALSO, do you required scheduled edition deploys OR do you require schedules publication of file (versions)?

It's not that simple.

SethHickel

Thank you for the responses. I inherited my current environment and am trying to learn and support and develop at the same time. Fun!

To respond to some of the questions:
1. dateDifferent="yes"

2. If Adam pushed Edition 1234 and someone else comes by later and pushes Edition 1233 the business wants this allowed.

3. The deployments are transactional and roll back if the deployment fails on one of the multiple servers.

4. "crontab or at will do the job": My deployment is all done from a workflow that allows the users to set the time of deployment. Is crontab relative?

Perhaps I am incorrectly thinking of editions as a "roll up" of file versions. I think of an edition as a snapshot of the content at a point in time (much like a CVS tag) and that by deploying an
edition I am deploying those files (versions) as they were at the time the edition was created. Am I wrong?

Let me try to paint the picture better with an example of how my users work.

My users create 5 versions of a page, and may deploy multiple files with that page. Edition/version 1 needs to deploy on Sunday, 2 on Monday, and etc.
What my users are asking for is a way to assure that edition 1 (with all the correct file versions) gets TimeDeployed on Sunday instead of the most recent edition (with all the correct file versions).
Currently they all share one workarea but that is not an assurance that the order of creation of edition/versions is the order in which the editions should be deployed.
In the future each content developer will have their own workarea so the order of the edition creation will be even less controllable.

I do agree that my users may not understand all the problems that they could create for themselves with this solution. I am trying to get them to understand.

They do want this solution though.

So another couple of questions:
How do I capture the edition number that is created in order to store it in a variable? Is there a specific function call that I can make?
A second question - can edition names be partially provided by a user? Perhaps allowing them to provide a descriptive name while I append a date/time?

Thank you all for all the thought and help. (See attached wft and od configuration)

RonaldV

Hi Seth,

Once more, it is quite difficult to discuss something like this in a forum. But we can give it a try, can't we?

From looking at your req's all you need to do is create an edition at the right moment and schedule this for deployment. With the clt iwpublish you can create editions, either with a name you define (but must be unique!) OR with auto-generated names. These auto-named names can be retrieved with iwlasted & iwnexted. Your deployment should then deploy this edition (edition-name is passed as a parameter) and NOT from STAGING (which is a bad habbit any way).

And please note that an edition can have an descriptive text added to it which is often more useful then a short marker in the name.

Nevertheless, your users could be up for suprises! "He, this file I submitted should not have been deployed until after the weekend", which happens if user 1 submits file a, creates & schedules an edition for monday-morning; afterwhich user 2 creates and schedules an second edition to be deployed friday-evening. Lot's, lot's of coordination between the content-owners will be required!!!!! (which is my lingo for 'I would not implement it like this')

Cheers, Ronald