I have stateless .net core 2 Fabric Service Web Application creating using one of the templates that comes with Service Fabric SDK. It is a real pain to develop since I have to do a full deploy before I can see any changes to code/html/script. In my case that operation takes more than 5 minutes.
I have looked at this article that states how it can be done by running the web app from the commandline.
That article is based on Net Core RC2. Does anyone has an updated example on how to do this?
https://dzone.com/articles/aspnet-core-with-kestrel-and-service-fabric
Together with Azure Developer Support i found a solution to speed up the development process
I Fabric Explorer you need to find the node where you Web Application is running. I my case that is _Node_0
By SF SDK design, local SF published file is under C:\SfDevCluster\Data_App\ this folder. In my environment, the website file path is C:\SfDevCluster\Data_App_Node_0\Application1Type_App1\Web1Pkg.Code.1.0.0\wwwroot\lib\bootstrap\dist
So you can also find your HTML, CSS, JS and other static resources under below path:
C:\SfDevCluster\Data_App[node_id][application_type_and_instance_name][service_type_and_version]\
You can just modify the files in this folder, then the change will immediately apply to your local test web browser. Please notice if your service is hosted by micro-service running in several nodes, you may need to modify all nodes files because load balancer may access any folder files randomly.
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.
I am not clear enough yet how Service Fabric allows deployment.
From the applications being created in a single VS solution, let me try to ask with file formats for better understanding.
In a single Visual Studio solution, there are
a single .sln
a single .sfproj
multiple .csproj(s)
As I see these files, multiple services (.csproj files) are bound to a single Service Fabric application (.sfproj file), which is under single solution file (.sln file).
Can I individually deploy a .csproj project to the Service Fabric cluster, or are these now bound to a .sfproj so that I have to deploy multiple services (each created with .csproj and bound to .sfproj) together?
The answer to your question is yes and no at the same time. Let me explain it in detail.
Can I individually deploy .csproj project to the Service Fabric cluster
The answer is no you can't deploy a service - in term of Service Fabric the minimal unit of deployment is the application (the .sfproj one). So no matter what changes you have you still need to deploy the application.
But as we all understand performing a full deployment of all application services is very hard, consumes lots of time and causes lots of disturbance to the cluster. To avoid this massive update, all Service Fabric components have their own versions (you can take a closer look at ServiceManifest.xml and ApplicationManifest.xml). So each time application is deployed to the cluster, Service Fabric goes through all services included in the application and updates only components that have been changed (i.e. have different version).
This approach allows you to perform updates of very high granularity i.e. you can update only <Config /> package of the single service.
I'm running an ASP.NET Core web service that's dead easy to deploy to IIS on a Windows Server using WebDeploy: Right-click the project in VS, choose Publish, done. The currently running site is backuped and then updated. Couldn't be easier.
However, Windows services are another matter. I'm taking over maintenance of a service that is currently updated by building the Release config, remote desktoping to the server, stopping the current service, renaming the folder the service executable resides in (for easy rollback in case something goes wrong), copying over the build output from the dev machine, renaming the copied folder to the service folder name so the service finds the executable, and starting the service.
Is there a way to publish/update Windows services that is as easy as running WebDeploy? I haven't found any. There's always the possibility of abusing WebDeploy and just replacing the Windows service head project with an ASP.NET head project running on IIS, but the service has nothing to do with the web and I have no idea whether there would be any side effects to this solution.
(I could of course just write a script that performs the copying etc., but a built-in VS deployment process as with web projects would be optimal. As for continuous integration/deployment, it is unfortunately not something we have ever done at my company.)
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 have recently added some functionality to our web site that requires adding a service reference to an api in an external domain. Adding the reference to a VS2008 project createed a sub-folder in the "Service References" folder and added 18 files to that folder that appear to represent the classes in the api. The api provider also had me add custom binding and client references to system.serviceModel in my web.config file.
Do I have to deploy that entire folder with its 18 files to my production site to use the web service? Does some of it get compiled into my project dll? I can find all kinds of references to deploying a service, but not what is necessary to deploy a service consumption module.
Sorry for short, but I don't have the answer for you. But you can get this answer yourself. This is the only way Iwould get the answer. Deploy it without them, see if it works. If it doesn't deploy with. If it works, then you know.
The good news is that I have to deploy absolutely no files from the project have to be deployed to the production site. Everything the web service consumer application needs gets compiled into the application assembly.