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

Sync'ng

SethHickel

I have 12 dev/qa servers to which folks can push independently or in groups. Currently my users sync by pushing all content to individual servers. Is there a better aproach and/or process? This causes four and five hour OD jobs to run. Ugh!

Find more posts tagged with

Comments

Adam Stoller

I have 12 dev/qa servers to which folks can push independently or in groups. Currently my users sync by pushing all content to individual servers. Is there a better aproach and/or process? This causes four and five hour OD jobs to run. Ugh!

Generally speaking, a fan-out deployment to N-servers is faster than N individual deployments to each server if those deployments are being run serially (fan-out implies concurrency).

Are these servers all on the LAN or are a number of them on the WAN?
If you're deploying from a server in one country to N servers in another country - it might be worth looking into routed deployments (read the manual for details) - you'll have to incur the expense of an additional Base Server for each "hub" you create - but it would allow you to do a single point-to-point deployment with the hub across the WAN and then have the hub do a fan-out deployment to N servers along the LAN (or at least to divide the traffic so that you're not doing all N legs of the overall deployment from one server).

Also - are these filelist deployments or comparison deployments? Generally when talking about "syncing" you're talking about comparison deployments - and as long as you don't let the servers get too far out of sync most of the deployment process should be doing the diff and there should be relatively few files that need to actually be deployed.

If they're doing file list deployments of files that might already be in sync - they're wasting bandwidth since the files in the list will be deployed regardless of whether or not they are already the same.

SethHickel

Good information - thank you. More questions ...

I will create a fan-out deployment. And this would be transactional - agree?

So - in my OD configuration I have dateDifferent="yes" but the documentation states

This differs from the OpenDeploy default date-based comparison setting,
where a file is deployed only if the source file is newer than the target file. A value
of yes indicates that the file should be deployed. Default value is no.

Which makes me question if I should have this setting. Does having this set to YES mean that any date difference will cause a file to be pushed and if by leaving it blank I accept the default OD setting then only newer source files will be pushed?

And a question: is doing a comparison deployment configured completely in the OD configuration or is there a workflow portion of this? Or should it simply be run from OD by those authorized to do so. Can you point me to some examples?

I have the following in my OD configuration for one of these servers: This OD configuration is used by a workflow.
[php]

ignoreGroup="yes" checksumCompare="no" />

svrTryDisableOverwrite="no" rmReadOnly="no" compression="no" compressionLevel="" applySourceFileTime="yes" checksumVerify="no" byteIncremental="no" /> [/php]

Adam Stoller

I will create a fan-out deployment. And this would be transactional - agree?

You can enable or disable the transactional aspect as you see fit. Transactional is slower, but provides an all-or-nothing result. If you do it non-transactionally - you want to make sure you check the results if you get a "completed with errors" status.

So - in my OD configuration I have dateDifferent="yes" but the documentation states

Which makes me question if I should have this setting. Does having this set to YES mean that any date difference will cause a file to be pushed and if by leaving it blank I accept the default OD setting then only newer source files will be pushed?

Your understanding is correct. The reason in favor of allowing dateDifferent="yes" is that it overwrites anything that some misguided person might have done directly on the receiving server - e.g.: someone modified a file directly on the web server instead of making the change to the file within TeamSite. Of course overwriting such a change means the change gets lost - but that's the price of doing things wrong.

And a question: is doing a comparison deployment configured completely in the OD configuration or is there a workflow portion of this? Or should it simply be run from OD by those authorized to do so. Can you point me to some examples?

It is primarily a matter of the OD configuration. The workflow portion is only concerned with invoking the deployment with the correct parameters. Usually workflow-based deployments are file-list based, and as such the workflow is responsible for creating the file list and passing it as a command line parameter to the deployment. In the diff-based scenario your workflow doesn't have to do that -- but it shouldn't hurt anything if it does because if the parameter is unused by the deployment it is completely ignored.

I have the following in my OD configuration for one of these servers: This OD configuration is used by a workflow.
[php]

ignoreGroup="yes" checksumCompare="no" />

svrTryDisableOverwrite="no" rmReadOnly="no" compression="no" compressionLevel="" applySourceFileTime="yes" checksumVerify="no" byteIncremental="no" /> [/php]

All the attributes that have a value of "no" can be omitted as, I believe, that is their default. You generally only need to specify the attributes if you want their value set to "yes".