Here’s my scenario: an ASP.NET 4 MVC Web Application with multiple “Areas” that are developed independently (and by different teams FWIW). The current build/deploy process is running for about 2 hours using VSTS Build and RM - and basically a “brute force” copy (and copying a lot of files they don’t need on target server). I’m confident that moving to Octopus will give big gains.
The main ASP.NET Website is called the “Mastersite” which includes the main components and the web.config file “bin” directory, etc. Deploying this is a piece of cake - I’m using the WebPublish task to “FileSystem” which I can package and Octopus deploy as IIS task - so far so good. Note that this application has it’s own VS solution which doesn’t contain the others.
This part is only build and deployed when they make changes, which isn’t too often (and mainly just the web.config file)
My question involves the “Areas” that are built and deployed much more frequently. Currently two in production and a third in development with more in the future.
The folder structure looks like this
\Applications\Mastersite (Physical Path to IIS Website)
\Applications\Mastersite\bin (bin directly - we’ll be discussing this more below)
\Applications\Mastersite\Areas
\Applications\Mastersite\Areas\Application1.WebArea
\Applications\Mastersite\Areas\Application2Area
etc
So - I need to create a build/deploy for Application1 and Application2. Note that each has it’s own solution and is independent from each other and Mastersite.
The tricky part is that each build/deploy in addition to updating (for App1 for example) \Applications\Mastersite\Areas\Application1.WebArea
I also need to send files to \Applications\Mastersite\bin
My initial thought is to create multiple packages versioned the same and have separate deploy steps to different custom install directories. But I’m guessing there is a “better” solution.
I think you are on the right track with how to setup your deployment. As you described, you could have a package for each of the Areas you want to deploy, and a deploy step for each of those areas as well. This means that everytime you run the deployment, every one of those Areas will be re-deployed. If you want to avoid this, you could instead have different projects for each Area, which would allow them to be deployed independently of each other.
The thing that stands out to me with the scenario that you have described is that your “Areas” need to send files to the Mastersite’s “bin” directory. It would be nice if these Areas were truly independent of the Mastersite and could be deployed independently of the Mastersite.
If you were to have a separate project for each Area, consider what would happen when someone makes a change to the Mastersite. The Mastersite would be re-deployed and this would overwrite the contents of the bin directory, and therefore clear any files that have been copied there by previous deployments by the Areas. You would then need to re-deploy the latest version of all of the Areas to get those files back in the bin directory.
This extra coupling between the Mastersite and the Areas introduces more edge cases and makes the deployment process a bit more fragile. It is difficult for me to say any more without understanding a little bit more about why you need to copy those files to the bin directory, but it could be very advantageous for your organization if you are able to remove this requirement.
Hope that was helpful Let me know if you have any more questions
Tom
Sorry to not be clear with my question. The architecture of the application is not in question - the client has put a lot of thought into it, they have a process where what you describe is not an issue for them. They are happy and aren’t going to change it to make deployments easier.
The problem is that the way are doing deployments is very long running, and the basic architecture of Octopus solves that (ie delta compression, synchronous deployment to multiple servers, etc) So I simply need to implement it in the most efficient manner. Part of the problem is the way they were building the solutions and I’ve solved that.
My question is simply how do I use Octopus to deploy the areas with both the Mastersite/Areas/Application1 folder and the Mastersite/bin folder
Do I need to create two separate packages or is there a way I can have a package with 2 folders and have task(s) that can selectively deploy the folders within a package to two different locations.
No problem, I think I understand your problem a little better now.
I think the best way to handle this situation is by creating 2 packages for each area. The first package contains the files for the IIS application and is used by a Deploy to IIS step to deploy the IIS application.
The second package contains the files for the bin directory for that area, and would be used within a regular Deploy Package step. As part of the Deploy Package step, you could configure the Custom Installation Directory to be the path of the Mastersite’s bin folder.
I would recommend this approach because it is the simplest way to setup your deployment, and requires the least amount of configuration.
Alternatively, it is possible to do the deployment with just one package, but it requires a little bit of custom scripting. The structure of this package could be something like this:
/(*All of your IIS application files here in the package root*)
/bin/(*All of the Mastersite's bin directory files here*)
The you could deploy this package using the Deploy to IIS step. You would need to run a custom script to copy the contents of the /bin directory within the deployed package folder to Mastersite’s bin directory. Unfortunately, Octopus won’t do this for you out of the box, so you would need to write this script yourself.
Both of these options are reasonable solutions to your problem, so it is up to you which one suits you best. I hope that clears things up for you
Let me know if you have any more questions