I need to deploy apps to app store for each branch. I have DEV, PROD, Staging and UAT environments. Each has a separate branch. What i need to build and deploy each branch to separate app in app store.
The problem is I can only add a single app in app store connect. If i try to add again, it says 'already connected'.
Anyone knows any solution for branch based deployment to store??
I couldn't find any articles mentioning these kind of scenarios.
Scenario
Single Repo
Dev Branch ---> Dev_App
Staging branch ---> Staging_App
I have separate apps in app store for each environment.
I would think it is normally discouraged to have multiple versions on the AppStore. I would think you would run DEV locally, STAGING on devices that download a release build from AppCenter, and PROD on the AppStore.
If you really wanted different versions on the AppStore, you would probably need to change the BundleIdentifier per release. You can find this in the Info.plist file.
Related
Consider an enterprise mobile app available for both Android and iOS, with build and release pipelines.
What I'm trying to achieve is a promotional model for the release pipeline, such that the app binaries are built only one time in a build pipeline, and are then promoted through the environments to production by a release pipeline:
Build pipeline builds the IPA and APK files
Release pipeline is triggered after a successful build, and deploys to the Test environment
QA manager promotes to the QA environment, and it's pushed out to testers
QA manager promotes to the Production environment, and it's pushed out to end users
[ APK/IPA ]---->Test ---> QA ---> Production---->[ Same APK/IPA ]
There are corresponding Test, QA and Production versions of a backend API that the app must connect to (e.g. while the app is at the Test stage, it should connect to the Test API) - but how can the app know which one to connect to?
Now, if I was creating a web app, this is simple enough to handle using environment variables, so the web app knows which environment it's running in - not so with a mobile app.
The only way I can figure to handle this is for the app to connect to a kind of configuration API, sending it's version number, so it's "told" what environment it belongs to by the backend. But this seems a little inflexible.
Is there perhaps some way to bundle a file in the APK/IPA files to let it know which environment it belongs to? What ways are there to handle this?
I am new to kobotoolBox, I was required to add some changes to kobotoolBox project. I have successfully run the project in android studio and have applied changes and now need to publish that.
I want to ask that I have cloned this project from GitHub means it has the same package name with which already an APK is published on play-store. What should I do to publish APK that I have created. Should I need to change the package name or there is another alternative way aside from changing package name??
You may check this guide to help you started.
Publishing is the general process that makes your Android applications
available to users. When you publish an Android application you
perform two main tasks:
You prepare the application for release.
During the preparation step you build a release version of your
application, which users can download and install on their
Android-powered devices.
You release the application to users.
During the release step you publicize, sell, and distribute the
release version of your application to users.
Explore the page for you to get the proper steps when publishing an application.
Hope this helps.
Once a build is submitted to the Apple Store/TestFlight or Google Play, that specific build can't be changed.
I take that to mean a Production build must be submitted, configured for the Production environment.
But then how would that same build be able to point to a Staging environment (for TestFlight or Google Play Alpha/Beta testing)? and then when approved reconfigured to point to Production before promotion to the App Store?
How do I support both a Staging and Production environment in a single build?
An example, would be for analytics where staging metrics shouldn't go to production or Q/A users whose data should reside on a Staging database.
There are different approaches to deal with this. Part of this depends on your needs. For example, if you want to to be able to point to stage with a production build.
An easy approach is to use the Debug and Release configurations as your means of separating the two. In other words, builds built using the Debug configuration will point to stage and builds built with Release point to prod.
You can certainly pimp this out if you want. For example, you can have your Debug build actually be configurable to change environments.
Control of this is done with compile time flags such as DEBUG. So your code would be something like:
#if DEBUG
// Do Staging environment setup here
#else
// Do Prod environment setup here
#endif
It can be helpful to do this through some object to limit the places in code you need to discern between environments.
Note this is also a common way of handling 3rd Party services you may use for analytics, etc which have different keys for QA/prod.
By default, Android Pay refuses to work in debug builds, which makes testing tricky. What we've done so far is to actually merge new code into a develop or hotfix branch so our build environment will make a signed APK which can be tested. This is not ideal.
https://developers.google.com/android-pay/get-started states
"Note: Our test environment will not return live, chargeable tokens in the FullWallet response, but will allow us to test your pre-purchase flow. You will see an Unrecognized App error on the Android Pay chooser until your app has production access."
which isn't too promising.
https://developer.android.com/google/play/billing/billing_testing.html suggests testing with specially configured static responses for "reserved product IDs", which would be a nuisance to set up and not a true test. The other option they offer is to publish the app to an alpha or beta channel, which would, of course, be a signed APK.
https://stripe.com/docs/mobile/android has a suggestion about "TEST_GATEWAY_TOKEN" but isn't really helpful in learning how to use Android Pay in test.
We even talked to a Google Developer Advocate, who did nothing but cut and paste some of the same documentation.
Is there any way to do a good test using an unsigned build? It would be wonderful to test Android Pay functionality successfully on a local developer machine.
No, there is not a debug mode option to that per docs:
https://developer.android.com/google/play/billing/billing_testing.html
set a separate machine with a CI server and have it do the alpha and beta builds for testing Google Play.
It is a pity but you have only one way to test IAP:
Grant testing permission to your google accout used at your device
Build .apk file.
Upload it to your account at GoolePlay as beta version
Wait until uploaded .apk processed
Try do to actions you need and check it.
If any issues - fix them and start from p. 2
I have an app which is published on both App Store and Play Store already. The app published is pointing to my production server. What I want to do is to have my devices install a "staging" app which points to my staging server so I don't mess up with the real users during my development. So essentially, my device would have two of my apps - MyApp and MyApp_Staging. The staging app must be able to be distributed to my testers.
I use the Push Notification feature from Parse. How can the staging app has the same feature? Do I need another Developer account for staging app?
I have been looking at iOS Beta Testing features. It seems like my staging app has to be reviewed by Apple before I push to my testers. How can I skip the review process? For Android, the staged rollout seems like a good idea, but the staged app will be replacing the production app.
Is there a way to have both staging and production apps installed on devices?
For iOS:
I have staging and production app for iOS installed on the same device. I can't answer this for Android, but here is my set up for iOS with Parse push notifications.
A: Multiple versions of the app on the same device:
For both the apps to be installed on the same device they need to have different bundle identifiers. To do that:
Open your project and go to the Info tab for your Target.
Locate the setting for Bundle identifier
Add a suffix at the end of the identifier as follows: com.MyApp$(BUNDLE_ID_SUFFIX)
Now open the Build Settings tab and add a new User-Defined setting
Set the name of the setting be BUNDLE_ID_SUFFIX
Add a different suffix for each of the build configurations that you have. e.g. Debug could have the value .debug. Leave the suffix for the Release configuration empty. I have 3 build configurations with different suffixes.
Debug for testing as I am developing
Adhoc for releasing adhoc builds to testers.
Release for releasing to the App Store.
If you follow this path, you will notice that all the versions of app installed on your device have the same name and it will be difficult to tell them apart.
To fix that, go back to the Info tab and edit the setting for Bundle display name to say ${PRODUCT_NAME}${BUNDLE_DISPLAY_NAME_SUFFIX}
Similar to what we did above create a new User-Defined setting with the name BUNDLE_DISPLAY_NAME_SUFFIX and add different values for each build configuration. e.g. mine say α and β.
The above will allow you to install multiple versions of the app on a single device.
B: Setup Push notifications using parse between the versions.
To set up Parse push notifications to work across these versions: Follow the Parse tutorial to create certificates and provisioning profiles for each of the bundle identifiers. e.g. I have 3 certificates/provisioning profiles for my 3 bundle identifiers:
com.MyApp.debug is a Development profile for DEBUG.
com.MyApp.adhoc is a AdHoc Production profile for Ad Hoc testing.
com.MyApp is a AppStore Production profile for submitting to the App Store.
Make sure to set the right provisioning profiles in your Build Settings, so that the app is signed correctly.
Upload all the certificates to Parse.com. Parse allows you to have 6 different iOS push certificates.
C: Using different production and staging servers.
Set up preprocessing macros on Build settings tab. Search for Preprocessor and under Apple LLVM 6.1 - Preprocessing for the setting Preprocessor Macros setup different macros for each build configuration. e.g. mine say for Adhoc ADHOC=1, for Debug DEBUG=1
Then somewhere in your source code have something as follows:
#if defined(DEBUG)
#define SERVER <development server>
#else
#if defined(ADHOC)
#define SERVER <staging server>
#else
#define SERVER <production server>
#endif
D: Sending builds to testers.
This topic has probably been covered multiple times. I am not fond of Apple's Beta test process. There are numerous other solutions. The one I like is Beta by Crashlytics.
You can read about it here: http://try.crashlytics.com/beta/
I deploy the AdHoc build configuration to testers as it is built with the Adhoc provisioning profile which allows me to deploy it on 100 devices without Apple approval.
For Android
To install both on same device at the same time , use different package names for application
com.company.testapp - For the app in staging
com.company.live - For the app in live mode
For interaction with server use different URL(s) in both the apps e.g. store urls in some file and use same as static variables.
Deploy GCM/push notification code for both on different servers.