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

Staging vs Edition

Digger

Hi,
I've got my thought on this but would appreciates your input on this best practice approach that we should use.

Here the question:

• •The client wants to create 3 editions per day (morning, noon and afternoon) and deploy the content from editions, not from staging area. By doing this they will always know what version of the content is on-line. They have very strict rules for content versioning. - Is it a common approach, it is a normal Interwoven practice, to version and deploy the content like that?

Find more posts tagged with

Comments

moonkhanna

Hi,
I've got my thought on this but would appreciates your input on this best practice approach that we should use.

Here the question:

• •The client wants to create 3 editions per day (morning, noon and afternoon) and deploy the content from editions, not from staging area. By doing this they will always know what version of the content is on-line. They have very strict rules for content versioning. - Is it a common approach, it is a normal Interwoven practice, to version and deploy the content like that?

Makes perfect sense to me. Excellent and to the point method. Generally, you may also deploy directly from Staging and then make Editions as per requirement. Still retains Version history but with deltas. The above you have explained would very precise and nice to have.. but you will also need process Publish an Edition as an exception when some important content needs to be published immidiately.

Migrateduser

Do you think the content will change that option from morning, noon, and evening? The common practice is to submit the files to staging, then when you have everything changed and want to capture that moment, publish the edition. From the description, it sounds like staging would be better.

moonkhanna

Do you think the content will change that option from morning, noon, and evening? The common practice is to submit the files to staging, then when you have everything changed and want to capture that moment, publish the edition. From the description, it sounds like staging would be better.

In some environments, retaining content with time stamp is necessary and which can be retrievable anytime...

In Such environments, publishing an Edition at a specific time in the day is more useful and handy..

ISCBorisB

Do you think the content will change that option from morning, noon, and evening? The common practice is to submit the files to staging, then when you have everything changed and want to capture that moment, publish the edition. From the description, it sounds like staging would be better.

If possible, Deployment from Staging should be avoided. The reason is a Submission. If it so happened that the file
in the OD Manifest gets submitted during Deployment the Deployment may (and often will) fail.

There are certainly ways to mitigate the issue ( proper WF locking and the like ) but other things being equal Edition
deployment is safer and makes overall design more scalable. Even if you do not have multiple WAs and concurrent Content
development today you may tomorrow

Adam Stoller

I implemented something like this for a customer where I used the dnrDeploymentJob element in my deployment configuration file to run a script that generated the edition and then the deployment configuration proceeded to deploy the latest edition (which is the one that was just created).

singh

qq. if a branch is hacing multiple work area for diff developers will this be a good approach ? Also if ur doc root is 1 gig and servers are over WAN link then i think creating an edition and deploying the complete edition is not a good idea or no ?

Adam Stoller

qq. if a branch is having multiple work area for diff developers will this be a good approach ? Also if your doc root is 1 gig and servers are over WAN link then i think creating an edition and deploying the complete edition is not a good idea or no ?

Well I cannot tell you what you think.

Multiple workareas on a branch should not be an issue if the intent is to make sure that only fully approved content is deployed and that the deployed content is fully retrievable (either for rollback, litigation, or any other reason).

Are you talking about a doc root being 1 Gb or a backing store being 1 Gb?

When you deploy from an edition with a diff-based deployment - you pay the overhead cost of performing a diff of the all the files in the edition with their counterparts on the target server, over the network - and only those files which actually differ (based on whatever comparisonRules you configured) will get deployed. Chances are it will be less that the complete contents of the edition (after the initial deployment is done)

When you deploy from an edition with a file list deployment - only those files listed will be deployed - so unless you provide a file list that contains every single file in the edition, you're probably only going to deploy a small fraction of the total content of the edition.

If you decide to use a TeamSite based comparison deployment, you need to make sure you correctly identify the last successfully deployed edition before comparing it with the edition whose contents you want to deploy. Once you've taken care of that, you're again likely to be deploying only a small fraction of the total contents of the edition (unless your previous edition is "INITIAL").

Now - if you're attempting to a fan-out deployment over a WAN, you might want to look into the option for "routed deployments". For a single hop spread, it might be overkill, but if you're deploying from a data center in NYC to farms of receivers in New York, California, London, Paris, China, and Japan (add whatever else you want to the example) - then a routed deployment will probably significantly improve your overall performance.

Arijit

To answer your original question, it might be worth understanding the requirement in details. What is the real business use case behind creating morning, noon and afternoon Editions? Does the content change at that rate? How do deployments happen - through workflow or schedules?

It is not good practice to deploy from STAGING area. Staging area is just read-only approved content it is not a point in time snapshot of your web-site content. Once an Edition is published that is when a point in time snapshot gets created. For a site where content change is so rapid (morning, afternoon and evening) maintaining time-stamped snapshots will also give you a way to rollback if necessary.

And for deployments, as Adam mentioned in his post, there could be multiple solutions defined to do differential deployment keeping in mind key business requirements - performance, time to deploy etc. Does that help?

Digger

It certainly help, thx for all of the input.

Michel