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

Consolidating deployment files within one workflow

eddie1

Consider the following ...

There is a simple workflow the following tasks in sequence:
1) Editor approval
2) Deployment Approval
3) External Deploy Task
4) End

consider File 1 from WorkArea A has been submitted thru this WorkFlow.After the 'Editor approval ' it is waiting for the 'Deployment Approval' before it gets deployed by the ExternalTask.

Meanwhile .... consider File 2 from WorkArea B has been submitted thru this WorkFlow.After the 'Editor approval ' it is waiting for the 'Deployment Approval' before it gets deployed by the ExternalTask.

Now at this stage we have the following tasks assigned to the Deployment Approver:

Task with File 1 from WorkArea A
Task with File 2 from WorkArea B

My question is that is there a way by which i can consolidate these 2 files in a single task ... so that the deployment approver has to initiate the deployment only once ?

Please note that i want files from DIFFERENT workareas to be consolidated.

Find more posts tagged with

Comments

Migrateduser

The short answer -- I believe -- is no.

However, you might come up with a scheme where a submit workflow gets an editor approval and then (conditionally) kicks off another job to have someone approve changes and run a deployment, but if there is already a deployment job awaiting approval the submit job would just add the additional files.

However, ask yourself this question: "If there is a 'Deployment Approval' task, does that mean that someone will have an option to not deploy files?" If the answer is "yes", when you merge the changes from two workareas into one approval task, you may lose the ability to reject one set of changes and not the other.

Brinko Kobrin
Interwoven Staff Engineer

log1.txt

Migrateduser

You might consider changing your design so that after editor approval the file(s) are copied (via an updatetask) to a holding workarea. Then, maybe on a timed basis, a different workflow is started that uses iwcmp to generate a list of the files in the holding WA that are different than the STAGING area, attach these files to the WF, send them to the deployment approver, who can use a usertask to remove files that he doesn't want to deploy (or can cancel altogether). The ones he selects for deployment get submitted, an edition is cut, and then that new edition is used as the source area for the deployment.

The passed-over files in the deploy-ready "hold" WA can stay there, modified, indefinitely, and would continue to be part of each new deployment approval job until deployed or deleted.

bw

Bob Walden [bob.walden@interwoven.com]
Interwoven Education Group
IM: Yahoo, MSN bob_walden

eddie1

Yes i was also considering that this might be a solution but there were 2 doubts in my mind:

1) This will still confine the "Deployment Approval" task to have only files from a single workarea -- where as i want that files from different workareas once submitted for deployment can be " Batch Deployed ".

2) How can i figure out if theres another "Deployment Approval" task is active and waiting ? and to add files to it i will have to know the taskID of the "Deployment Approval" task .. i wasnt able to find any CLTs for this .... any ideas ?

And no, the Deployment Approver does not have the ability to reject any files, he only has to initiate deployment.

Thanks !

eddie1

Yes this was also a solution that i had in mind, but are some issues in this as well ...

1) The "Deployment Approval" task will deploy the files into a Pre-Production enviroment where UAT testing will happen. So after deployment another task will be activated which is the 'UAT Approval' task. Now if the UAT testers approve the new changes, only then the modified files are submitted into the staging area of the branch. After submission into staging, an edition is cut which is then deployed onto the final Production Server & another DR ( Disaster Recovery ) Server. So i cannot submit the files to staging during the "Deployment Approval" task becuase if i do that and UAT fails theres no way to rollback the staging area.

Which means that i would need a separate branch for the 'hold' WA so i can use its staging area to do the Pre-Production deployment ( Deployment Approval task ) without using the staging area of the main branch. Am i right ?

2) You said that i can have a separate WF initiated to do the Deployment. Is there a way by which the WF, after submitting the files to staging can detect if there is already 'Deployment Approval' task ( which maybe part of a previous job ) waiting so in that case the WF would just end instead of creating another 'Deployment Approval' Task ? If this can be achieved, then the whole process can be put into a single WF.

Thanks !

Migrateduser

Well, as you know deployed files come from the STAGING area rather that from Workareas, so if your workflows do the following:

->Select Files->Approve->Submit

You could have a special menu only available to your "Deployment approval" that will deploy anything that is found on staging. On the other hand, if you still want to inform him that there are new files to deploy, just add an external task that will send him a mail... he will only then have to decide when he has enough new files to make a deployment worthwhile. Not everything must be on a workflow I believe...

Migrateduser

You can deploy from any area - doesn't have to be from STAGING.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com