Exclude paths with Azure Web App

Legacy Uncategorised
1

Hi,

Is there anyway to exclude additional directories from the file removal process during install (similar to App_Data)? We have a layered application that is deployed in parts and updated by separate teams.

Component A target /
Component B target /ComponentBPath
Component C target /ComponentCPath

We want to scope the removal process of each component to within specific directories. WebDeploy can do this, but is there a way to pass through the params from Octopus? i.e ComponentA removes files in root, but ignores /ComponentBPath and /ComponentCPath?

Thanks,
Mike

2

Hi Mike,

Currently, no, there is no way to exclude specific directories from deletion.

I could implement this for you. Would specifying a variable in your project (e.g. Octopus.Action.Azure.PreservePaths) work for you?

Regards,
Michael R

3

Hi Michael,

Yes that would be great. A variable sounds good. I’m assuming I’d be able to pass it a delimited list of paths? If I deploy ComponentB to ComponentBPath, I’m assuming it already won’t touch files in the root?

Thanks,
Mike

4

Yeah, exactly.

A question: can deploying ComponentB to ComponentBPath, and selecting the “Remove additional files” option not already give you what you want?

5

Sounds good.

No the issue is if ComponentA is redeployed it removes ComponentB and and ComponentC. I want to deploy ComponentA without removing the other 2.

6

Ahh, because ComponentA is deployed to the root. Of course.

7

Exactly, any idea how long it will take to rollout this functionality? It’s going to massively help us on a very large project.

8

I’m actually looking at it this moment.

I’ll have something ready for you early next week. We generally release every few days.

The implementation I’m leaning towards is allowing you to supply a list of regexes that will be passed straight through to WebDeploy. The regexes will be used to filter files and directories. For example, in your scenario you could set the variable to \\Component.*(\\.*|$)
This would prevent any files or directories in a path beginning with \Component from being deleted. I think this will be the most flexible solution.

Does this sound suitable?

9

Hey Mike,

As of the latest release (3.2.6), you can set a variable: Octopus.Action.Azure.PreservePaths

This should be a ; separated list of regexes that will be used to select directories and files to preserve.
e.g.
\\Component.*(\\.*|$)
will preserve any paths beginning with \Component.

Note: Because of the way the rules work for WebDeploy (which we use to deploy Azure Websites), your pattern must also match any parent directories of the path you wish to preserve. For e.g. if you had
\Components\ComponentA

\Components\ComponentB

and you wanted to preserve ComponentA but not ComponentB, then you would have to set the variable to:
\\Components;\\Components\\ComponentA(\\.*|$)
As this will match the \Components directory, the ComponentsA directory and any files and sub-dirs.

I hope this makes sense. Let me know how it works out for you?

10

Hi seems to work, thanks!

Any chance we can also get this behaviour for tentacle based deployments? Same scenario.

Thanks,
Mike

11

You’re welcome. I’m glad to hear that helped.

Regarding Tentacles, we think there may be a few other options to achieve the outcome you want. I would be interested to hear your thoughts on these:

  • Deploy your components to separate directories (i.e. not sub-directories), and use IIS virtual directories mapped to them. In other words, create your desired structure in IIS, but have the physical directories independent for each component.

  • Rather than having Octopus automatically purge your directories, you could always write your own PowerShell to do it. e.g. You could have a PreDeploy.ps1 script that deleted the contents of your component.

Do you think one (or a combination of) these options might work for you?

Regards,
Michael R

12

Hi,

I’m unable to use Virtual directories in this case. The PowerShell could work but it would be nice to have it handled for me.

One of the challenges is that I want to deploy to Web Apps, but ComponentA needs to run a config transform against a root web.config file. I’m staging the file system on the Octopus server using a Tentacle, and getting Octopus to handle the transforms for me by moving config files between Component locations and copying back. I then plan to synchronise the working directory with Azure Web Apps using MSDeploy directly to another approach to be decided. Do you have a better suggestion for how this could work? I want a solution that can work on both Web Apps and VMs.

Thanks,
Mike

13

Hi Mike,

I apologize, I’ve been on holidays for a few days.

Without completely understanding your situation, it sounds like you’re on the right track. You could deploy all your components (including the root) to the same custom installation directory; this would make it simpler for the components to transform the root web.config. Alternatively copying and transforming will work too.

Regarding deletion, leave Purge unchecked, and add your own PowerShell script step. For the child components, this might be simply:
Remove-Item #{YourComponentPath} -recurse

Then for the root component, you would obviously need to exclude the components; something like the following (warning: not tested):

Get-ChildItem -Path  #{YourRootDirectory} -Recurse  |
Select -ExpandProperty FullName |
Where {$_ -notlike '#{YourRootDirectory}\Component*'} |
sort length -Descending |
Remove-Item -force

And then I suppose you would have a final PowerShell step which invoked WebDeploy to synchronize to Azure?

Is there the possibility of changing your solution so the Components don’t need to modify the root web.config. Some sort of dynamic discovery?

I hope this helps.