I'm trying to figure out a good way to version my android app.
Problem is that we have multiple environments:
Standard production environment for most of the users
Beta environment so users can see the latest additions (WIP)
Test environment which is an internal release of the app so our own people can use the system.
All 3 environments will have both debug and release, release will be the default that is being used. The debug is only in case there are issues we can't figure out and might be hardware related as this app will be used on our specified devices (so not every device can use it, I mean they could but it might not work as expected).
So I don't know what versioning to use as basically a feature is released only to the test environment, so our internal users can test it.
Once that feature is accepted as a good working feature without bugs or anything (or atleast as low possible) we release it in the beta environment so our customer can give their own thought about this feature so we can get an idea of our customer requirements.
Once we gather that information we compile it and then discuss if we should implement it in our production environment, once it has been accepted as a new feature, we launch it to our production environment.
So because we don't update our production environment that frequently as it has to get through test and beta environment, I am wondering what might be a good versioning system for this?
I know that many use the "major.minor.patch" versioning but I don't know if this will work in this case.
Any ideas?
My thought:
I was thinking to maybe use "major.minor.patch" versioning of production and for the beta and test environment I would do "major.minor.patch-environment-major.minor.patch" so we can see how many changes we have applied to it since the last update to production.
But I don't know if that's a good idea or not...
You can give version to each flavors separately like below
productFlavors {
Standard{
versionCode 1
versionName "1.0.0"
}
Beta {
versionCode 2
versionName "1.2.0"
}
Test {
versionCode 3
versionName "1.3.0"
}
}
inside app level build.gradel
Related
I was trying to run an A/B test using Firebase A/B testing, but just for specific versions of the app. There were no results and no users exposed to the experiment after 5 days of running it.
After that, I tried to run the same A/B test but without a version restrictions and the first results were available the next day.
So I thought that the way I was defining version restrictions was wrong. I tested it in Remote Config, but the Remote Config was returning the correct values when I applied the same version restriction. Here is how I defined the version restriction in both cases:
The app's version names are in the following format X.Y.Z (e.g. 6.51.0, 6.51.1)
Is there something that I am missing? Is the test significantly slower to start if specific versions are being targeted?
This should work. I have tried this many times. Make sure that you're targeting the correct value based on your app configuration. The Version targeting criterion...
For Android app, you should target the "versionName", not the "versionCode".
For iOS app, you should target the "CFBundleShortVersionString", not the "CFBundleVersion".
In addition, you should put the exact number on the console. For example, if the versionName or CFBundleShortVersionString is 1.0.0, then you should put 1.0.0 and not just 1.0.
Please note: although I specifically mention AngularJS, Ionic and Cordova here, I'm really talking about any mobile app (hybrid and native alike) that produces binaries for iOS and Android platforms. As such, I believe that anybody with experience in mobile dev should be able to address the question!
I am building a mobile app for iOS and Android using AngularJS, Ionic and Cordova. My concern is that iOS and Android release updates all the time, some may be buggy or just might be outright breaking changes and all of the sudden become incompatible with the plugin/library versions that I'm using.
This will cause apps to crash spontaneously in production. But it sheds light on an even nastier problem under the hood: making the decision to pin your builds against specific dependency (plugins/libraries/etc.) versions or just always pull in the latest/stable versions of them!
Option 1: Pin your dependency versions
Here we specify the exact version of all dependencies to use. We then fight with the Ionic build to get the app built, but are now good to go. I can expect that if I don't change any of my code, that each subsequent build of the app against the exact same dependency versions will always result with a successful build.
However, when iOS/Android does release a breaking change or bug (or anything that prompts the library/plugin maintainers to go into a frenzy and publish new versions of themselves), because I've pinned my previous build to specific versions of dependencies, I may actually be running on very old dependency versions and it will now be a massive headache to get my app building again against all the latest versions.
Option 2: Use latest/stable versions at all times
If I don't specify dependency versions (and just let the build always use latest and greatest), then I could work fervently to get my app building, then wait a few days (and not change any of my own code) and then try building it again and the compile/build might fail! This is because in between those few days, some project upgraded itself and/or its own dependencies and introduced a build-breaking change.
However, when iOS/Android releases a breaking change that requires me to upgrade to latest dependencies, the headache would likely be considerably less then Option 1 since I'll be on a relatively much newer version of all my dependencies.
Are there any tools/strategies/techniques/etc. that the mobile community leverages to stabilize builds and make it so that I can have more consistent, repeatable builds?
It is recommend to use specific version of your dependencies, you may consider using the notion * at the minor patch level X.Y.* to get the lastest bug fixes.
Your build should be automatic and consistent, there are products that do this for you, e.g BuddyBuild and Buddy support both Android and IOS.
Successful builds is not the whole thing, The app should pass all the functionality and QA tests before a release. So you need to write as much as UnitTests and FunctionalTest to cover the quality checks. There are other QC tools for even further assurance, For example static code analysis tools help you to discover potential bugs and failures, And test coverage tools let you know which parts of your code has not been tested yet.
Here is a Simple CI/CD workflow
Code -> Push -> CI Test -> CD Publish Release
You can set a job to build your project on a weekly basis on the CI server and Publish a Release only if it passes all the Quality Checks
Apps crashing on the new OS versions is not a catastrophic problem, it's common and has its solution, Google and Apple don't release new OS versions to users just like that, Developers are provided with preview builds of the OS and new APIs, Developers usually have more than 2 month to adopt thier apps with the new changes and even use the new API features.
And by the way you have access to crash reporting tools like Fabric.io and Firebase which helps you to discover problems at production.
Cheers
I wish to release a new app as public beta for Android and production for iOS. I wish to have the same version numbers for both. But, iOS doesn't allow version less than 1.0.0 for production, correct me if I am wrong.
So can I use version 1.x.x for an android public beta app?
Is there any restrictions in Google play to use appropriate version numbers?
You can use whatever versionName you want. The only thing that matters is the versionCodes have to increment. You can't upload a new APK with a matching or lower version code.
The versionName has no purpose other than to be displayed to users.
https://developer.android.com/studio/publish/versioning.html
On gradle you set "versionCode" with an integer, this integer must be necessarily superior to the previous version. check play console for help about alpha-beta versionCode hierarchies.
on the same gradle you set "versionName" string, the info that your apps users will see, this is a free textfield, you can use "1.x.x" or "1.xx.xx_beta"
productFlavors allows free texfields too
check the "app info" about apps instaled on your device and compare styles
I have uploaded my application on google play store under beta testing rollout for test purpose to find out if there are impersonation kind of issues.It got published. Now I have a very minor change in my application and would not like to unnecessarily change the version. So can I sign the apk and directly publish it on production .And what will happen to this beta production,anyway I do not wish to retain it,Or should I again upload it with new version on beta test and publish it to production? Any help in which should be the proper procedure is appreciated. Thank you :)
You will not be able to publish the same version code twice to the same release agent. BETA can have versioncode 1 for example and then Production can have versioncode 1, But you can not rebuild and release versioncode 1 again. It will not allow it.
Yes you can release two completely different builds to release vs beta and have both be version 1, but you are creating ambiguity.
BETA users will always have the latest versioncode app whether it comes from BETA or Release, so in this scenario it will likely default to production app as it will assume that BETA was promoted to production due to matching version code. Hope that makes sense.
Also, you do not have to change your version String so if you are going out as 1.00 you can still leave it as 1.00. This is the version string that you show to the user and name the release, you can reuse that as many times are you want, The version code is an arbitrary hidden integer value that google play makes you supply so it knows if it is newer or not. It is not visible to the user other, they will see your version String.
It depends what you mean by version. There is a version string which may be the same and there is a version number which must be different.
I sign the apk and directly publish it on production. And what will happen to this beta production? Anyway I do not wish to retain it. Should I again upload it with new version on beta test and publish it to production?
For your new build, increase the the versionCode to 1 more than the previous release's versionCode. Directly publish that to production. The version in the beta phase will by shadowed by the production version. Anyone having the beta app will see an Update, wherein they can update to the production version. In your Beta section on App Releases section, it will show like this:
According to the official documentation (Versioning your applications), the "android:versionCode" must be increased with every release of an Android application.
For release versions supposed to be uploaded to Google Play, I understand why this is necessary. However, what about nightly builds, mainly aimed at developers? For these, the versionCode would need to be generated, which is not straightforward (SCM like Git without numeric commit id, possibly multiple builds from the same commit etc.).
So, my question:
Can I just use a constant versionCode for nightly builds? What consequences will this have (apart from not being able to upload to Google Play)?
Can I just use a constant versionCode for nightly builds?
Sure. That's what happens every time you run your app from your IDE, after all, unless you have scripted something (e.g., in Gradle) yourself to generate a unique versionCode.
What consequences will this have (apart from not being able to upload to Google Play)?
Nothing that's any different from doing builds in the IDE, other than things that are more tied to doing centralized builds, more so than versionCode (e.g., certificate mismatch errors, unless everyone and the CI server are synchronized to use the same debug keystore).
VersionCode is used to upgrade your apps, if you are using the same versionCode in your ease release, it will oveeride your apk file and don't able to install your new release file in which you have made some changes in it
In android you have versionCode and versionName by default. versionCode is an integer that is used by Google Play Store to make sure that you are uploading a new version of the app
For e.g. If you are releasing your fisrt app to playstore, your versionCode is android:versionCode="1" and if you're releasing your second version, your android:versionCode="2", so it will always increasing.