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

how can I publish a specific file version to production?

BigMelvin

In workflow, how can I publish a file to production using a specific version of a file, rather than always publishing the latest version from STAGING?

Here is the scenario:

1. fileA is modified and attached to workflow job#1.
2. fileA version 1 is versioned in STAGING.
3. fileA is modified and attached to workflow job#2.
4. fileA version 2 is versioned in STAGING.

When workflow job#1 is published to production, now both fileA version 1 and 2 show up in production, while workflow job#2 remains in testing.

What I want to do is, when workflow job#1 gets published to production, I only want it to publish fileA version 1.

Any ideas would be helpful. Thanks.

If it helps, I'm using:
TeamSite version: 6.5.0 Service Pack 2
Platform: Unix

Find more posts tagged with

Comments

RajatChopra

At what stage are you deploying these to PRODUCTION??

I assume that Production is a web server somewhere. Are you using OpenDeploy to deploy these files to it?

How come you have both versions in Production? If you deploy from STAGING you should have only one version in Production...

BigMelvin

Thanks for your reply. Yes, I'm using OpenDeploy to publish files to production. And yes, when I refer to "production", I refer to a web server that is visible to the public.

After a file is versioned in STAGING, I have several other testing environments I deploy to, before a wf job is deployed to production. Something like this:

Dev -> STAGING -> TestEnv1 -> TestEnv2 -> TestEnv3 -> Production.

RajatChopra

Dev -> STAGING -> TestEnv1 -> TestEnv2 -> TestEnv3 -> Production.

Melvin,
I'm assuming that the trigger for the workflow to proceed from one environment to the next is a User Task.

If that is the case, then you can have OD deploy only those files that are attached to the workflow JOB using filelist deployments

That way, you can retain different versions across the environment depending on how far the workflow has progressed...

If in case this is not through user tasks, then you'll probably have to elaborate your development a bit more. Such as:

1. How is the workflow configured to deploy to the various environments?
2. Are you using independent OD scripts per environment or is this a farm replication?

Adam Stoller

Thanks for your reply. Yes, I'm using OpenDeploy to publish files to production. And yes, when I refer to "production", I refer to a web server that is visible to the public.

After a file is versioned in STAGING, I have several other testing environments I deploy to, before a wf job is deployed to production. Something like this:

Dev -> STAGING -> TestEnv1 -> TestEnv2 -> TestEnv3 -> Production.

There is one school of thought that says that any given file should only be allowed to be associated with one workflow at a time and that if a second workflow is initiated with a file that is already part of a pre-existing workflow, some error should be indicated and the job either cancelled or the file removed from the second job.

If you follow that school of thought, then you should never end up with the problem you are experiencing - if version 2 of the file is more correct than version 1 - you would need to edit the job that version 1 is attached to and remove it from there so that a new job could be launched with version 2.

Another alternative is to use editions - when your workflow submits the files to staging, cut an edition and store the edition name in a job variable - when it comes time to perform the deployment - do so from the edition rather than from staging.

Another alternative is to use sub-branches and to "promote" files to sub-branches as they pass the various testing stages, and then to perform your deployments from the sub-branch instead of the initial branch.

There are probably a few other alternatives as well - but the above are probably the main three.

BigMelvin

Rajat,

Yes, the trigger for the workflow to proceed from one environment to the next is a User Task. I already have OD deploying only those files that are attached to the workflow JOB using filelist deployments. But now the challenge is getting the proper version of those files deployed.

fish,

Those are great ideas. Question regarding thought #2 about creating an edition for each job that is submitted to STAGING. How much of a resource hog would that be, if any? We sometimes have up to 40 jobs created a day.

Thanks for your thoughts.

Adam Stoller

Rajat,

Yes, the trigger for the workflow to proceed from one environment to the next is a User Task. I already have OD deploying only those files that are attached to the workflow JOB using filelist deployments. But now the challenge is getting the proper version of those files deployed.

fish,

Those are great ideas. Question regarding thought #2 about creating an edition for each job that is submitted to STAGING. How much of a resource hog would that be, if any? We sometimes have up to 40 jobs created a day.

Thanks for your thoughts.

There's a small amount of overhead per edition in all supported versions of TeamSite (older versions [pre-5.5.2] had more overhead per edition) - if you go that route, you'll probably also want to think about setting up some form of edition expiration / archiving mechanism.

RajatChopra

There is one school of thought that says that any given file should only be allowed to be associated with one workflow at a time and that if a second workflow is initiated with a file that is already part of a pre-existing workflow, some error should be indicated and the job either cancelled or the file removed from the second job.

Adam,
What exactly are the drawbacks if multiple jobs have the same file?
If they are all run sequentially (ideal scenario), one would assume that the code in different environments can have different versions.

Doesn't the workflow retain the right file version?
Just wanted to inquire about the school of thought.

-Rajat

nipper

Adam,
What exactly are the drawbacks if multiple jobs have the same file?

Don't call me Adam.

:-)

see below

If they are all run sequentially (ideal scenario), one would assume that the code in different environments can have different versions.

Doesn't the workflow retain the right file version?
Just wanted to inquire about the school of thought.

-Rajat

The answer is that it all depends.

If you have 3 workflows from the same workarea and the same branch, then, unless you have done some serious coding, each WF will have the same version.

That is (among other reasons) why you do not allow the same file in multiple workflows.

Even if you use different workareas, then you will have some serious merge issues once one goes to the Staging area.

Adam Stoller

