Workflow w 2 serial deployments

>1. deploy files to an external QA web site.
>2. send email to reviewers
>3. reviewers approve the job (within TeamSite)
>4. deploy files to external production web site.
>
>What is the best approach for building the workflow?
Get training or someone who knows what they are doing.

>Is it possible to trigger multiple deployments from a single workflow

Yes, this is trivial

Seriously, what you are looking for is straightforward, actually fairly easy. Would take a
competent WF person 2 days maybe to complete.

By your questions, it certainly appears you do not know much about WF, maybe TS in general.
So get a decent consultant if you want it done quick. Get to some training.

I am curious why you need the first deployment ? With TS proxy you can often (not always)
avoid that step.

Questions like that are why you bring in someone who knows what they are doing.

Andy

Maybe it would take you 2 days since you're a competant WF contractor. But to a lowly competent salaried WF person like me, it would take about an hour. Keep those billable hours to their maximum. A well trained contractor always does.

Smiley Happy

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

>Maybe it would take you 2 days since you're a competant WF contractor. But to a lowly competent salaried WF person like me,
>it would take about an hour. Keep those billable hours to their maximum. A well trained contractor always does.

& your point is that it is good to be a contractor ?

Yes this can easily be done in an hour, but I suspect other questions will come up that can easily use more time. Here
it took almost a day to get the IT dept to get the email settings correct.

me

You must have the 3rd Edition of O'Reilly's Contracting in a Nutshell. Blaming the network folks for not getting the email addresses right - that's in Chapter 2. Cranking up the OT to build a workflow you could have written in 30 minutes. Covered in Chapter 7.

Seriously, when I was a contractor I loved it - the money was worth anything negative. Until the dot com crash and jobs went away. That was no fun. If I didn't work in Utopia, I would probably become a contractor again.

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

Despite my expertise (I believe I can say that - yes?) with workflows - I don't like estimating less than a week for a workflow. Not because the original description is so difficult (yes, on face value it could probably be done in less than a day), but because you almost always run into something where the customer decides they want something done differently or "better", or feature-creep occurs.

The thing that gets underestimated the most is not the WFT, but the externaltask and (more often) the cgitask scripts that go to support it - whether this occurs because of requiring 3rd-party assistance or simply because the code turns out to be more complext than originally thought, or even because a small typo or logic error manages to find its way into the code - is irrelevant - the fact is: **it happens.

I'd rather estimate a week and be done in a day, then estimate a day and be done in a week ...

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

>I don't like estimating less than a week for a workflow.

Spoken like a true consultant. :-)

No - spoken like a consultant who's been burned by having someone else estimate less time than was required far too often. (like by sales people who think everything they say is true ;-)

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

Unless the workflow is massive, if it takes 2 weeks to write a workflow given all the requirements, something is pretty weird. Other than my monster nested workflow, no workflow has taken more than a couple days to write. Maybe were just too simplistic up here in o-ray-gon.

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

Actually Smitty there is this concept of error checking.

and testing

& padding

opps.

Funny how this thread has digressed.

me

My code is self sufficient. By default it works correctly, whatever it does. If I wanted error checking, I'd have them hire a stinkin' contractor. Sheesh.

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

I'm not sure I really need to "defend" myself here, but heck - if Smitty can pad his post count with frivilous fluff, I can spare a few cycles to add some reasonable content to this clearly diverged thread.

I guess it all depends on how you look at things.
When someone tells me they want a workflow I consider the following:

Information gathering - to make sure the proposed process is what they really want implemented
Development of the WFT
Development of associated externaltask scripts
Development of associated cgitask scripts
Documenting the design and implementation

Depending on the depth of what the customer wants and the level of the people who are going to be responsible for maintaining it after its developed ... well that could me a lot more effort spent on coding and documentation.

If all you want is a workflow knocked out to do something very simple, like tweaking one of the OOTB workflows - hey no problem - a couple of hours.

But in my experience, people who start out with that decision usually don't know what they want, and when they figure out what they really want, you're talking about a 20-30 task workflow with several complex cgitasks, error handling, etc. - and if you started off with an estimate of 1-2 days you're going to feel really foolish when you figure out exactly how much work you actually have to do....

Hence, my feeling that you should never estimate less than a week per workflow - until you have sufficient detail to figure out a more realistic estimate. This is regardless of whether I would be doing this as a consultant or a full-time employee.

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

iwovGraduate

While I have no doubts about Smitty77's competence, I really doubt if anyone can really deliver a working solution within an hour given the original post.

To me the original post is a mix of vague, incomplete requirements and design. It may take you much more than an hour just to get answers to some unknowns here : Who are the reviewers ? how many ? who selects them ? when ? etc., etc.

In the ideal world, you have answers to all the questions you may have, and hopefully you can start from something OOTB and get it working very quickly. How often does that happen ? In my experience you often spend more time getting the right requirements then actually coding/testing a workflow.

Couldn't resist to add my $0.02 to this diverged thread

jbyork

2-3 days to determine, document, and get customer sign-off of component requirements.
1 week to document design and perform design review
1+ weeks to develop (estimate increases depending on number and complexity of scripts)
1 week for unit testing, system testing, and integration testing.
1-2 days for UAT and customer sign-off

Depending on the methodology you're using, and required documentation, the time may increase based on number of work products you have to produce.

