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?
Related
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.
this is a conceptual/design question.
We have a Xamarin Forms apps and I'm creating a build and release pipeline for the Android version in Azure DevOps.
We have 4 environments in total, internal, RC, staging and production.
For each of those I have created a powershell pre-build script that changes some configuration xml files, the app icons (different colours for different environments) and even the app name and package name (this way we can have all 4 installed on one device and be able to test using the different servers)
Now I have a build in DevOps which runs the pre-build script to modify all those things, builds the project, signs the apk and publishes it. In my release pipeline, I cannot use this logic because I need to be able to deploy the different apps to their own test groups in App Center.
So I decided to split the build, it would just build and then the release pipeline would have stages - alpha would run the script and modify the app and sign it and put it for testing in an Alpha group, the Beta stage to beta etc...
However, this means I have to modify the .apk after it was produced using powershell. For example, the Android Manifest file's content doesn't look like XML anymore and has strange NUL, DLE and other symbols in it. It'd make my life harder.
Do I build all 4 packages in my Build pipeline with prepared packages for all environments? This would increase the time a lot so it's undesirable but it'd save me from having to edit APKs later...
What are best practices in these kind of situations, what are you able to suggest I do, change the way I do everything or what?
I'm working with a client who wants to deploy multiple versions of their android application (representing DEV, TEST, UAT, PROD, etc) to the same device.
Normally, with any application, I'd prefer to promote the same compiled binary code from one environment to the next. For example, if a build passed testing in TEST, I'd like to promote that exact build (perhaps with different configs) to UAT. This would be possible if the clients test environments were different devices, but given they have the same android device running multiple versions of the app, I'm wondering if there's any kind of best practice here.
The client is using Azure DevOps. Is there an easy way to build the APK as part of an Azure build pipeline, and then change its Bundle Id, or google-services.json in a release pipeline to indicate that it's a "Dev" or "QA" version of the app?
You may try to use extension 'Mobile App Tasks for iOS and Android', this extension includes tasks to change app's version name and code or app's package name at build/release time. If the extension can not satisfy your requirement, you can refer the source code, modify it and create a custom extension. Please see how to create a custom pipleline task.
I'm trying to figure out the CI portion that provided by AppCenter. I've implemented CodePush for my app and please correct me if my understanding is wrong.
We build the native android app and generate a signed apk.
Release the generated signed apk to playstore
execute command to upload bundle appcenter codepush release-react -a <owner>/<android-app> -d Production
The above are generally the way I understand CodePush and I've tested and working fine.
Now I've noticed that we can integrate our github project branch to appcenter, and whenever there is a git push, AppCenter will build it automatically and we can configure to release to playstore automatically.
Now the part I don't understand is, is this CI auto build by AppCenter actually nothing to do with CodePush?
If now my situation is only having updates on JS code side, actually when I git-push to repo, there isn't a need to auto-release to playstore right?
Correct, Build and Push are separate services in App Center. Build does the binary build of your app while CodePush simply updates the JavaScript and related code in an Apache Cordova or React Native. They're separate workflows and it seems you want to trigger them separate ways.
If you're using CodePush, you can't also use Build to auto build and deploy the native app to devices, you're duplicating work. I'm not an expert, but you probably want to manually deploy your builds whenever you make changes to the native side of the app (which should be rarely, right?) - like when there's major updates to the native framework or new plugins added to the native app
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.