I need some consulting on a deployment issue on web applications .
Let say I have many web apps installed on my web server (WCF service , ASP.NET site, Silverlight app , Static web app , and thing you can host on IIS).
My main problem , I need to manage these application version up to my clients.
Example : Today I have Wcf service with version 1 , all the clients work with , after next month I release version 2 and I need to install it separatly on IIS and start move clients one by one to it .
Same thing can happen to any application type I have .
Is there a modern way I can do that .
Thanks in advance...
Take a look at Nuget and set up a feed your clients can use. Full versioning capabilities included:
http://nuget.codeplex.com/
http://www.codersbarn.com/post/2012/05/09/An-Introduction-to-Nuget.aspx
If you deploy your WCF service version (such that 2 versions can co-exists), you can make use of application configuration files to manage what service each individual application points to. So after you deploy the new version of your service, you simply go through each applications web.config file and modify it to point to the new service when you desire.
Related
I am trying to minimize the cost of running my web app in Azure App Service. I have a Visual Studio 2017 solution with two Web Projects: Web and API (both .NET Core). The entire solution is part of a single GitHub Repo. Before adding the API project, the build and deployment to Azure App Service was automated. My goal is to deploy both projects under the same App Service (to minimize cost) with two subdomains (e.g. www.example.com and api.example.com) and keep everything automated.
Is this something that can be done? Can somebody please help me understand how this can be done? Can those settings be commited?
An Azure App Service Plan can contain multiple web apps. Normally when you use the Azure portal to connect it to source control, Kudu (the tool behind App Service Plans), will create a deployment script for that site.
In case you want to deploy two projects of a single solution (and git repo) to different Web Apps you have to do the following:
Create two web apps under the same App Service Plan
Connect both of them to the same git repo for automated deployments
Modify the deployment parameters
I'm going to suppose you know how to do the first two steps.
To modify the deployment parameters, you could either modify the deployment script by downloading it through Kudu and adapting it or, much simpler, configure it through the portal:
Go the App1 => Application Settings => Add setting PROJECT with value
<path>\<path-to-app1>.csproj
Go the App2 => Application Settings => Add setting PROJECT with value <path>\<path-to-app2>.csproj
Every time you push up a change, both web apps will receive an update, but they will deploy a different part to the web site.
More information can be found here (see last paragraph): https://github.com/projectkudu/kudu/wiki/Customizing-deployments
We have multiple clients and we use Azure web sites to host our web application. When we upgrade a client to a newer version of our software we have to upgrade all of our clients to the latest version.
We would like to be able to upgrade a subset of clients when we release a new version. This would give us the ability to test that the new solution is working properly before we bring all of our clients to the new version. We would like to offer a beta version option to selected clients so that they can access new features of our software and are aware that the version they are using is still in a 'beta' mode.
When we deploy a new version we would like to create a web site just for this new version whilst leaving the other clients on the more stable previous version. To do this we are thinking of writing a reverse proxy that directs traffic to the different versioned web sites depending on the client.
Can we host multiple versions of the web site using the same Azure web site. (IIS directories) The documentation I have read relating to this does not mention being able to build multiple versions of the web site based on different code bases.
Is there a way to set up the build so that each new version is deployed to a directory on the Azure same web site so we can effectively host multiple versions of our app under the same azure web site?
We could do every versioned build to a new Azure web site but this could get quite expensive as we run two instances so as to maintain a good SLA. It is feasible that we could end up with ten versions in the wild at once, running 20 Azure web sites to support these versions could get expensive. How can we save on costs and give our clients a good experience?
You can have up to 5 deployment slots including production on azure web apps. Each slot can use a different branch of your source control system like git or tfs. If you use any of these two, deploy is also automatic (continuous deployment) and you can swap slots any time very fast with minimium to none downtime. Each slot has it's own url for external access.
To save costs, you can run multiple web apps on the same hosting plan. There's no limit for the number of web apps running on the same hosting plan. For each hosting plan it's possible to have 10 small/medium/large instances.
Set up staging environments for web apps in Azure App Service
https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
Azure App Service plans in-depth overview
https://azure.microsoft.com/en-us/documentation/articles/azure-web-sites-web-hosting-plans-in-depth-overview/
Yes this is possible. In management portal, You need to configure the details for the IIS virtual directory or application in the website’s configuration.
Ref - http://blogs.msdn.com/b/tomholl/archive/2014/09/22/deploying-multiple-virtual-directories-to-a-single-azure-website.aspx
Is there a way I can deploy my entire website/webapp to an Azure WebRole without the need of Visual Studio?
Context: We have a test environment where there's an IIS hosted web app where our testers test (of course). The thing is, we want to grab that exact tested web app folder and deploy it "as is" to a WebRole.
Please avoid commenting on our procedure, we have been looking at it and we will eventually change it if we have to, I just need a 'simple' yes(how)/no answer.
IIS Web Deploy can be used to package/migrate/restore IIS applications. It can be enabled while deploying a web role as described in this article and allows to update the web role with the application as deployed in your test environment.
Be aware that only single instance cloud services are supported and that in case of a maintenance operation by the fabric controller, your service will be rolled back to the state created by the initial azure package deployment. (There once was a tool for syncing between multi-instance web deployments but sadly that did not work out too well and is no longer supported. Do not attempt to use or rebuild it.)
Installing and Configuring Web Deploy shows the steps to get web deploy for your local testing IIS while articles on using web deploy like this one show examples for calling the tool.
Another option to evaluate are azure websites and git deployment. This could provide you with a documented and reproducible form of deployment that is not prone to unwanted rollbacks while allowing the service to scale to multiple instances. This option might not work out if the application it too tied to the web roles infrastructure or contains code not suitable for the more restricted web sites environment.
A third option to look at is using CSPack as presented in this article. You basically create a service definition and package up the webapp manually without building it in Visual Studio or TFS.
Yes - make sure you have enabled Remote Access on your webrole. Then copy your web app from your local IIS folder to F:\sitesroot\0 (NOTE - may be E:\sitesroot\0 on same web roles).
Yes, you can write a programmatic interface against Web Deploy from your C# code. If you're deploying to Azure Web Sites, you could also use the Windows Azure Management Libraries to spin up new web sites or clouand deploy them.
I've created an Azure server instance. I've deployed a simple application to it. As part of the deployment process I enabled Remote Desktop Connections.
I have some standard ASP.net applications that run on Windows, is there something to stop me deploying these applications manually to IIS using Remote Desktop. I've read so much about having to migrate standard ASP.net apps to Azure. I don't want to this as we will have customers who will still use Windows Server 2003/2008 so I don't want to have to maintain 2 versions.
Well, as I understand it, in theory you could deploy stuff using remote desktop. But when the instance shuts down/restarts you'll lose it all (unless you've built it into your startup scripts) and have to re-load everything each time. The main reason they suggest you have at least two instances is so that when one shuts down for updates etc there is always at least one other running.
The "Windows Azure Accelerator for Web Roles" project allows you to create an Azure web role which then enables you to use web deploy for all your other web sites - I'm guessing that will be a whole lot better approach and is definitely worth a look. Also, I believe smarx.com is a good place to browse for info and ideas.
Using a startup task and the Azure Bootstrapper you can download, unzip, install almost any kind of 3rd party software that supports either xcopy deployment (just copy the files) or an unattended(silent) install.
Assuming you aren't using Azure storage or anything like that, there shouldn't be any difference with the IIS application. If you are using anything specific to Azure, you can use the RoleEnvironment.IsAvailable to test if you are running inside Azure or not. That will return true for the emulator as well. If you want to use Azure storage from both, you can add the settings in the web.config to use if not running in Azure.
Our server application runs as a service and has a ASP.NET MVC3 web-based frontend that connects to our application for monitoring and configuration. Our application is generally installed on client servers that are maintained by their IT departments so I'm trying to figure out the best way to package and deploy the ASP.NET portion of our application to make it as painless as possible to run on their servers.
It seems like the official way to run an ASP.NET MVC3 site is to deploy it to an IIS server installation. Since we would like to avoid pushing the additional overhead of providing, installing, and maintaining a full web server onto our clients it seems that it would be best if we could give them a package that was entirely self-contained and just ran a second service alongside our application. The web frontend is for internal use only so scaling isn't much of a concern.
Any ideas?
The simplest way is to host it yourselves. I frequently make technology decisions for my team, and having the option to pay you to host an instance for me is 100% my preference.
Ultimately, the alternative is the client having a web server. You cannot just set it up for them, because IIS requires administration and configuration to be secure and work in the client's environment.
Since there weren't a lot of responses here I'm answering with what I ended up doing in case anyone runs across this in the future.
We ended up using IIS Express. We're going to distribute the IIS Express installer along with our installer (allowed by the IIS Express license: http://blogs.iis.net/vaidyg/archive/2011/01/17/iis-7-5-express-official-release-highlights.aspx). Once installed we use CreateProcess to directly run iisexpress.exe with the /path set to our ASP.NET project so the entire thing is completely controlled by our existing service (and we can route output into our logging system). We use Job Objects to ensure that the IIS Express process is killed if our service crashes.
We do something like this to shutdown IIS Express:
for( HWND currentWindow = GetTopWindow(NULL); currentWindow != NULL; currentWindow = GetWindow( currentWindow, GW_HWNDNEXT ) )
{
DWORD currentWindowProcessId;
GetWindowThreadProcessId( currentWindow, ¤tWindowProcessId );
if( currentWindowProcessId == m_processId )
{
PostMessage( currentWindow, WM_QUIT, NULL, NULL );
break;
}
}
We haven't put this into production yet, but it's been working great so far during development.