If we have an existing NewRelic account, how can we direct our CloudBees apps to use that account rather than the on-the-fly account that's created by activating New Relic plugin on our CloudBees app configuration screen? This would enable us to utilize license pricing we've already paid for and allow us a central New Relic console screen for all our apps, whether they're running on CloudBees or elsewhere.
I have added a New Relic configuration file to my CloudBees app and inside that config file I specify the license key for my New Relic account and now all my CloudBees and non-CloudBees apps are available under my New Relic console. If you follow these instructions to update and deploy the newrelic.yml file and specify your own license key, you should immediately start seeing your app reporting on your existing New Relic console.
Related
I have .net core web application developed in VS 2019 already running in Azure. I installed the VS 2019 in a new system and opened the solution. When I am trying to publish (may be after a simple code change) the application using Visual Studio. The window that is coming up having 3 options to publish. Regarding these options, what is the difference, and when to use what?
Below is the screenshot, options highlighted in red. Create New is for complete new deployment, as per my understanding. However, I'm not able to clearly get, "select Existing" versus "import profile" and when to use what?
Can you download the publish profile from the azure portal for the service in question and reimport it?
The window that is coming up having 3 options to publish. Regarding these options, what is the difference, and when to use what?
1.Create New option enables us to create a new App Service, create or use an existing App Service plan (Hosting Plan) and Resource group within your specific subscription, like below.
If you do not have any existing App Services that you create through Azure portal or VS etc, you can use this option to create a new one before you publish your project.
2.Select Existing option enables us to search and select existing App Services from specific subscription and Resource group.
If you'd like to publish your project to an existing App Service, you can use this option.
3.Import Profile... option provides a way to import publish settings that we got from Azure portal as below and then deploy our app.
Sometimes, developer does not sign in with same account (create Azure App Service etc resources using this account) in Visual Studio, to deploy app to an existing App Service, we can use this option and import a publish settings file.
I've studied the link below:
Storefront Source Code Getting Started.
According to the "Configuring content connection string" Section, I realized that the need to be placed physical address of "cms-content" of admin.
but We've deployed web applications(admin and storefront) to dedicated server.
So for a configuration with these conditions I read the link below:
Deploy web applications to dedicated server
But this link is not yet clear how the "ContentConnectionString" was initialized.
ContentConnectionString storefront setting pointed to place where themes files stored and has default value ~/App_Data/cms-content.
VC platform, with installed module vc-content allows to manage themes files from manager UI and have similar setting CmsContentConnectionString.
If storefront and platform have installed on same Azure apps or dedicated server this both settings should pointed to same physical place and have follow valuesprovider=LocalStorage;rootPath=~\App_Data\cms-content in platform Web.config and provider=LocalStorage;rootPath={ vc-platform physical path}\App_Data\cms-content in storefront Web.config.
For case when VC platform and storefront have separated installation need to use azure blob storage provider=AzureBlobStorage;rootPath=cms-content;DefaultEndpointsProtocol=https;AccountName=yourAccountName;AccountKey=yourAccountKey to share themes files between storefront and platform.
We strongly recommend use store and change your theme in GitHub repository and use CI (continuous integrations tasks) for update themes on production and use admin UI theme management only for emergency fixes or other not historical changes.
I am testing WSO2-Emm system for managing our android mobile app. We have an app for taxi drivers. We deploy it using our tablets and a single gmail account. Our problem is that google allows up to 10 signed in devices for a single google account.
I have tried to load the apk to the WSO2 store. The problem is that when I want to upload a new version of the same app I get a warning message saying that this APK already exists in the store. When I try to rename it and add it as a new apk it works. The problem is that when I go to App-Management, the application appears under 'installed'. The Emm system doesn't detect there is a new version.
To be more specific, my question is is there a way to manage mobile application versions using the WSO2 store and not the google play store.
If there is a way we can go on with this system. If not, we will stop testing it.
The only way I've figured out how update an already installed app is by going to the App Management tab, selecting your latest version of the app in question, and hitting the install button under the Roles tab (NOT the Users tab). It will send the install command to any devices listed under roles you have checked, even if they already have the app installed. Keep in mind this will install the app on all the devices, even devices that already have the version you're trying to put out.
It looks like you already know about the patch on EMM-686 that must be implemented in order to upload multiple versions of the same app to the Publisher. Just in case you want to confirm it's implemented correctly, see my answer here for instructions on how to implement it.
With Direct Update, the mobile application can be automatically update with a new version of the web resources. In order to update the native resource, a new version of application must be uploaded to application store.
Consider the case that I have an update for my Worklight app with both native and web resources code update which has already been in application store.
Questions:
Is the following a correct way to update the app?
Step 1. Package the app in .ipa / .apk (with native + web code) and submit to application store
Step 2. Deploy an updated .wlapp file (with web code) to Worklight Server.
In application store, I can specify the application version when uploading the application. Will the application version be incremented automatically once I deploy the .wlapp to Worklight Server?
If the user does not update his application in application store and open the application, since there is a new web resource update in Worklight Server, it means that there will be a direct update alert box to prompt the user to download the latest application and in this case only web resource will be downloaded. There are some problems when the native code and web code are correlated?
Thanks a lot.
This would essentially be the correct order of steps, yes.
However, since you say you're updating both the native and web resources, I would make sure that the existing app can work with just the web resources update (without updating the native), because once deploying the .wlapp to the Worklight Server, existing users will receive a Direct Update.
If this scenario is not one you want to support, then in application-descriptor.xml you should also up the value of the version=" " attribute in the environment's element. When building the app after doing so, this will create a new .wlapp (for example: myProjectNameMyAppName-1.1.wlapp instead of ...-1.0.wlapp).
This means that the existing 1.0 users will not receive any Direct Updates, unless you deploy an updated ...-1.0.wlapp to the Worklight Server.
In relation to the above, no, the application version is not incremented automatically, it is something you need to control manually.
Also, I don't think the version value is something you control in the application store interface...
IFAIK the application version is changeable in Xcode prior to creating the .ipa for iOS and in AndroidManifest.xml prior to generating the .apk for Android (and in similar fashion for other environments).
EDIT: Actually... I think that changing the version value in application-descriptor.xml will also up the application's version number. Need to look at the end result (in AndroidManifest.xml or the Xcode project, in Xcode).
This would really depend on the behavior of your application and how resilient you've written it to be in the face of updates. I have slightly covered this in #1 above.
Other than talking about it theoretically I would suggest taking the jump actually upload an app to an application store, and test it privately, of course. This would be the most convenient to do using Google Play where publishing an app is near-instant.
I'm in the process of learning iOS development and app submission process. Before trying to archive my application I only tested and debug it on iOS 6 simulator and now I want to deploy this application on real device. And during this I encountered with some problems.So, what steps I must implement in order to successfully archive my application and get an .app and then an .ipa file of it. How to setup provisioning profiles and solve code signing error?
You need to go to the provisioning portal at http://developer.apple.com and generate provisioning profiles for your applications there.
If you have not paid your developer license fee you will not be able to install your apps on real devices.
You will need to get a Developer and or Distribution certificate including their respective Private keys. You will also need a Team Provisioning Profile, or a Provisioning Profile specifically made for the app. You can either make all these yourself through the provisioning portal at http://developer.apple.com Or if you are working for someone else who has a developer program license, they could possibly provide you with all these.
The provisioning profile describes all the steps you need to take to implement the certificates and provisioning profiles so you can build and deploy / distribute your app.