721 PLC Productoin Deployment from edition?

Environment[indent]TS/OD/LS 7.2.1 Patch 1 on Linux[/indent]
Issue[indent]There are a number of things I don't like about the OOTB PLC workflow, and one of them is that the submit takes place after the production deployment and that the production deployment takes place from the workarea.
So I set about modifying our PLC-variant to have the submit task followed by an external task followed by the Production Deployment task.
The external task runs a script that:

Find more posts tagged with

Comments

Rick Poulin

So I set about modifying our PLC-variant to have the submit task followed by an external task followed by the Production Deployment task.

Not that I've tried, but it feels like this is fundamentally different from how the PLC was designed. Yes, they could probably have cast the area to a CSArea for the purposes of generating a file list, but there's other things in the PLC that actually need to modify the content, such as that piece at the end that writes the DeploymentAudit xml EA on deployed files. I suspect that if you start going down a path of customizing this, you'll end up rewriting the whole deployment task from scratch.

What don't you like about publishing from the WA? I've always felt uneasy about the other way around, where you could end up with stuff in staging that never made it out to the runtime.

Adam Stoller

In this case (an inherited environment and process) - there's no checking or preventing the same file from being processed by more than one workflow, and there's no explicit locking taking place within the workflow - so one could review / approve version X (or X+') of a file and then (in the current model), deploy it and then end up submitting version Y (or X+'' to become Y).

In my revised scheme - the submit would happen before the deployment, but because of the lack of checks and locks and such - and the potential for a requested delay between the end of the review and the beginning of the deployment, it would be possible to again review and approve one version of the content but then end up deploying a completely different version of the content because it was changed in the workarea.

If, on the other hand, you submit and create an edition directly after the review process has completed, you can then delay as long as you want to then deploy the version that was approved from an edition.

Of course, this opens up the other can of worms in that you could theoretically deploy an older version of the file over a newer version of the file - but I think you should be able to protect against that with the proper directive in the deployment configuration.

Regardless, I didn't realize EAs were getting written onto the files after (or at the end of the) Production Deployment task -- that being the case, I'll probably have to move my submit task (and the web content & edition creation task) back to after the Production deployment task.

Thanks for the info - it should help prevent me from wasting a lot of time on this ;-)