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

Synchronized Deployment N'Run

System

I have a rather complex deployment definition I'm trying to hash out. I have the scripts that I need to run before and after a deployment working well. However I need to also deploy these files before and after the main deployment.

Script 1) de-register and shut down and COM+ applicaiton
Script 2) install new DLL and start COM+ application

So what I have is 4 definitions

1 - the content - this is fine it just needs to go before the component update

2 - the script that de-registers the COM+ application so that step 3 can succeed

3 - the DLLs

4 - the script that registers the new DLL(s)

Now, I thought about just having 1 and 3 and then doing something within 3's DNR ... the scripts could be deployed with 3, but I couldn't figure out how to ensure that script 1 was deployed and ran, then the DLL(s) where deployed then script 2 is deployed and run ...

So I broke it up into 3, however I think each definition is executed asynchronously.

Is there a better way to do this? Is it possible to have a chained deployment in one definition file?

Thanks,
Adam

Find more posts tagged with

Comments

Migrateduser

If you have multiple definitions being executed from multiple execDeploymentTask elements, these will all run in parallel.

You can serialize the delivery of content using a single definition and a multiple sub-source structure. (There's an example on p. 137 of the OD 5.6 Admin Guide, Nov 2003 edition.)

You can serialize DNR scripts by specifying the trigger points for launching. P. 176 of the Admin Guide has a diagram that illustrates the various trigger points that are available.

Hope that helps,
Todd

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Migrateduser

ok, almost there

now I want those files deployed if changes are made or missing obviously ...

but... now with the triggering issue ... here they are:

{execDeploymentTask useDefinition="com_plus"}
{deployNRun }
{dnrFile location="target" when="after" state="always" mask="darts_pre_install.vbs" }
{script cmd="C:\WINNT\System32\cscript.exe C:\WINNT\System32\darts_pre_install.vbs" as="" where="" async="no"/}
{/dnrFile}

{dnrFile location="target" when="after" state="always" mask="darts_install.vbs" }
{script cmd="C:\WINNT\System32\cscript.exe C:\WINNT\System32\darts_install.vbs" as="" where="" async="no"/}
{/dnrFile}
{/deployNRun}
{/execDeploymentTask}

what if the files haven't been changed and aren't deployed? I need these to run no matter what ... is there a way i can use a file list that just includes the file names ... i don't wnat to have to create this file list ... something like a cat command ... or even echo ... i'm running solaris 8 ... going to win2k ...

Migrateduser

dnrFile fires for each file being deployed and is not supported for transactional deployments.

You may want to consider using dnrDeploymentJob and/or dnrDeployment instead.

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Migrateduser

but do you get what I'm trying to do?

I have installation scripts that must be run prior to the actual product being deployed and installation scripts that must be run after the actual product is deployed.

the installation scripts must be part of the deployment.

I was think of using a file list like "echo darts_pre_install.vbs" but since you are using Java it is looking for an absolute path and the API doesn't interpret streams.

I tried using a before connection and after disconnect to create the files and clean them up after the deployment is complete. However, the file list attribute expects the file to exist before beginning.

If no one can figure a way around this I will have to file a feature request and make two deployments - one for the content and installation scripts and one for the actual COM+ application.

One more note, using the same idea with creating the file list before and cleaning up after I was thinking of doing a "touch" on the files on the source server... I couldn't do an "iwupdate" afterwards because the file might not exist or might be changed in the source.

If the include path filter had an ALWAYS DEPLOY attribute that would be really nice.

Any other thoughts?

Adam Stoller

Instead of using dnrFile - use dnrDeployment - and it will run regardless of whether those particular files were deployed - and it will only run once for the deployment.

<execDeploymentTask useDefinition="com_plus">
    <deployNRun>
        <dnrDeployment location="target" when="after" state="always">
            <script cmd="..." async="no"/>
        </dnrDeployment>
    </deployNRun>
</execDeploymentTask>

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

Adam Stoller

I seem to recall that the dnrFile (and dnrDir) do *not* provide the path/name of the file (or dir) that triggered the DNR to the script. I think there might be a feature request open on this (Todd?)

IFF the dnrFile did that, you could do something like:

    <dnrFile ...>
        <script cmd="... %s" .../>
    </dnrFile>

That would, IMO, be a nice way to handle cases like this. You could then have a dnrFile fire before and after the file was deployed and have the script "do the right thing" for just that file.

As it stands now, my previous post pretty much covers it - you'd have to have a dnrDeployment that fires off before to do whatever you need to do before the assets are deployed, and another dnrDeployment that fires off after to do whatever you need to do after the assets have been deployed.

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

Migrateduser

Did you forget, I need to deploy the scripts I am going to run before they are run ... what if they don't exist on the system yet or I made a change to them ...

The reason that one needs to run before the main deployment chunk of the COM+ dll's is that if the dll's are in use I won't be able to overwrite them ... so the first script stops the COM+ application and removes the components then the components get deployed, the second script it deployed and run which installs the components from the new dll's ...

Its like a remote installation ... I sometimes do this to stop IIS services in a high isolated web app so that it shuts down and I can overwrite some of the COM+ components it uses and then start them back up and away you go ...

You're supposed to be able to overwrite COM+ dll's while they are in use but in some cases this doesn't work as expected ... thus the need for the two scripts ...

I am asking if there is a way to FORCE a file or files to deploy without the use of a filelist ... or at least accept a dynamiclly generated file list ... what about a parameter replacement file ... i think i read about that but not too sure ... dynamically generate the file list and the parameter replacement file then clean them up after the deployment ...

You would think the OD definition would be more scriptable ... considering what you can do with wft files ...

Umlaut Test.pdf

Adam Stoller

In order to deploy specific files - you need to provide a filelist.
The filelist can be dynamically generated (within a wrapper script / workflow externaltask, etc.) and provided as a parameter to the deployment via the '-k' option (where the name of the filelist, within the configuration file is specified as a variable, e.g. "$filelist^"). In your case however, you might be able to hard-code a filelist for the scripts to be sent over...

If you need to make sure the script is deployed first - then you probably want to have two (or more) pathSpecification (or sourcexxx) elements within your definition - as I believe those directives run sequentially, while execDeploymentTasks run concurrently.

The only way to FORCE a file to deploy is with a filelist - otherwise it will only deploy if different (newer, by default).

I'm not sure why you think "OD definitions would be more scritable considering what you can do with wft files" - they're two different products developed for two different functionalities by two different sets of engineers ...

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

Migrateduser

It would just be nicer if it was a little more flexible ... hard coding everything and relying on parameter replacement is ok but it only gets you so far ...

I don't want to have to maintain 3 files for 1 deployment ... (the definition, the two file lists) ... If I could have PERL script inside a DNR that would rock. Before deployment I would generate the script and after I would clean them up...

Also being able to specify a set of files to ALWAYS deploy without a file list would be even more helpful in this case.

It's nice for deploying content, but we are taking it to the next level for application deployments ...

Adam Stoller

I believe the idea of being able to deploy specific files without a filelist has already been mentioned several times in this forum - I don't recall whether or not a feature request was created for it though (you can probably check with Interwoven Support).

The ability to use arbitrary scripting that takes place within the deployment configuration file and dynamically alters what the deployment does is ... well ... kind of a neat idea - but I'm not sure whether this falls into any of the current plans for OD - again, you might want to contact Interwoven Support and register for this as a product enhancement....

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

Last Line not blank.txt

Blank_last_Line.txt

Adam Stoller

Although not OOTB - one of the biggest projects I ever did with OpenDeploy involved writing a Perl wrapper to OpenDeploy that took care of handling a bunch of things that weren't avaiable OOTB -- it's not "nice-and-integrated", but it is a work-around for providing specific custom functionality.

In your case - you could have a script that generates the filelists, performs the deployment, the content distribution, and then generates another deployment to run the closing DNR - or something like that (I'm not entirely clear on the specific details of what you're trying to accomplish - nor do I, personally, have time to get that involved - I'm just suggesting ways that I think might achieve what I think you're looking to do)

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