My Teams app:
multi-tenant
deployed using Teams Toolkit to Azure Storage, CDN enabled with a Custom Domain
in alpha use by internationally distributed organisation (third party, not me), users around the world
the app functionality works fine including multi-tenant
in rapid development so frequent code updates. Very rare manifest updates.
Problem:
I frequently update the app's code and deploy the update to Azure using Teams Toolkit
when I do this users often report 'blank tabs' for a period of time, can be many hours. They see the tab menu but the tab contents are simply blank. Purging the CDN doesn't seem to help.
seems most common using Teams desktop app but also reported using browser and mobile Teams app
I think this may be an issue of code deployment .js files (each of which gets a new filename) not being available to the install, I can sometimes reproduce but very unreliably. Other times I can access the app, using a user account on the client's AAD, successfully from different locations (using a VPN to emulate location).
Previously the app's Custom Domain was managed on Cloudflare's proxy.
I disabled this and implemented Azure CDN.
Users continue to report the problem.
This is very poor user experience.
Does anyone have experience of this or hypotheses on what may be happening?
Thanks.
Would suggest to test one thing first: manually deploy a new code change to Azure storage, with the same storage-CDN-custom domain setup.
See if this also causes the hours delay symptom.
By doing this, if the issue is reproducible, it may indicate that the Azure Storage-CDN configuration needs to be optimized.
Otherwise please share the result and it will help narrow down the root causes.
Related
I have a quite extensive application running under Azure.
As part of the operational management of the application, I have a set of Application Insight instances to provide monitoring, tracking and logging.
The overall application consists of three ASP.NET MVC websites and a Worker Role. Additionally, I have three instances ("environments") of the application overall deployed (QA, UAT and Production).
I noticed a while back that for one of the App Insight instances (for the same MVC website across all environments) it was quite heavy on the number of Dependency data points that is being collected. Specifically, this is causing me to exceed the 5 million data points included in the monthly quota.
Noting this, I changed the Web Tests (for availability) to hit a different endpoint (one that doesn't invoke the dependencies).
However, I am still seeing the old endpoint being hit.
Digging a little further into this, I believe that I have an old rogue Web Test that is still active, and still hitting the old endpoint.
Issue is - I can't find it.
Is there a way to query, even if via the Powershell Cmdlets, the subscription in an attempt to find this? I've trawled through the portal and cannot see it anywhere.
Could this be the "Proactive Detection" feature? If so, can you change the endpoint it monitors?
You should definitely open a support ticket with us. Check out the dev support options and look at either option 3 or 4. It's preferred you open a support ticket via Azure with a support plan (option 3) if you have one. But, if you don't have a support plan check out option 4 and you can get in contact with us that way.
I've been ramping up on Azure Mobile Services over the past week. There are definitely some PROs and CONs in using them over a standard Azure Web Site where I can write APIs that hit SQL DB, etc.
One of the biggest negatives I see is developing the server side code and DB structures ON THE SERVER. I've watched lots of videos from launch and beyond, read lots of blog posts about tips and tricks around WAMS, but nobody seems to talk about the downside of developing the code (server scripts) and database structures on the server, at your live URL.
This is all great for developing the first version of your mobile app and associated mobile services. But once it's all deployed, how do you ever build version 2? Real apps hitting real APIs and data, but now I want to develop/change/play with the server scripts and database schema?
With Azure Web Sites, I can develop locally and only publish code and DB changes to the server on my schedule.
Have any of you seen or heard of the "v2 development story" around Azure Mobile Services?
Only thing I can think of would be to create another set of tables and APIs around them, most likely "virtual tables" that allow me to write APIs against the original set of data. Seems like a huge hassle, since the client code would now have to know about the original set of tables and the new set of tables... that's only for v2...
Thanks for any thoughts / insight.
You should have two services, one dev and one production and use scripts to promote your code from dev to production (pretty similar to how most workflows go, in moving from a test setup to a production one).
http://channel9.msdn.com/Events/Build/2013/3-511
I would like to be able to have my login work in development mode (localhost:3000) as well as on the production server, and ideally, on a staging server.
Apparently you can only configure one domain for login, unlike Google apps, which is much smarter.
Maybe I could rig up my hosts file to do something spiffy with a subdomain?
Under Basic Info: App Domains, you can put in your domain. It will handle all subdomains if you just put in the main domain name: '<yourdomain>.com' So it will definitely be able to handle your dev.yourdomain.com, qa.yourdomain.com, staging.yourdomain.com, etc.
As for your local development, that's where it gets tricky. You can't use multiple domains, as you've noted. You can definitely try to follow this answer: https://stackoverflow.com/a/7493806/183880 which involves creating a second Facebook app and configuring the domain to localhost.
I'm not sure if anyone else has solved it yet, but I came across the problem where if you are trying to develop Open Graph actions and objects, it's pretty much difficult if not impossible to develop those locally. This is because the Facebook servers need to be able to access the Open Graph object urls. And in this case since you'll be developing locally, they can't access http://localhost:3000/my-object-url. Somehow you need to be able to expose your local environment to the external world. More trouble than it's worth, in my opinon. My only work around is to just deploy to a development server http://dev.yourdomain.com and test from there.
I have a SharePoint 2010 (farm) solution that contains exactly feature:
The feature is site-scoped.
The feature's visibility is set to "true".
The assembly deployment target is set to "Web Application".
The feature contains one webpart.
After adding this solution to the solution store I can deploy the solution to a specific web application. However, after deploying the solution to exactly ONE web app, the feature is actually visible on ALL site collections! I would assume that the feature should only be visible in site collections hosted by that ONE web app?. Trying to activate the feature and add the webpart to a page will (expectedly) fail in all site collections of other web apps (the assemlby cannot be loaded).
Is that a SP2010 bug? Is there a workaround? I just want to limit the visibility of a feature to specific site collections...
Please help!
Thanks
Jan,
Are all your web apps running on the same WFE server? If you have multiple WFEs, you can do this:
Deploy feature to web app A in WFE A.
You should see the feature in the Site Collection Features of web app A.
Now, go to a web app B in WFE B. When you look at the Site Collection Features in web app B, your feature shouldn't be there.
If your web apps are running on the same server, then they are using the same 14-Hive/TEMPLATES/FEATURES folder. Once you deploy the feature to just one web app on that server, the features-folder is sitting in that server's TEMPLATES/FEATURES folder, which will make the feature visible on the Site Collection Features of all apps in that server.
If you have multiple apps running on the same WFE and if it still your requirement to limit the visiblity of the feature, you may have to look into sandboxed solutions.
Another possiblity is you make the feature hidden (visiblity off--it will never be shown on any Site Collection Features) and just have the SP administrators do command-line/cmdlet deployment of your feature for that one web application.
-Gabe
I've just inherited a CF app from a customer who uses a shared CF hosting provider. I'd like to introduce better processes including the ability to stage app changes that I make for their review. (In the past, they would upload changes and cross their fingers.)
Their app lives in a folder under the webroot. Let's call it "/app". I'd like to create a sibling directory named "/appstaging" where I would publish the latest code. The obstacle is that the hosting provider lets you set paths for custom tags and mappings but not per CF app. The existing settings all point into the /app directory so if I need to make changes to tags, CFCs, etc., I can't test these without affecting the live app. What I want is CF to let me set per-app tag paths and mappings. From what I've read, CF8 lets me do this but the customer is using CF7 (I'm pushing for them to upgrade asap). In the meantime, is there anyway to workaround this or does a smooth way of staging changes have to wait?
(I am currently experimenting with ways to detect which app I am based on using GetCurrentTemplatePath() in application.cfm. The idea is that any code that refers to other files using mappings would use a different mapping. I haven't done enough work there though to know if this will all work out.)
Any ideas or input are welcome. I should point out that the app and its dev env is not very "modern." There are no frameworks involved and no things like ant used for build/deployment. The customer's budget is extremely limited so I'm not looking to convert the app whole-sale but I do need to find cheap ways to get some process in there to keep things sane.
This is a serious, but wacky, suggestion: use a second hosted account.
Write up a cost-benefit analysis of having live and staging servers, and compare that to the cost of a second hosted account. The second account doesn't need massive data allowances, etc, and ought not cost as much as the live account.
Additionally, calcuate the cost of revising the code base to allow live and staging on the one account and compare that to the cost of a second hosting account.
Remember that you wont need the second account once your real upgrade is complete.
I expect you'll need to do something like defining the custom tag paths in a config file that gets loaded into the application scope. But that'll require some serious code refitting.