When configuring IIS for our backend service and frontend UI, I stumble on a problem. Both services should be independently deployed, yet this is not possible, because…
The content of the UI is directly hosted under the default installation were the package is deployed. That is it’s physical path. The backend is configured as application and gets his own physical path. Yet when configuring this, it is not possible for the backend to create a website because if that web site is already present, it while overwrite his value. I have not seen anything were I can keep the physical path empty or pick up the currently value of it.
So what I’m trying to say is, the process should be repeatable and stable, but if the UI is not deployed first(were the website is created), the backend cannot be deployed because it cannot create the IIS website else it while overwrite the UI.
What I did now is, deploy the backend and UI in one project, but I want to divide them in separate projects or is this not the way of going? I’m very curious if someone else stumbled on this problem as well.
It sounds like the deployment of your backend service and frontend UI are coupled together and therefore they should probably be deployed together too.
If you truly do want them to be deployed independently, then I would recommend de-coupling the deployment process of both of these services.
One idea as to how you could do this is to create two IIS applications for both the Frontend UI and for the Backend service. Both of these applications are under the same web site.
With this design, you could have two projects for each service. Each of these deployment processes would first try to create the same IIS website if it does not yet exist. You could try using this community step template to create the IIS website.
This is not perfect because the two deployments are still somewhat coupled together, but it could be enough to solve your problem. However, I would still recommend deploying both the backend service and the frontend UI together since they are part of the same IIS website.
Thank you for your reply. I understand indeed. I already played around with the create the IIS website and thought of that approach as well. The only downside of that then when creating applications underneath the web site, is that our end-users have to type a “/” in the URL. Yet I must say that I’m lacking knowledge of IIS here and maybe rewrite rules can be made for this?
They are indeed coupled together, but I was just purely curious because on our integration server they are also separately compiled and packed.
The current approach of deploying the UI and backend in one project is the way of normally going?