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

filelist deploy from STAGING

smg

Hi,

is it NOT a GOOD PRACTICE to deploy files from STAGING (instead deploying from WORKAREA is the BEST PRACTICE)

Could some one explain me why it is so?

Thanks.

Find more posts tagged with

Comments

moonkhanna

From my understanding, you can deploy from anywhere you like depending on your Requirement.

jkm

Hi,

is it NOT a GOOD PRACTICE to deploy files from STAGING (instead deploying from WORKAREA is the BEST PRACTICE)

Could some one explain me why it is so?

Thanks.

This is a good practice to deploy from STAGING instead of WA ...If you deploy the content after submittin to STAGING then content is versioned before going live and it is easy to track the changes.

But it always depends upon the business requirement to decide upon the correct route

nipper

Hi,

is it NOT a GOOD PRACTICE to deploy files from STAGING (instead deploying from WORKAREA is the BEST PRACTICE)

Could some one explain me why it is so?

Thanks.

It is NOT a good idea due to this issue (which I have seen multiple times).

Submit to Stage
Deploy to Prod (from Stage)

What happens is that the deploy starts before the submit has completed. In one case, (on Solaris from the cached mount point), it got the attributes of the files (# of bytes) of the OLD version of the file, and started deploying the new version (which was a different size).

Not maybe this is not an issue on DOS or Unix with the non-cached mount point, but it is still enough for me to avoid.

Andy

kaalraa

Hi,

is it NOT a GOOD PRACTICE to deploy files from STAGING (instead deploying from WORKAREA is the BEST PRACTICE)

Could some one explain me why it is so?

Thanks.

If you are using the workflow, with the deployment task after submit task... then you can do that with no hassles. As said earlier, your each deployment would deploy only baselined content.

Adam Stoller

Hi,

is it NOT a GOOD PRACTICE to deploy files from STAGING (instead deploying from WORKAREA is the BEST PRACTICE)

Could some one explain me why it is so?

Thanks.

I would say the opposite - you should generally never deploy from the workarea as that represents non-versioned assets.

What happens is that the deploy starts before the submit has completed. In one case, (on Solaris from the cached mount point), it got the attributes of the files (# of bytes) of the OLD version of the file, and started deploying the new version (which was a different size).

Not maybe this is not an issue on DOS or Unix with the non-cached mount point, but it is still enough for me to avoid.

I believe that your last sentence is correct - I believe this problem does not happen on Windows, nor when using the non-cached mount point on Unix - which I believe you should do.

beez

Staging is subject to change at any time (when any user or WF submits something). This includes *while a deployment is in progress*. If deploying a known set of files/versions matters to you, then deploy from a published Edition.

Adam Stoller

Staging is subject to change at any time (when any user or WF submits something). This includes *while a deployment is in progress*. If deploying a known set of files/versions matters to you, then deploy from a published Edition.

True - though I generally operate under the assumption (perhaps incorrectly) that workflows verify that the files associated with them are not associated with other workflows, and that very few users have direct access to the box, preventing them from running iwsubmit manually - but yes, if those assumptions cannot be verified, using an edition is definitely more stable than staging, and staging (IMO) is more correct than using a workarea ...

kaalraa

Staging is subject to change at any time (when any user or WF submits something). This includes *while a deployment is in progress*. If deploying a known set of files/versions matters to you, then deploy from a published Edition.

Thats the reason, why we always chose to have a conflict result screen before deployment for the approver. The Conflicts script checks for locks and association of the task files to any other job(s).

nipper

Staging is subject to change at any time (when any user or WF submits something). This includes *while a deployment is in progress*. If deploying a known set of files/versions matters to you, then deploy from a published Edition.

I agree with Fish. All of my WFs initially check to see if the file is currently in a workflow and will not allow it to continue.

I also have locks (admin) to prevent changes in process of the WF, so I feel comfortable to deploy from the WA.

Adam Stoller

I agree with Fish. All of my WFs initially check to see if the file is currently in a workflow and will not allow it to continue.

I also have locks (admin) to prevent changes in process of the WF, so I feel comfortable to deploy from the WA.

Are you deploying from the WA before, or after the submit has been processed?

If after, then I guess I can see it as being okay - but I still prefer knowing I deployed from the actual versioned file rather than the workarea....

gzevin

is it NOT a GOOD PRACTICE to deploy files from STAGING (instead deploying from WORKAREA is the BEST PRACTIC

while you got some good answer, I would still ask - WHO told you about the sentence above?

smg

while you got some good answer, I would still ask - WHO told you about the sentence above?

So, you are really interested in knowing who is recommending this:
Interwoven Support Engineer(s). Smiley Tongue

gzevin

So, you are really interested in knowing who is recommending this:
Interwoven Support Engineer(s).

you must be kidding. If I were you, I'd raise this with your account manager. That engineer doesn't either have basic knowledge for his job or the ability to ask the fellow engineers before telling this to a client. or both

Adam Stoller

you must be kidding. If I were you, I'd raise this with your account manager. That engineer doesn't either have basic knowledge for his job or the ability to ask the fellow engineers before telling this to a client. or both

Or someone misunderstood the question asked or answer provided ...

gzevin

Or someone misunderstood the question asked or answer provided ...

I am just based on the presumption of innocence of the asking person. Because it's up to support engineer to nail the question down.