I am developing an MVC 4 web application, VS2012.
For such applications I normally created an msi to install the app but for this project I am moving to the more modern publishing mechanism. I normally install to different environments:
dev
qa (server 1, 2, 3)
staging
prod (server 1, 2, 3)
Question is, do I need to create a publish profile for each of the environments, including a profile for each of the servers on qa and prod (as 1 web config setting varies between servers).
It seems like a need to create alot of publish profiles for this. Am I correct? What is the best way to manage publish profiles.
Publish profiles were designed for what you are describing. They allow you to specify different publishing configurations on a per server basis.
I am not sure what you mean by What is the best way to manage the publish profiles?. VS 2012.2 will manage these for you within the solution.
You can also right click on a publish profile and add a web config transform for that specific publish profile.
Sayed Hashimi has a good video explaining this here. http://www.youtube.com/watch?v=HdPK8mxpKEI
Related
If we are deploying a basic WebApp / WebApi, both these tasks from Microsoft appear to do the same thing - deploy to an appservice.
AzureWebAppV1
AzureRmWebAppDeploymentV4
How do you choose which one to use in a new YAML release pipeline? I just want to make sure I am using the version that is most future-proof - I have 25 release pipelines and don't want to have to re-do them unless necessary.
The way the help is written, hard to compare feature to feature to spot the key "must-haves". Some Microsoft online examples use both. Both are still marked as "In Development" in the readme and both are >1 year old since last check in.
The simplest way to deploy to an Azure Web App is to use the Azure Web App Deploy (AzureWebApp) task.
By default, your deployment happens to the root application in the Azure Web App. You can deploy to a specific virtual application by using the VirtualApplication property of the AzureRmWebAppDeployment task.
Azure App Service Deploy task allows users to modify configuration settings in configuration files (*.config files) inside web packages and XML parameters files (parameters.xml), based on the stage name specified.
Just my two cents, but I just noticed Web App Deploy takes much less time than Service App Deploy. I was wondering how come a simple zip deploy (Service App Deploy) can take so long. So I looked around and found there's also that Web App Deploy, so I tested it.
My project (React/Next small sized app) normally takes 6-10 min to deploy with Azure Service App Deploy (v4). With Azure Web App Deploy (v1) it took a little more than a minute. Wow.
We are working with Redhat's 3scale as our API management platform.
Currently we have a development environment and we are trying to build up another environment(Staging/Production).
Does anyone know how to move the artifacts(Pages, Files, Partials, Layouts, Sections etc.) of the Developer portal from one environment to another?
At the moment there is no API available yet for the Developers Portal, but it is on the product roadmap: https://issues.redhat.com/browse/THREESCALE-361?jql=project%20%3D%20THREESCALE%20AND%20description%20~%20%22api%20cms%22
I have some questions around the best mechanism to deploy MVC web applications to different environments. Previously I used setup projects (.msi's) but as these have been discontinued in VS2012 I am looking to move to an alternative.
Let me explain my current setup. I currently have a CI setup using TFSBuild 2010 with Team Foundation Server for source control.
A number of developers work on their local machines and check in to the TFS Server. We regularly deploy to a single server dev environment and a load balanced qa environment with 2 servers. Our current process includes installing an msi which carries out some of the following custom actions:
brings current app offline with the app_offline.htm file
run in database scripts (from database project in the solution)
modifies web.config (different for each web server of qa)
labels the code
warmup each deployed file via http request
etc
This is the current process. Now I would like to make some changes. Firstly, I need alternative to msi's. From som research I believe that web deploy via IIS and using MsDeploy is the best alternative. I can use web config transforms for web config modifications. Is this correct and if so, could I get an outline of what I need to do?
Secondly I want to set up continuous delivery via TFSBuild, I have no idea how this may be achieved, would it be possible to get an outline of how it can be integrated in to my current setup? Rather than check in driven, I would like it to be user driven following check in. Also, would it be possible for this to also run in database scripts from a database project in the solution.
Finally, there is also a production environment, but I would like to manually deploy this - can my process also produce an artifact that I can manually install?
Vishal Joshi has some information on his blog that is reasonably good, http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html. It does have the downside that your deployment password is include in the properties you pass to msbuild.
Syed Hashimi has also posted some information on this in another questions Team Build: Publish locally using MSDeploy.
Where I work, we release bug fixes in to the system every night when we know our clients are not using the system.
Trying to take a step towards better service I'd like to deploy to IIS while the application is running.
A solution that comes to mind is to setup two different IIS applications and switch them over after deploy using a script. But I'm not going to try this out as I don't want any complications during our busy hours.
Does anyone have experience in this area of deployment?
Thanks
Regardless of whether you're using PHP, ASP, ASP.NET etc there is no native support for transactional deployment on IIS.
The simplest approach would be to have two physical folders and (optionally two web sites - one production, one test) on your web server, for example:
c:\websites\myapp\dep1
c:\websites\myapp\dep2
Initially your site would have its physical path pointing to c:\websites\myapp\dep1.
When you deploy your latest build you'd deploy into c:\websites\myapp\dep2. Once you're done just switch the physical path of the production site over to this folder. This means you still have the original site and can fall back to it if the new code fails for whatever reason.
The next time you do a deployment you'd deploy into c:\websites\myapp\dep1 and once you're done switch the production site to that folder.
You could optionally have a test site that points to the folder you're deploying to so you can make sure the site works before switching your production site over.
This could all be scripted.
Here's some related reading that may be of interest:
Publishing/uploading new DLL to IIS: website goes down whilst uploading
Is smooth deployment possible with componentized ASP.NET MVC apps?
Rob Conery also had an excellent blog post about the lack of a decent deployment story for ASP.NET application. You should take a trawl through the comments some of which are quite insightful:
ASP.NET Deployment Needs To Be Fixed
Getting Constructive On ASP.NET Deployment
We will be developing 3 asp.net web applications. Each of them will have it's own database. We don't want these applications to share resources because they're from different departments.
What is the recommended hardware setup that will allow us to have staging and production environments for each application?
I generally just have 6 boxes set up. 2 each for development, staging, and production...and then of course production can scale out from there. Then I use cruise control to push my code from one environment to the next. You don't need physically separate environments to run your 3 different applications.
Take a look at this for more information: SVN Website Development and Deployment Solution