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

OD 5.6 - TeamSite Comparison Deployment

JeanIns

We are upgrading to OpenDeploy 5.6, and changing from directory comparison deployments to TeamSite comparison deployments. Deployment will be to 4 web and 2 sun servers. Are there best practices for keeping content in synch when doing TeamSite comparison deployments? Should we compare current edition to prev edition, or current to STAGING? Any other recommendations? Thanks.

Find more posts tagged with

Comments

nipper

You are not giving us much to work with here Jean.

However, the idea of doing as little work as is possible always holds. Not just for developers, but for the system as well. So if there is a more efficient way to do things, then use it.

How are you currently deploying ? Ad hoc ? Via workflow ? On a schedule ? That will impact how you use OD.

If you are deploying from a workflow, there are 2 choices, either use a file list (generated from the WF) and push it out, or take an Edition, & use OD's TS comparison (current to previous editions). BTW, TS 552 automatically generates hidden editions anyway.

If you are using ad hoc deployments, you can snap an edition and use it as above.

For a scheduled deployment (every night at 1 pm) it is a little more difficult since you would need to generate an edition just before the deployment kicks off. I do not think the OD scheduler will do this.

HTH

Andy

Issue.jpg

Adam Stoller

Be careful about relying on sourceTeamsite based deployments using the "magic" EDITION and EDITION/IW_PREV directives - and also be careful not to enable pending session queuing if you are using sourceTeamsite based deployments .... unless you are keeping track of what the last-known-good-deployed-edition is.

I.e. If you have: ed_001, ed_002, ed_003, and ed_004 -- and you attempt to deploy the differences between EDITION (ed_004) and EDITION/IW_PREV (ed_003) - but something goes wrong and the deployment doesn't fully succeed, and you don't realize it in time before ed_005 is cut and another deployment is made - that deployment will only deploy the differences between ed_005 and ed_004 (regardless of whether all of ed_004 got deployed).

However, if you can keep track of the last good deployed edition (ed_003 in the example above) and plug that in via a command line parameter (-k) when performing the deployment, then it doesn't matter how many deployments fail in between, if you deploy the differences between ed_009 and ed_003 you'll pick up all the changes from the editions between those two points.

Similarly, if you are using the pending queue and EDITION & EDITION/IW_PREV and while you're deploying ed_004 you somehow manage to publish and queue up deployments for ed_005, ed_006, and ed_007 - the pending deployment queue will only remember the last one, so after ed_004 deploys, the next deployment will be the difference between EDITION (ed_007) and EDITION/IW_PREV (ed_006) completely missing any changes made in ed_005 and ed_006. Again, if you keep track and plug in the last known-to-be-good edition for the previousArea value, it doesn't matter how many jobs you queue up - you'll be assured of picking up all the changes since a known, fixed milestone rather than a moving target.

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