Best way to deploy feature branch releases to incremental IIS port numbers

Legacy Uncategorised
1

In our development process we create releases of feature branches. Ideally, we’re thinking of deploying these branches to the same IIS server and run them on different port numbers. What would be the best way to achieve this? It looks like

2

Hi Pascal,

Thanks for getting in touch! With Octopus you can create and configure IIS sites on the fly during your deployments. You could something like this

  1. Have a Powershell step that checks an available port within a fixed range designated by you and assign the port number to an Octopus variable
  2. Use the Octopus variable value to set the port number on your deployment-IISConfiguration step.

Not sure if you had any other questions (your post seems to have been cut). Feel free to write us back and let us know if my reply made sense to you :slight_smile:

Dalmiro

3

Hi Dalmiro,

Yes, that is weird that my post got truncated. But your answer looks like a very workable solution. I have experimented with the port determination a bit and it seems to work.

I do have a follow-up question: we’re triggering the deployment from Bamboo and I’m wondering that it would be convenient to know in Bamboo on what exact port the release was deployed. Obviously there could be two approaches to this:

  1. have Bamboo come up with a port number (regardless if it’s available on the IIS server); that way we could record that number in Bamboo
  2. have OD report back the port number to Bamboo

Do you know what approach would be most viable? And how would I do it?

4

Hi Pascal

Either of those would work, given enough powershell! But neither are particularly elegant.

I was discussing a similar scenario earlier in the week with somebody, and I’m wondering if you’d considered using IIS host headers instead of ports ? That way you could use the branch name as the instance URL.

So you could have feature-foo.apptest.mydomain and feature-bar.apptest.mydomain for example and use your internal DNS to resolve *.apptest.mydomain to your test server.

It’s a way of doing it by convention rather than having to map between branches and port numbers and look up what is where.

Would that work for your scenario ?

Damian

5

Hi Damian,

Hmm… yes, that sounds like an excellent idea, actually. So given that we work with JIRA on a certain issue on a specific feature branch, which we name after the JIRA issue number (e.g. “KEY-123”), then we should configure OD to deploy to host: #{branch-name}.our-test-host.com, right?

That only leaves me with the question: how do I get that branch name from Bamboo to OD, given that I deploy now with Octo.exe?

Thanks,

Pascal

6

We plan on adding branch support next year which would make this easier, but for now could you maybe use the release notes field to specify the branch the build was created from ? That’s easy to set using octo.exe.

Damian

7

Hi Damian,

Yes, that should be a viable workaround for now.

Thanks for the quick answers!

Pascal.

8

No problems!

Another way to do it would be to use the OctoPackAppendToPackageId param we’ve just added to OctoPack. Then your package could be something like MyApp.feature-branch.1.2.3.nupkg which you could parse.

Damian