Stackify offers a Web App Extension (which I think you’re using) and you would need to add that Web App Extension to any new Site or Slot as part of the deployment, and uses some AppSettings for your API key etc. One way NewRelic is installed as a NuGet package, and included when you build, package, and eventually deploy your application. Release Notes for WebDeploy 3.6-betaĪPMs like Stackify and NewRelic can be installed in different ways. We are working with Microsoft to update the NuGet package, otherwise we will have package and ship it ourselves. Improved Proxy support (but fixes in WebDeploy)Īll of these rely upon us upgrading to .3.6.0 (track this GitHub Issue).Improved Checksum support (bug fixes in WebDeploy).We will continue to roll out further improvements to Azure Web App support, though we don’t have any fixed delivery timeframes for these: We cannot maintain consistent timestamps when extracting NuGet packages - see this GitHub Issue for more information. To get the most benefit of using timestamps for WebDeploy sync, start using zip packages instead of NuGet packages. Any new Azure Web App steps you create will use Timestamp by default.You will need to modify existing steps to use Timestamp (we do not automatically switch them over).You can now use Timestamp instead of Checksum and see if this fixes the issue for your deployments. has reportedly had issues with locking when using Checksum for file comparisons. The examples we have seen so far look look like threading dead-locks in WebDeploy. I can see you’ve been participating in a few threads about this issue, so I apologise if I’m repeating anything you already know. I’ll try and summarise what we’ve done so far to address this issue. A hung deployment’s last log output is always timestamp checking.Might need to test more here to be certain. Deploy from Visual Studio seems to work well, at least the 2 times we have tried it so far.Clean upload (delete deployment slot first) always succeeds, or at least the 4-5 times we tried it, which indicates that timestamp checking is one of the culprits here.Frequency varies but we almost always have to retry once or twice for each deployment, sometimes it fails several times in a row.Upload speed of big binary to web app FTP is stable at 1.5-1.7 MiB/s, meaning it should theoretically complete a full upload of web app in about 3.5 minutes, and practice have shown a clean upload (no timestamp checking) to take about 4-6 minutes too.Azure web app S1 Standard tier app service plan with two web apps hosted on it, total load is very low.Successful deployment takes 4-6 minutes, where timestamp checking makes up about 2-3 of those minutes.Deployed app size: 240MB and 3300 files. Combination of hung/success and dev/staging servers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |