I've been successfully using Git deploy (via Kudu) to a couple of Azure websites (e.g., beta/prod) for several months, and it's worked quite well. Starting today, I noticed that when I push to the appropriate respective git branch, my Azure websites will supposedly deploy - i.e., the deploy kicks off, everything builds, all my tests run, and the Azure management portal swears up and down that it's deployed my website - but ... nothing happens. My websites don't change. (Beta and prod pull from different branches of the same git repo, but no matter which I push to, none of the changes included in the latest push show up on either website.)
There are no errors or any other indication of a problem in the logs. The Azure portal detects the git pushes, runs the deployments, and swears that they've happened successfully. But the changes - some very simple ones, i.e., text on a certain page - simply aren't there.
This is the sort of thing that I'd normally contact Azure support for, but my subscription doesn't include tech support :-(. The Azure site recommends asking here on SO, and hence my post.
Any suggestions for further troubleshooting this?
Well, I don't know what was triggering the problem, but resetting the website - by adding a bogus key/value pair to the configuration, and saving it - triggers the website(s) to pick up the changes. Apparently the underlying issue is that the Kudu deploy doesn't seem to be triggering the website to reset itself. I'll add more details in the future if I run into the problem again.
[Edit 2013-10-15 - Today, deploys seem to be working normally again. My guess is that it was some sort of transient Azure bug that's now fixed.]
Related
Currently in the process of potentially moving our sites to Azure. As it stands we are testing deploying to Azure app service, everything works and publishes fine using one computer. However if someone else runs a publish from a different computer with an identical build the publish operation sees fit to 'update' all of the files, of which there are a lot. Then when the next publish occurs from the original computer the same happens there. Further publishes from the same computer do not generate this 'updating' of all the files which takes a long time.
Never had this issue previously when publishing to IIS on our Rackspace servers. Why is MSDeploy choosing to update these files even though they have not changed at all and seemingly only because the publish is coming from a different computer to the last publish that occurred?
Can anyone explain how I can stop this?
It seems your project is in local repository or personal repository, and maybe published using zip deploy or Visual Studio.
Deploy like that would come up with a connection between Azure and the
location of your project. If you deploy from another computer, or
another repository, the connection would be fresh to the new one,
which would update all the files like publishing a new project.
You could consider deploying continuously from a remote repository like GitHub, which you could access it on any computer.
Here are the samples you could have a look:
Deploy using GitHub Action
Deploy using DevOps
Let's say I have an Azure App Service web app at foo.azurewebsites.net. The code for the web app (a simple Node.js server and React frontend) is hosted on VSTS, and a custom deployment script is configured build and deploy the web app every time code is pushed to the repository's master branch. In other words, the standard web app configuration.
Now, all of my API code (just a Node.js server) is in another repository on VSTS. I'd like to be able to do the following:
Have all requests to foo.azurewebsites.net/api be handled by the API server (an implication of this, which I would nonetheless like to state explicitly, is that the server can ask the browser to set cookies that the web app can then read, and vice versa).
Set up similar continuous deployment for the API server, such that it gets redeployed whenever there are code changes in the API repo.
Be able to maintain the web app and API repositories completely separately.
This seems like a fairly standard scenario...is there an accepted solution? I came across this, but it seems like a pretty hacky way to do it, not to mention the fact that I have no idea what the correct URL is for the web hook for VSTS and can't seem to find any information on it. Also, that example doesn't cover how to deal with point (1) above.
EDIT: Additional clarification
Note that the accepted answer on this question is not what I'm looking for. It describes how to pull from a second repository at deployment time, but not how to have that second repository trigger deployments, or how to handle the fact that the the second repository is its own server. Additionally, it introduces a dependency between the two repositories, since the deploy.cmd is presumably under source control in the first repository.
EDIT: Virtual Directories
Thanks to #CtrlDot for pointing out that Virtual Directories are the way to solve (1). Still seeking guidance on (2) and (3).
I think the concept you are referring to is called Virtual Directories
I'm not sure which VSTS task you are using to deploy, but based on the article provided, you should be to configure it to target only the virtual directory you want to deploy to.
EDIT
Sorry for not being more clear. The AzureRmWebAppDeployment task has a parameter for virtual application name. You would simply set that in your deployment pipeline for the API project (/api) and for the main project (leave it blank)
with a local TFS 2013 server i'm trying to implement the Continuous Integration of a webservice to Azure. Now the build Definitions have the following:
/t:Publish /p:DeloyOnBuild=true /p:PublishProfile="xxx" /p:AllowUntrustedCertificate=true /p:UserName="yyy\$zzz" /p:Password="abc"
When a checkin occurs the build gets triggered, and i receive an Successful message. I then access the site on azure only to find the site wasn't updated.
i don't receive any errors. it almost seems like the deploy didn't happen.
if i do all this manually using the publish feature of VS2013, i choose the profile i got from importing the 'publish profile' file from azure. Then i see the changes. So my profile is good. It's just seems that the MSBuild is not doing the deploy after the build.
also in the LOG of the build. i don't see any references to deploying... not sure if i should see something there.
the only hint i get from the log is that the line:
Run optional script after MSBuild = 00:00
everything after that is also 00:00.
is there perhaps a setting that the autobuild needs to deploy? something more than what the manual publish would need?
so this odd problem was happening because the username included the domain. now there are several guides out there that indicate to use the user name found in the publish file you down load from azure. Which is what I did. But the web deploy didn't work until the domain was removed from the username.
/flp:verbosity="diagnostic" /p:DeloyOnBuild=true /p:PublishProfile="xxx" /p:AllowUntrustedCertificate=true /p:UserName="$zzz" /p:Password="abc"
notice the removal of yyy in username from the first post.
now i'm happily deploying.
I have a solution containing a .net mvc website, and a webjob.
I deploy using git - so on git push to azure, my website is upgraded. I'm now just adding a console application that is going to be run on a schedule. I'm trying to work out how to deploy this with the website when I git push, but I'm not sure how to do this.
I know I could create a folder website\app_data\jobs\triggered\webjob and copy the files into there (say from a post-build event on the webjob), but that would mean I would need to commit all those files to the git repo for the deploy to pick them up - which would also mean that every time I build, Git would be prompting me to commit them again - ugh.
Is there a nicer way to do this - where I can just push my repo to azure, and it will deploy my website correctly AND my webjob?
Thanks
Yes, you can do this without having to put the actual EXE's and project output into the folder explicitly. This blog post from the Azure Blog documents the workaround to enable Git or command-line deployment of a web application inclusive with WebJobs.
http://azure.microsoft.com/blog/2014/08/18/enabling-command-line-or-continuous-delivery-of-azure-webjobs/
If this doesn't unblock you please post an update and I'll help walk diagnose any other issues you run into. You may also want to update the WebJob publishing NuGet to the most updated one on NuGet here: https://www.nuget.org/packages/Microsoft.Web.WebJobs.Publish/1.0.2
As of 9/15/2015, this appears to be as simple as some context menus inside Visual Studio.
If you want your WebJob to automatically deploy whenever your Website is deployed, in Visual Studio you can right-click on the Website and select "Add->Existing Project as Azure WebJob".
More details here, in particular the "Enable automatic WebJobs deployment with a web project" section.
I was struggling with this, but I've got it working now.
It appears that WebJobs.Publish 1.0.2 must be used. 1.0.1 was not working for me. Worked as soon as I updated.
I had also tried adding webjobs.props files as indicated here by David Ebbo, but that didn't work for 1.0.1 and I've now removed those files and it's working under 1.0.2 without them.
Using WebJobs.Publish creates a webjob-publish-settings.json (in the webjob project) and a webjobs-list.json (in the MVC app) and that would seem to be all that is needed.
Only thing that does not work is creating the schedule for a scheduled job. Continuous and Triggered jobs deploy just fine. There's a thread here where David Ebbo mentions that this is a current limitation.
Where I work, our marketing team is looking for a "quick and easy" method up periodically updating some files on a website of ours. I opened my mouth and said "We can use Azure Websites with DropBox!". It all works fine, except that with DropBox, files only deploy if I log into the Azure Portal and click Sync. Needless to say, this is a deal breaker, because the users want to save a file and have everything appear magically.
Is there a way to setup continuous deployments via DropBox on Azure? I don't mind setting up a job to run every 15 minutes to perform a file upload if needed.. but would prefer to avoid that if possible
Thanks In Advance
Currently we don't support the continuous sync with Dropbox. The challenge is the noise and the reliability of the site given those changes. Imagine users naturally modify file by file and Dropbox sync them one at time. You can get into the situation where your site is in transient bad state.
This is not currently possible using the Dropbox integration in Azure Websites. Best option for this is the local git integration, where Azure will provide you a remote git location that you can push to that causes an update.
So that gives you behavior, but not the dropbox behavior you want, as someone would still need to commit and push.
To get that you could look into implement a Git hook to mimick the behavior, where you would auto commit and push when a file changes.
Something like this would give you that behavior, but you'd need to translate to a server-based model.
Git Repo Auto-commit and Push
Alternatively, you can host the site in GitHub or Visual Studio Online and I beleive you get that hook automatically.