I have various groups for test flight:
1) Internal Testers
2) Employees
3) Beta Testers
We first distribute to all devs via Internal Testers, once we believe it is stable enough, we release to the entire company for further testing and notes, which is Employees, and finally we release to all of our Beta Testers.
It would be very nice however, to be able to alternate between versions, e.g. say the latest version 7, which is for Internal Testers, fixed a lot of bugs, e.g. validations, but unknowingly, version 6 is broken for Employees and Beta Testers. Is it possible, if you are part of the Internal Testers that are testing version 7, to revert/test version 6 and see if these changes had any breaking changes?
Yes, in the TestFlight App, tap on the app icon and then select "Previous Builds".
You will then see a list of previous versions that you have been given access to test. Select the relevant version and then select "install" next to the build of that version that you wish to install.
If you have a known "bad build" you can expire it from the TestFlight page in AppStoreConnect to prevent it from being re-installed.
Related
In our app we updated the database from one version to another.
Now for testing I want to jump between older versions that were officially released at some point in time.
In the Android developer console we can find the previous releases under
Production / Tab "Releases" / Section "Release history" / Dropdown "Show"
and a direct installation link for internal testers under
Blue rightarrow "Details" of the version to install / Section "App Bundles" / Blue rightarrow "Details" of the desired APK / Tab "Downloads" / Link "Copy Sharable link"
The link looks like this:
https://play.google.com/apps/test/<name.of.my.app>/<release versionCode number>
Now if I open this link on my target device (where "Internal app sharing" is activated in the settings) one of two things can happen:
a) everything works fine:
Google offers me to install the old app version with the hint
This version of this app (<versionCode number>) may be old. Turn off auto-update for this app to keep it from getting updated.
b) I get the following notification:
You're an internal tester. This app may be unsecure or unstable.
In this case, the most recent version available to internal testers (typically the future version) is installed.
I have several different Google accounts for alpha testers, and all of them are listed in the same group (Email list) under Testing / Internal testing / Testers
All accounts are in "developer mode" in the Play store and have "Internal app sharing" active in the Play store settings
I typically uninstall old app versions before clicking on the APK link which I sent to my tester accounts via Email
I have several phones with various Android versions, screen sizes etc. I could not recognize a deterministic pattern for ending up in situation "b)"
How can I install the older versions when the second situation "b)" appears?
Our product version follows Semantic Versioning with an extra digit for build package identification:
major.minor.patch.build
The first 3 parts are for source code versioning, depending on API compatibility and bug fixes (patches). The last part is to keep track of multiple build packages. Multiple builds can happen with no source code changes (therefore no changes to major.minor.patch). Reasons for multiple builds are numerous all relating specifically to Android APK packaging (such Icons missing/changed, minSDKVersion increases, permission changes, SDK updates, descriptor-file changes [we are using AIR], etc)
Unfortunately, Google Play does not recognize this 4-part version. It only recognizes the first 3 parts. Example:
2.3.1.1 - Uploaded, received warning about SDK/API min version mismatch.
2.3.1.2 - No source code changes, only bumped minSDKVersion in manifest.
As far as Google Play is concerned, both are version 2.3.1 (2003001)
Why does it matter?
In order to test In-App-Billing (IAB) purchases, a version has to be published to Alpha (or Beta or Production). Once published, you cannot upload another APK without incrementing the version. As far as we are concerned, we are incrementing the version, but Google doesn't recognize that. For us, to bump the patch number when there were no source code changes is stupid and goes against the company versioning scheme which spans many more platforms then just Google Play.
So what to do for IAB testing?
- We distribute APKs to QA internally (not through Google Play), however we are still required to publish an APK to Alpha in order to test IAB.
- Without publishing an APK with increased version number, IAB testing errors out (APK version on device cannot be higher than the latest uploaded APK in Google Play)
How do others handle this?
The first version of our app 1.0.0 was uploaded and approved by Apple and currently, it has a status "Developer Removed From Sale". However this version has severals bugs and some features are missing, so we decided not to release it, to improve it and release another version.
So, we uploaded another version 1.1.0 after some time, and currently, it has "Pending Developer Release" status. The funny thing is managing guys decided to add yet another features, so we will have to upload the third version.
The question is will the second approved app version (1.1.0) be there after uploading the third version to itunes connect, or will it be deleted? We definitely don't need the first version because there are bugs but it's unable to delete it even if it was not released to app store. But I would prefer to have the second version until the third be approved (just in case).
The current approved version will remain Ready for Sale (wether you choose to put it live on the App Store by making in available in one, some or all countries or not) while the Update is Waiting for Review, In Review, and Processing for the App Store, and will be removed when the Update's status goes to Ready for Sale. (It will also remain should the Update be Rejected.)
Is there any way to maintain 2 different versions of the same app on the iPhone? One version is the actual production build and another version is the development build which I can use for experiments i.e. UI changes
Xcode 4 allows you to create targets for your applications. You might find those useful. I use them to maintain a free version and a paid version of my apps.
http://developer.apple.com/library/mac/#featuredarticles/XcodeConcepts/Concept-Targets.html
Each target should then have a different bundle ID as this is what the phone uses to distinguish different apps. If you need a specific ID, (i.e for push notifications, game center or iads), I'm not sure on a solution sorry
You can change the Bundle ID of the development version. You can install different versions of the same app if the bundle IDs are different.
We have our source code stored in Kiln/Mercurial repositories; we use MSBuild to build our product and we have Unit Tests that utilize MSTest (Visual Studio Unit Tests).
What solutions exist to implement a continuous integration machine (i.e. Build machine).
The requirements for this are:
A build should be kicked of when necessary (i.e. code has changed in the Repositories we care about)
Before the actual build, the latest version of the source code must be acquired from the repository we are building from
The build must build the entire product
The build must build all Unit Tests
The build must execute all unit tests
A summary of success/failure must be sent out after the build has finished; this must include information about the build itself but also about which Unit Tests failed and which ones succeeded.
The summary must contain which changesets were in this build that were not yet in the previous successful (!) build
The system must be configurable so that it can build from multiple branches(/Repositories).
Ideally, this system would run on a single box (our product isn't that big) without any server components.
What solutions are currently available? What are their pros/cons? From the list above, what can be done and what cannot be done?
Thanks
TeamCity, from JetBrains, the makers of ReSharp, will do all of that. You will have to configure it for what specifically it means to "build your product", but you can configure up everything you specified with it.
The software can alert you to failed builds, even down to alerting only the person responsible for checking in code that broke the build. It even comes with handy web pages you can view to see only your own changes, which builds they've been through successfully, which ones are pending, and which ones are currently being executed.
Since it is a distributed product, you can make it grow with your organization and product. If at some point you discover that you're waiting for the build to complete too much, because a lot of builds are being queued up, you can add more build agents. The build agents are basically separate client programs you install on additional machines, that execute the actual build configurations.
It comes in two flavors, the professional version and the enterprise version. The professional version is free, can contain up to 20 build configurations, 20 users, and 3 build agents. The enterprise version has unlimited users and build configurations, and you can also use LDAP based security (think domain verified users.) There's also some other bonuses from the enterprise version. You can also buy licenses for more build agents if you need more than the initial 3.
Now, if "no server components" means you don't want it to act like a web server, you're going to be hard pressed to find something that will react to your commits.
However, if you mean that you don't want to have to install a server OS, then TeamCity can work on workstation versions of Windows as well. That isn't to say that you shouldn't consider setting up a proper server for it, but it will run on a workstation if that is what you require.
Our product BuildMaster does all of the things you listed by design and there is a free, somewhat limited edition (e.g. you can only have a limited number of issue tracking providers integrate with it, the database change script packaging tool isn't included in the free version, etc.) for 5 users or fewer.
What you've described is the basics of a CI Tool, so every CI Tool should be OK.
I use Cruise Control.NET but it is bugged with Mercurial and is not very straightforward at first glance. I am nevertheless happy with it. Other tools that come in my mind are Hudson, Team Build (from TFS) and TeamCity.
I have not tried other tools but you can see pros/cons here :
TeamCity vs CC.net
Hudson vs CC.net, Link 1 and Link 2
CC.net vs TFS
EDIT : I forgot to mention that Hudson and Cruise Control.net are Open Source project, you can easily write plugins and patches to your install.
EDIT² : Mercurial bugs seem to be fixed in the upcoming 1.6 version of ccnet (changes commited to the trunk this week).
There's always BuildBot which I like (and have contributed some code to ). It's fairly easy to set-up and run on any OS, and to do simple tasks like that you say, and remarkably flexible if you need it.
What you might find missing is batteries-included log-scrapers and/or report generators that other more commercial CI-servers comes with, especially for Enterprise-y frameworks.
It scales pretty well too, Mozilla and Chromium use it, amongst others.