Adam,
What exactly are the drawbacks if multiple jobs have the same file?
If they are all run sequentially (ideal scenario), one would assume that the code in different environments can have different versions.

Doesn't the workflow retain the right file version?
Just wanted to inquire about the school of thought.

-Rajat

Workflows operate within a workarea on a branch.
If you're using a shared workarea and you attach user1's version of file1 to the job, and then user2 makes additional changes to file1 within the same workarea and adds that to a new job - then both jobs will be referencing the exact same file (user2's mods) and the version without user2's mods is gone.

If you deploy from staging, but you have an extended process that goes on beyond the submitting of the files to the staging area - then (using the same scenario as above) user2's submission will overwrite user1's version in staging and although the first deployment of user1's work to the first testing server will work it is likely that the next deployment (either to another testing environment or to the production environment) will then be user2's and not user1's - even though user2's work might not yet have been fully validated in the initial testing environment.

If you're using different workareas on the same branch, then prior to submission each version of the file is maintained separately, but you generally should not deploy files from workareas - so you're once again faced with the issue of potentially deploying a version of a file that was not the version originally associated with the particular job.

Since editions are unique snapshots in time, the version in the edition will never change and thus if you deployed the version from that edition to one environment it doesn't matter how long it takes before it gets deployed to the next environment - it will be the same file. This, however, brings in another tricky aspect of allowing the same file to be associated with multiple jobs at the same time... If version-1 of file1 is submitted and then proceeds to the next testing stage, and then version-2 of file1 is submitted and also proceeds to the next testing stage ... if, for some reason, the second job (with version-2) is approved / verified before the first job - then you will potentially succeed in deploying version-2 first, and then version-1 over version-2 - thus negating the later changes. You could probably avoid this by only deploying newer files (dateDifferent="no") but it's still a somewhat risky and confusing issue.

If you make sure that you do not have the same file attached to more than one active job at any one time - then you don't have this problem. If you try to attach a file to a job and it errors out because the file is already part of another job - then it makes sense to find out why the earlier version hasn't made its way out yet and whether it should, or whether it should now be rejected in favor of the newer version ...

It comes down to each organization's process requirements.

RajatChopra

Workflows operate within a workarea on a branch.
If you're using a shared workarea and you attach user1's version of file1 to the job, and then user2 makes additional changes to file1 within the same workarea and adds that to a new job - then both jobs will be referencing the exact same file (user2's mods) and the version without user2's mods is gone.

If you deploy from staging, but you have an extended process that goes on beyond the submitting of the files to the staging area - then (using the same scenario as above) user2's submission will overwrite user1's version in staging and although the first deployment of user1's work to the first testing server will work it is likely that the next deployment (either to another testing environment or to the production environment) will then be user2's and not user1's - even though user2's work might not yet have been fully validated in the initial testing environment.

If you're using different workareas on the same branch, then prior to submission each version of the file is maintained separately, but you generally should not deploy files from workareas - so you're once again faced with the issue of potentially deploying a version of a file that was not the version originally associated with the particular job.

Since editions are unique snapshots in time, the version in the edition will never change and thus if you deployed the version from that edition to one environment it doesn't matter how long it takes before it gets deployed to the next environment - it will be the same file. This, however, brings in another tricky aspect of allowing the same file to be associated with multiple jobs at the same time... If version-1 of file1 is submitted and then proceeds to the next testing stage, and then version-2 of file1 is submitted and also proceeds to the next testing stage ... if, for some reason, the second job (with version-2) is approved / verified before the first job - then you will potentially succeed in deploying version-2 first, and then version-1 over version-2 - thus negating the later changes. You could probably avoid this by only deploying newer files (dateDifferent="no") but it's still a somewhat risky and confusing issue.

If you make sure that you do not have the same file attached to more than one active job at any one time - then you don't have this problem. If you try to attach a file to a job and it errors out because the file is already part of another job - then it makes sense to find out why the earlier version hasn't made its way out yet and whether it should, or whether it should now be rejected in favor of the newer version ...

It comes down to each organization's process requirements.

AWESOME!!
Thanks (And I really mean it),
Rajat

SethHickel

My users want to use time deploy to depoy specific editions. They often have multiple versions of the same file(s) in process at the same time, , something like multiple versions of a home page, that they want to time deploy over a series of days.

I read the following suggestion from this thread:

"another alternative is to use editions - when your workflow submits the files to staging, cut an edition and store the edition name in a job variable - when it comes time to perform the deployment - do so from the edition rather than from staging."

Can someone provide guidance on how to capture and store this value so that I can allow my users to time deploy a spefic edition? I'm having difficulty finding help on that task.

We currently deploy the latest version. Our workflow submits to staging and builds the edition.

Thank you.

Adam Stoller

[...]
I read the following suggestion from this thread:

"another alternative is to use editions - when your workflow submits the files to staging, cut an edition and store the edition name in a job variable - when it comes time to perform the deployment - do so from the edition rather than from staging."

Can someone provide guidance on how to capture and store this value so that I can allow my users to time deploy a spefic edition? I'm having difficulty finding help on that task.

If your workflow process creates a named edition - then you can store that named value in a job variable and then retrieve it later (in the same job) when you're ready to perform the deployment.

If your workflow process creates a generated-named edition - then you can either use the iwnexted CLT before, or the iwlasted CLT after, to retrieve the name of the edition and put that into a job variable which can be used later to perform the deployment.

Note: I don't necessarily advocate either of these solutions as there may be a number of variables involved that might make this a less-then-desirable solution in the long run. There's no "one right answer" - you have to design your solution based on actual requirements.