You've got to be kidding me. You must be a contractor. One week to test this trivial workflow?

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

gotta love being paid by the hour.

Now I do think this WF is a couple day work (to implement and unit test). UAT & other testing
depends on the corporation.

Andy

http://www.quotient-inc.com

From the original description:

I guess I'm just looking at this problem with blinders on. I'm thinking if someone from my company requested this workflow - it would be so simple because the workflow itself already exists, it would just be a matter of changing the usernames. The points you bring up are well taken. And yes I spent a fair amount of time customizing emails so that a user didn't have to log into TeamSite to act on a successor event. If I was brand new and didn't have a clue, it would probably take months. I concede that it could indeed take significantly longer if things weren't set up yet (like OpenDeploy). I am making assumptions that everything is all set. But still, a friggin' week to test the thing? You have to admit that testing would be rather simple.

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

>I guess I'm just looking at this problem with blinders on. I'm thinking if someone from my company requested this workflow - it would be so simple
>because the workflow itself already exists, it would just be a matter of changing the usernames. The points you bring up are well taken. And
>yes I spent a fair amount of time customizing emails so that a user didn't have to log into TeamSite to act on a successor event. If I was brand
>new and didn't have a clue, it would probably take months. I concede that it could indeed take significantly longer if things weren't set up
>yet (like OpenDeploy). I am making assumptions that everything is all set. But still, a friggin' week to test the thing? You have to admit
>that testing would be rather simple.

So the month that was quoted by another user I thought excessive.

The point is that there are many variables that need to be known. Even my 2 day guess assumed that the deployments were already defined,
that I could set a group (unix/nt) for approvers (as well as an alias for email) and that this is an existing installation where the majority of the
TS functionality works and is tested (email, OpenDeploy, etc).

BTW, who thinks we've scared away the original poster ?

Andy

Testing time varies with complexity - the more ways you have for doing something, and/or for breaking something - the more ways you need to test it. If it takes a fair amount of time to set up the scenarios for testing, then it will take longer to test. Also - if you assume that everything will work right the first time then yes, a week for testing seems a long time. However, if you assume that it is possible to find a problem during testing, and that the fix for that problem may take a bit of time, and that all testing should be re-done when the fix is put into place ... a week (or more!) may be required.

I'm really *not* trying to pad figures here purely for consulting greed (or whatever you'd want to call it) - I'm trying to show how basing estimates off incomplete information can lead to significant under-estimating and that, as I said before, I would not want to commit to any workflow design without estimating *at least* a week of work.

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

BTW, who thinks we've scared away the original poster ?

Hmm - GLeon - you still around?

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

Yes, I gave it a couple of days to simmer since my initial reaction I could not put in words.

I realize that I did not provide enough specifics so forgive me for that.

We had a consultant (lets not go there) come in about a year ago and set up a couple of workflows for us. I have not had workflow training and my background is in ColdFusion but I've reviewed the Advance Workflow Development manual. Since we have a working model I figured it should not be a big deal to add some steps to it.

Sooo, the existing workflow does the following:

1. Sends email to reviewers (hard-coded list in WF)
2. After approval, files are deployed. here is the external task in the WF:

<externaltask name="Deployment"
owner="__TAG__('iw_user');"
description="Initiating Deployment to Deploy files.">
<areavpath v = "__INSERT__($cArea_VPath);"/>
<successors>
<successorset description="onDeploySuccess">
<succ v="EndTask"/>
</successorset>
<successorset description="onDeployError">
<succ v="NotifyDeploymentError"/>
</successorset>
</successors>
__INSERT__("<command v='$iwhome/iw-perl/bin/iwperl $iwhome/custom/NY/wft_opendeploy.ipl' />");
<activation>
<or>
<pred v="Submit" />
<pred v="ErrorInDeployment" />
</or>
</activation>
</externaltask>

The wft_opendeploy.ipl script reads in a configuration file; sets up the parameters and runs the opendeploy command:
my $deploy_cmd = "$OD_DIR/bin/iwodstart wft_opendeploy -k area=$workarea -k filelist=$filelist ";
$deploy_cmd .= "-k useNode=$useNode -k targetArea=$targetArea -inst $taskid ";

Aside from any efficiency points (and calling in another consultant) what would be the approach to add in another review and deploy steps?

I tried essentially just duplicating the externa task (along with the wft_opendeploy.ipl script) with a different name but it always ends up in the deployment step and stays there.

And yes, I am looking into getting training in WF and Perl in general.

JonathonG

When you say "it always ends up in the deployment step and stays there." What do you mean? Does the workflow end before your new externaltask gets executed? That would be my guess. If so, it's because you haven't change the successorset for the existing externaltask (its currently pointing to the end task on success). If not, what do you mean? If possible, post (as an attachment) your new version of the wft and someone (maybe me) may be able to look at it and give you a couple of pointers.

Jonathon
Independent Interwoven Contractor

>I tried essentially just duplicating the externa task (along with the wft_opendeploy.ipl script) with a different name but it always ends up in the deployment >step and stays there.

Are you certain your perl script is running ?

Are you catching any log files ?

Just for kicks, run the new perl script from the command line

You should get an error something like:

Task 0 does not exist.
ERROR:00920: Object being looked up was not found

Obviously your script is not terminating properly, I wonder if it is starting at all

Andy