Troubleshooting series of workflows

I'm trying to troubleshoot an existing series of workflows that a colleague created. He has one workflow that moves a series of files from one workarea to another upon "submit" This new workarea acts like a "UAT" where a developer can test the files to make sure they are working correctly. A second workflow was created to move the files into Staging (either Deve, QA or Prod).

The problem is that when the second workflow is initiated the files are not moving, and the user is getting an error that the files are locked. THis second workflow should bypass the files that are in "UAT" workarea and move from workarea 1 to Staging.

Any ideas on why this is not working are greatly appreciated.

Find more posts tagged with

Comments

nipper

Unfortunately without seeing the code and seeing it run on the system, that will be next to impossible.

There are several moving parts in this equation: multiple workflows, external tasks that run perl scripts, those invoke deployments or copies to different branches or servers. Plus you have data, permissions, groups and users.

The error is probably in one of those. :-)

Your best bet is to get someone who really knows TS on site and start debugging. If you have some guts, you can start by putting logging information into the perl tasks to see if you can narrow down what happens when it fails.

Andy

dgordon

Andy,

Thanks for your post. Unfortunately we don't have a TS expert on site and I've been given the task to troubleshoot.

Is it possible to write the workflow so that the files moved to Staging actually come from the workarea in Step 1 rather than the "UAT" workarea (step 2)? I haven't been able to determine yet whether that is how the 2d workflow was created. The original developer didn't leave any documentation behind when he left the company.

nipper

First we need to be certain we are talking about the same things. When you mention moving files, do you have multiple branches and it truly copies/deploys files from one branch or server to another ?

TeamSite has a Staging area which is populated when someone submits changes. You can have another workarea do a get latest (or updatetask) in the workflow which moves the changes down.

This solution is dependent on the architecture of the implementation. Workflows cover one branch only, so if you are working with other branches, then multiple workflows are needed. I have seen implementations like that before, but typically it is more complex than is required. Developers who come from a traditional SCM world and want to implement a waterfall model do that, but very often it is unnecessary.

dgordon

Thanks for your patience!

We have one branch 'ClientX' which has several branches inside it. One of those branches "projectX" has several workareas "developer1" "developer2" and "UAT". The way this workflow was initially designed was to move files from "developer1" to "UAT" upon submit. "UAT" is used as a sort of QA workarea. When developer1 is satisfied that the files are working correctly, she will submit the files to Staging and select whether the files should be deployed to Dev QA or Prod environments.

The .wft has the following code:
submittask owner="__TAG__('iw_user');"
name="Submit changes"
unlock="__TAG__('iw_keeplocks');"
savecomments="t"
start="f"
override="__TAG__('iw_override');"
areavpath v="__TAG__('iw_workarea');"/
successorset
/successorset

variables
variable key="submit_cmt" value="__INSERT__($submit_cmt);"/
__INSERT__($info_tag);
/variables
/submittask

I'm not clear on what the "unlock="__TAG__('iw_keeplocks');"" is doing. From what I understand, when developer1 submits the files from developer1 workarea to UAT, the files get locked in developer1 workarea. WHen she tries to invoke a second workflow to move the files to Staging, TeamSite tells her there is a conflict and that the files are locked.

Should she invoke the second workflow from "UAT" workarea or "developer1" workarea?

Is the 'iw_keeplocks' code causing the 2d workflow from being successful?

nipper

Thanks for your patience!

We have one branch 'ClientX' which has several branches inside it. One of those branches "projectX" has several workareas "developer1" "developer2" and "UAT". The way this workflow was initially designed was to move files from "developer1" to "UAT" upon submit. "UAT" is used as a sort of QA workarea. When developer1 is satisfied that the files are working correctly, she will submit the files to Staging and select whether the files should be deployed to Dev QA or Prod environments.

A few comments, first this is a very bad design. Copy/moving files between workareas in the same branch is a very bad practice. You can make it work and it sounds like it worked for a while. However there is a strong likelihood of things getting out of sync. Badly. The least of which are locks.

How many developer workareas are there ? You list 2, there is no way you need this level of complexity for 2 developer workareas.

To answer your other questions, there should be a check box (or radio button) on the start of the WF for Keep Locks and Override conflicts. Those are the variable in the submit task.

I would strongly suggest major simplification, use a typical workflow with submits and update tasks. Use the staging area as a UAT. Push the changes out with an edition to the Prod environment.

Andy