Apologies if this question has already been answered. I've tried looking around, but may not have done a great job!
My azure deployment consists of 4 web sites deployed from VSTS that all share common web assets hosted on an Azure CDN. I would like to create a single "build" (or release) in VSTS so that I can build all the client-assets at once and deploy them to the CDN endpoint as well as the 4 running app services for fallback.
My initial approach used FTP tasks for the web servers. This worked but took almost an hour to ftp 500+ files to each website. I then attempted the approach mentioned here. Though I was able to zip up the assets, my drop file had the structure of:
- assets
- WebAssets.zip
Eg. "WebAssets.zip" was just a compressed copy of "assets" and I was unable to deploy this file to the proper location on the websites, "/site/wwwroot/wwwroot".
Is there a better way to copy these assets to each web service? Here is the structure of the "ftp" version of copying the assets:
Any help or direction pointing would be appreciated.
Update: just wanted to clarify that the current process does indeed work. It just takes between 30min and an hour to complete. I just want to make sure I am doing it correctly and that there is not a better way.
With Azure App Service Deployment task, you need to check Publish using Web Deploy option if you want to extract the zip folder.
On the other hand, to improve the performance, you can setup a private build agent that has the high performance (e.g. Network, Memory, CPU)
Deploy an agent on Windows
Related
I'm playing around with Azure Static Web Apps and have built a simple Blazor App which I've deployed. I added a Contacts page with an image that appears when built and running in Visual Studio but the image is missing when the app is is deployed via a GitHub Workflow Action. I've checked the file is present in the GitHub repo. I'm just using the free version of Azure static web apps for testing and believe the files are deployed to blob storage.
I can see two similar related questions to my problem but neither of them provide a solution to my issue
Is there a way to view files in Azure Static Web App?
Azure static web apps not loading page resources correctly. css or javascript files
As per the link to the first question above, is there a way to see the files deployed to check if the file is actually there? Everything I'm seeing tells me it's not! - the image is not showing and copying the link to a new window gives me the usual file not found. Link looks absolutely spot on - https://madeupbit.azurestaticapps.net/FundXWebTelNo1.png. I deliberately moved the file out of a separate images directory into the root to eliminate any of the possible issues mentioned in the second question linked above.
And I guess the second question is if it's not there, how do I get it there seeing the automated GitHub Workflow Action ain't doing it. Of course there may be something else going on so any suggestions welcome!
I am deploying a Nuxt application with Appveyor over Azure App Service Zip Deploy, but I am having trouble with the full deployment process being incredibly slow (Around 30+ minutes).
It seems that the whole build process is going as it should, but zipping the files takes around a minute or two (106 MB), and the file is successfully being pushed to the app service within a reasonable amount of time. However the incredible waiting time is at the Site Under Construction white page stage, taking down the whole website with it.
Does anyone have any tips to speed up this process besides upgrading
the App Service plan?
Is there any way to avoid the blank Site Under Construction page?
For example, is there a way to unzip to another folder and move the
files after everything is done so I would get minimal downtime on
the website?
You can add WEBSITE_RUN_FROM_PACKAGE=1 app settings
This option will deploy your app service to read only file system (read-only wwwroot folder, other folders are available for write operations)
Please take into account if you set this variable on ci/cd tool side probably the first time it won't apply because app settings are passed after zip deployment
And regarding the second questions. I guess it could be fixed by another app settings SCM_CREATE_APP_OFFLINE=0 (it should update your app without bringing it offline)
I uploaded static files on Nginx + NodeJS. The only way I know how to update the website is using an FTP application.
Is there some other way of uploading website assets?
Is there a package that allows commits in GitHub to automatically update my website in Nginx?
What are the best practices for updating websites? I tend to avoid CMS as much as possible as I'm only updating the website a few times only.
It all depends on how you’re hosting your site. Some services provide their own tools for updating content within them. For example if we host our site in a docker deployment in aws ecs, then we would use aws commands to get that done.
If you’re fine with ftp, then you can create a GitHub action workflow to automatically update your site
You can take a look at the sample pipeline I provided as a response in this post for reference on how the workflow would work
https://stackoverflow.com/a/63731446/14167216
I am starting a new project (let's call it MyWebProject) which will have
MyWebProject: a front-end app with AspNet Core serving a SPA with Angular2
MyWebProjectAPI: a back-end app with AspNet Core connected to a DB and exposing RESTful API
They don't have inter dependencies since MyWebProject access MyWebProjectAPI through http requests only. So we could say they are independent.
I have a single domain www.mywebproject.com linked to a single Azure App Service mywebproject.azurewebsites.net and I want to have both projects (front-end and RESTful API) deployed under the same Azure App.
If I access with a web browser www.mywebproject.com I want to access the front-end. I don't mind where the RESTful API is deployed (I'm guessing in a virtual directory under the same App Service IIS?)
I am also planning to have continuous deployment where pushing changes to a master branch in a Git repository would trigger a new deployment (ideally both deployments are configured separately but I don't mind that much)
The question is:
How to structure my solution/projects and what approach should I follow?
I am considering One single solution with the 2 main projects (front-end and back-end) plus library projects required by the back-end project, and therefore I am assuming they all would have to be in the same Git repository?. Would that be a problem? or is it better to have them in separate Git repositories and separate solutions? (this option would also be ok)
What would be the approach to follow when deploying into the same Azure App service? To use a virtual directory because they both are web projects (both have a wwwroot)?
Another option could be one single project for both RESTful API and front-end with one of the controllers simply serving the SPA and the other controllers acting as the API resources. This would certainly simplify everything, but somehow I wanted to have both projects independent.
Any reference, article or opinion would be appreciated.
I work with an app where we have one solution that two different Web Projects, both living at the same domain and both being deployed using continuous deployment. It works out fine. Here is how it works:
Have one Visual Studio Solution
Under that solution have the two web projects
In the Azure Application settings for your App Service, scroll to the bottom under "Virtual applications and directories" and set up a Virtual Directory for MyWebProjectAPI. Virtual directory would be "/MyWebProjectAPI" and Physical path would be "site\wwwroot\MyWebProjectAPI"
Create the deploy.cmd for doing the continuous deployment in the solution folder, just like normal
Edit the deploy.cmd to also deploy the second web project.
You'll find a line for the first project that looks like:
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\MyWebProject\MyWebProject.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\"
IF !ERRORLEVEL! NEQ 0 goto error
Copy that code and update it to build the API project into the virtual directory (notice the first path changed as well as the PackageTempDir):
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\MyWebProjectAPI\MyWebProjectAPI.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%\MyWebProjectAPI";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\"
IF !ERRORLEVEL! NEQ 0 goto error
After you deploy, your front end will be at www.mywebproject.com and the api will be at www.mywebproject.com/mywebprojectapi (of course you can rename everything).
Is this the right way to go? There are pros and cons. In our case we needed to do it this way because the 2nd Web Project came from a third party and had to live at the same domain. And that's a big pro - you avoid any possible cross domain issues. Also you have a lot of consolidation with only one DNS entry to worry about (including SSL certificates) and only one App Service to pay attention to.
I could argue, though, that it would be better to let your code run in two apps to get more distinct monitoring and scalability. You said you only want one App Service right now, so either way you don't get the ability to scale. But if you set up two projects as different apps, you could eventually move them to separate App Services later if you needed to scale one and not the other.
If you did want two separate apps with different DNS entries, you could still have just one solution file. I don't have an exact example of doing this, but you would have both apps monitor that branch. So a build would kick off in both apps when you pushed. But you would add a setting in your Azure Application Settings saying which project should be built, and you'd modify your deploy.cmd file to look for this parameter to build the right one.
I have a solution in Visual Studio Team Services that has 2 Web Applications (specifically one project for WebAPI services and another for the actual site using MVC).
I'm trying to set up continuous delivery to Azure but all the information that I can find seems to assume that you only have a single Web Application within your solution (which seems a little unrealistic for all but the simplest of projects!).
The out of box continuous delivery process seems to just pick and deploy the first Web Application it finds (which isn't necessarily the same project each time!)
I've tried specifying the Deployment Settings file, but that seems to affect the destination rather than the project being deployed since again, it seems to just "pick" a project to deploy, and each time it deploys every single compiled assembly plus all dependencies rather than just the binaries and dependencies of the project actually being deployed, which can cause issues with MVC finding duplicate controller matches for a given name (this can of course be fixed by specifying the namespace of the controllers within the route configuration, but that seems less than ideal, and still doesn't fix the entire problem).
Ideally I'd like to find a way to deploy both projects with a single build, but as a temporary solution I'd be happy with 2 builds that are both triggered by a check-in of the single solution, that each reliably deploy 1 of the 2 Web Applications.
Does anyone know if this is possible? I guess I could write my own custom build template, but I'm hoping there is an easier answer (not least because I can't imagine that this isn't a problem being faced by other people!)
I did find this question TFSPreview.com and Azure continuous deployment for multiple solutions in TFS but since that's quite old and is specifically talking about AzureWebRoleProjects rather than Web Applications being deployed to the newer Azure Websites feature, I'm hoping that there is a more positive answer?
This is possible with multiple build configurations. In addition to Debug and Release you could specify two more, one for each app.
You can find these in Visual Studio at Build -> Configuration Manager. And then in the configurations specify only one of them to be built. Then running MSBuild with that configuration will output only one WebDeploy package.