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

deployment issue

madmax

hi all ,

i am tring to code a deployment script but before i do i really need to know few facts--

1)let's say a user is editing a file workarea\personal\index.asp . so immideately index.asp file will be locked by the user now if another user deployed the full workarea to QA then is it gonna deploy the locked file? or it's gonna deploy the file before it was locked.

2)same questions goes to workflow? the files are locked till the job is finished.so if there is a deployment before the workflow finished then what will happen to locked file ? are they deployable on the locking state ?

thanks in advance.

Find more posts tagged with

Comments

jbonifaci

The answer is, it depends on how you code your workflow. If you tell your workflow to ignore locked files, they won't get submitted to staging.

~Jeff

Adam Stoller

1)let's say a user is editing a file workarea\personal\index.asp . so immideately index.asp file will be locked by the user now if another user deployed the full workarea to QA then is it gonna deploy the locked file? or it's gonna deploy the file before it was locked.

Are you deploying from a workarea? from staging? or from an edition?

In general - you pretty much never want to deploy directly from a workarea.

If you deploy from the workarea - then you're deploying the file in the workarea - regardless of the lock.
If you deploy from the staging area - then you're deploying whatever version is in staging at the time of the deployment - regardless of what's going on in any of the workareas.
If you deploy from an edition - then you're deploying whatever version is associated with that edition - regardless of what's happening in any workarea or staging.

2)same questions goes to workflow? the files are locked till the job is finished.so if there is a deployment before the workflow finished then what will happen to locked file ? are they deployable on the locking state ?

The notion of a lock in TeamSite is internal to TeamSite - so if the file is locked in TeamSite and you deploy it - the result is "a file" not "a locked file" on the target server. Beyond that, see the above responses to the first question.

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

jbonifaci

What Adam says is all true.

I guess I assumed you meant that you submitted the whole workarea and then deployed from staging, as I didn't even think anyone would ever actually deploy from the workarea. If you're deploying from the workarea, then obviously it will deploy whichever version is in the workarea.

~Jeff

madmax

sorry for the cross reference. i thought by that way i'll get my response fast. because most of the developer usually comes to teamsite product line and my question is related to open deploy so that made me to post in two places.

thanks a lot to clear my concept about the teamsite lock.

so if it's simple deployment of all folder under workarea-- which one will be more preferable -- staging or edition?

i think i'll prefer staging.
REASON:
We update content often that way we can save deployment time by not creating edition all the time

jbonifaci

How are your deployments kicked off?

Are they scheduled ? If they're scheduled, I would recommend cutting an edition each time you do a scheduled deployment and deploying from the latest edition.

Are they kicked off every time a user submits a file to staging? If so, I would question why you aren't just doing a filelist deployment with the file(s) submitted to staging? But you would likely want to deploy from staging in this case, as creating an edition after every submit is overkill.

~Jeff

Adam Stoller

... as creating an edition after every submit is overkill.

Well - technically speaking, since 5.5.2 - an unnamed edition is created every time you do a submit.
The purpose of cutting an explicit, named, edition would be to provide for the ability to retrieve the same version(s) of the file(s) at a later time (rollback, re-deployment, whatever).

In general though, I agree, creating a named edition afer every submit is overkill.

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

madmax

thanks to all.

now i'll start writing my script. our user use open deploy gui to deploy , so i'll write a script that will deploy all the files from staging to a webserver file system. i also think of deploying the last edition to the file system. but i want to avoid creating unnecessary edition since i can deploy directly from staging. but i have small question left -- in staging files are read only but after deploying the files to webserver , what will be all those files status?

LooseCannon

you control the dir/file perms via the OD script

Adam Stoller

More precisely - via the permissionRules (within the target or targetRules element) in the deployment configuration file.

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

madmax

thanks ghoti.