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 ? sourceFilesystem VS. sourceTeamsite

NathansDIS

We currently have a deployment that uses sourceFilesystem to specify the source in the configuration. I know that using sourceTeamsite with a previousArea attribute can speed up the deployment due to not having to check every file on the target. The question is have is regarding the reliability of using sourceTeamsite vs. sourceFilesystem. Since we only run this once or twice a day, the little performance improvement isn't worth running something that is more error prone. Can anyone chime in with best practices, caveats, advice, pros and cons? Thanks for your time.

Regards,

Nathan
Washington State DIS
~~~

Find more posts tagged with

Comments

Adam Stoller

sourceTeamSite should ONLY be used if you keep track of the last *successful* deployment - rather than always just assuming that the previous last edition is the previous last successful edition. It will make deployments faster because it is easier/quicker for TeamSite to provide a list of files that changed between [normally] two editions than it is to perform a file-by-file comparision between the source and target servers - however, if you miss any interim deployment for whatever reason and don't set the previous area to the last *successful* deployment, a sourceTeamsite deployment could be successful without actually deploying all the content you want to deploy.

For example - using editions as an example as that's the usual scenario for TS based deployments:

Previous Area	Source Area	Result
INITIAL (empty)	ed_001 (new files 'foo' and 'bar')	foo and bar are deployed
ed_001	ed_002 (modified 'foo', added 'baz')	foo and baz are deployed
ed_002	ed_003 (modified 'bar', added 'mumble')	assume deployment failed for whatever reason
ed_003	ed_004 (modified 'foo')	Only 'foo' is deployed - instead, you really want ...
ed_002 (the last successful deployment)	ed_004 (modified 'foo')	foo, bar, and mumble are deployed

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

nipper

One other question is how this will be invoked. If you are using Workflow to kick off OD, then
you can use the file list deployment which is even faster. As in Ghoti's example you need to make
certain any errors are caught (I get an email on failed ODs), so they can be re run.

HTH

Andy

NathansDIS

Is there any way to tell OD to automatically use the last successful deployment as the previousArea? I would really like to eliminate the human element from the equation determining successful execution of this deployment. Thanks!

-Nathan
DIS

nipper

Sounds like a heck of a FR. To my knowledge this functionality does not exist, but you should ping Todd.

Putting some logic in a script to do this is pretty easy. However using these deployments (TS based or date) is not a
great idea in a workflow (because you can have two deployments run in parallel). That is why the file list deployment
is recommended for the workflow deployments.

HTH

Andy

Adam Stoller

Automatically - as in out-of-the-box - no. OD does not maintain state with respect to TeamSite editions, success, and failures.

If you develop your own system for handling the deployments - you can keep track of successful deployments and use that information within a parameterized deployment configuration file to "do the right thing".

On the other hand - if you use source/target file system comparisons to do deployments you don't really have much human element in there -- again, assuming you're deploying from either staging or an edition to a target location that is supposed to look exactly like the source location ... or where you've included filters to handle the expected discrepancies.

If you're doing the deployment as part of a workflow process - then the filelist mechanism tends to make the most sense.

If you can provide more details about the context in which you will be running your deployments, who/how/when/when etc - it will be easier to provide better suggestions and/or pros and cons.

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

NathansDIS

For the most part, this deployment is being run via a scheduled job, once daily, right after a new edition has been cut by another scheduled task. Occasionally, it is run manually by the site administrator, but it is never invoked from a workflow. FYI, not sure it matters, but I didn't mention our platform: Windows 2000, OpenDeploy 6.0, TeamSite 6.1.

Thx,
-n

Adam Stoller

Given your scenario - you could use either a TeamSite based or a regular file system (source/target) comparison deployment.

The advantage, as has already been pointed out, for TeamSite based deployments is that they tend to be faster the source/target comparison deployments because the diff happens locally on the TeamSite server.

The disadvantage, as has also already been pointed out, for TeamSite based deployments is that you need to make sure that the previous area is set to the last edition *known* to be deployed - which is often, but *not always* the next-to-last edition - and you would need to create a process surronding the deployment to (a) retrieve the last known-to-be deployed edition and pass it in as a parameter for the previous area; and (b) update some record, somewhere, with the name of the current edition being deployed *after* it has successfully been deployed.

The advantages / disadvantages of a source/target comparisson deployment are essentially the opposite of those for TeamSite based deployments -- however the time-to-deploy issue is more a factor of the number of files to be compared and the network bandwidth between the two servers. In most cases, especially in yours where you are deploying on a regular daily basis - the difference in time is usually negligable and thus the source/target comparsion's disadvantages tend to be less than the TeamSite deployment's disadvantages.

If you have the ability to create the wrapper surrounding the TeamSite based deployments - by all means do so - but if you're not feeling sure about how to do it reliably - stick with the source/target comparisson style.

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