Azure DevOps deploy Angular app to IIS with Octopus

I’m trying to deploy a Angular application to my IIS server using Octopus and Azure DevOps

My application has multiple environments, each environment with it’s own settings (config.prod.json)

What I want to do

Basically Octopus should take the release from Azure DevOps, and copy the release to multiple folders, with different config.prod.json files.
Each folder corresponds to a specific IIS website.

Azure DevOps pipeline setup

  1. Use Node 14.x
  2. npm install
  3. ng build --prod
  4. Archive dis/angular-app ; Archive type: zip
  5. Publish Artifact; Path $(Build.ArtifactStagingDirectory)

Triggers : Enable continuous integration

Azure DevOps Releases setup

1. Package Application for Octopus

enter image description here

2. Push Package(s) to Octopus

enter image description here

3. Create Octopus Release

enter image description here

Octopus setup

One step DEPLOY TO IIS

1. Package details

enter image description here

2. Custom Installation Directory

[![enter image description here][5]][5]

3. IIS Web Site and Application Pool
enter image description here
enter image description here

Errors
In IIS while I click Binding, Basic settings, I get this error: There was an error while performing this operation. The parameter is incorrect

Also, the folder mapped in iis for the website that I’m targeting. Contains a folder drop with the zip file 27.zip (27 is the release id)

  1. How do I unzip the zip file?

  2. How do I replicate the zip file to the other environments?

  3. Is my configuration ok so far? What am I doing wrong?

Just a few of the links that I’ve checked:

https://octopus.com/docs/guides/deploy-aspnetcore-app/to-iis/using-octopus-onprem-azure-devops-builtin

Hi @stefan.niculescu,

Thanks for getting in touch!

Regarding the error when attempting to open the Bindings in IIS, this isn’t something that we’ve seen before. Some searching online suggests various fixes such as performing a repair on IIS or installing additional features. None of them seemed consistent, so, it is hard to suggest the best one to try.
If you create a new website within IIS are you able to view the bindings for that or does it return the same error? If it encounters the same error it would suggest that there may be a problem with the IIS install.

If the zip file within the drop folder is being created during the build process then it may be necessary to add an additional step or script to extract this zip file. Or modify the build process to skip zipping it up in the first place.
If you choose to perform the extraction during the deployment with Octopus, the best option may be to add the Custom Deployment Scripts feature to the Deploy to IIS step and add some Powershell as a Pre-deploy or Deploy script to extract the zip file.

When you say How do I replicate the zip file to the other environments? are you able to clarify a bit more? Are you wanting to re-deploy this release to other targets in different Octopus Environments? Or is this for other websites on the same deployment target that you’re wanting to copy the same package to?

If it is the latter, then you would likely need to add additional Deploy to IIS or Deploy a Package steps to your deployment process for each of the folders that need updating.

Regards,
Paul

Hi @paul.calvert ,

First question, if I delete the website and recreate it, everything works just fine. The other websites work just fine. After deploy, the website settings break.

Second question, I don’t know how to deploy the release without a package (zip). What is Custom Deployment Scripts feature to the Deploy to IIS like a child step? Do you have a link, or a example please?

Third, I have a number of x instances of the application, different database, different api, different settings. When I deploy the application, I want the package to update all the front end instances (basically the IIS websites). What is the best approach to achieve this? So that when I delete an instance, or add another one, to be as simple as possible.

Thanks,
Stefan

You wouldn’t be deploying the release without a package, but unless I’m mistaken it sounded like your zip package (KFPortal) contains another zip package (27.zip) that isn’t being extracted? This second zip file (27.zip) must already exist when the Package Application step runs in Azure Dev Ops. So, one option would be to look at how your application is built and see if you can avoid creating the 27.zip file in the first place and instead have those files available within that directory.

If that isn’t an option, then the custom scripts feature can be found by using the Configure Features option within the Deploy to IIS step.
e.g.


This will then add an additional section within the step where you can add custom scripting to perform the extract of this zip file.

Deploying a package to multiple instances would can be achieved using either Target Roles or Tenants. You may need to explore both of them to decide which is best for your situation.

Using Target Roles you would create a new role for each of your instances and add these to the Deployment Target configuration. You would then need to create a Deploy to IIS step for each individual Target Role. This would allow you to provide different details for each instance of the application and have them all deploy in a single deployment.
This method is fairly low in complexity but the creation and maintenance of multiple almost identical steps can be time consuming.
There are additional details on Target Roles available here: Environments, Deployment Targets, and Roles - Octopus Deploy

On the other hand, using Tenants would involve you creating a Tenant for each of your application instances and any configuration differences, such as installation folder, would in Octopus Variables within the Tenant. This method can be a little more complex to initially set up but provides a much smoother experience as you can easily manage and deploy to the individual instances.

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.