What I need Actually?
We create the iPhone application for Mobile & iPad and the code is always checked in to the repository.
1) When ever the code is checked in to the code repository, that has to under go the automation testing and confirm the build does not failed or the app itself will works as per teh functional test scripts.
2) If there is any Build failure, mail has to be triggered to the developers.
3) The build is sucess and automation scripts are executed and that is also passed, next step is to deploy to the apple store and submit for review, necessary information for apple store is made available in configuration files.
Existing reference in stack overflow:
Continuous Integration for Xcode projects?
**Reference**: http://stackoverflow.com/questions/212999/continuous-integration-for-xcode-projects/17097018#17097018
Continuous integration for iphone xcode
**Reference**: http://stackoverflow.com/questions/1544119/continous-integration-for-iphone-xcode
Some of other references also was checked, which just give me the idea of how to execute functional script during code checkin, which is actual works like any CI tools likes Jenkins etc.
Above said reference are also discussed during 2009/2013, which are evry old.
What is available when researched?
I came to know about using using Hudson on the mac, which is very old version and not much supportive and also found Xcode OS X Server which is a product of apple itself where the reviews are not good and implementation is not feasible for my requirement.
Please share me the the approach of how to achieve this, also is that is possible to do CI process a one touch go for IOS, I found something similar to android with few confirmation from user.
At-least execution of Tests and creating an .ipa file in ios will be great.
Related
We recently submitted a build of our mobile application and then realized that we forgot to build it with 64-bit support, which has been required in the App Store for a fairly long time.
This is easy enough to fix. It would be nice if we could catch this in our continuous integration build pipeline, however.
For this specific case, we may be able to get away with a grep command that verifies arm64 support is included in the pbxproj file.
Slightly more generally, is there a static analysis tool that would let us query the project settings files more systematically in our continuous integration pipeline? Is this, for instance, something you could detect using fastlane actions?
We create iOS and Android apps that are white-labeled. They all use a single code base (one for iOS and one for Android). Whenever we need to make changes to all of our apps (> 100 live in App Store) we rely on Fastlane. We have a "bulk" command that submits each new build to Apple, changing out config variables first and a few files so each app is unique.
This has worked well for us... but... its getting really slow. We'd love to be able to take advantage of some of the continuous development services out there. It seems like they weren't necessarily made for this use case but it might still work?
Ideally instead of running bulk on a local machine we could spin up 100 instances on something like CircleCI and they all run side by side, using our fastlane script to build, submit, etc.
We started by looking into CircleCI. The problem we are running into is they don't allow injection of variables into a job (https://ideas.circleci.com/ideas/CCI-I-690).
Is there a better service for this goal? Is there a tool that was built to achieve this? Struggling to find an alternative to hacking together a bunch of smaller tools.
I think you already identified your first step: You will have to split your fastlane (and other tooling) configuration, so it is possible to build each app in isolation.
Then you can trigger a job for each app on a CI service like for example Travis CI or Azure Pipelines (both have a simple API you can use to start jobs and give them some parameters that will be available to your job) that builds and releases the app.
All the other things (e.g. one big build vs. many small build steps etc.) are just implementation details and will depend on the individual service or tools you choose.
I've build Jenkinsfile for multibranch-pipeline as on this gist: https://gist.github.com/nysander/0911f439bca7e046c765c0dc79e35e9f
My problem is that I want to automate testing on multiple simulators and multiple iOS SDK versions. To make this work I make a lot of duplication in attached code.
Is there any way to make this work in loop and pull list of simulators / SDK's to test from some library, array, etc?
The other thing is that testing as in gist is made in sequence (when I made it parallel it broke - something like Xcode database locked)
Other issue is that tests on tests results summary are shown now 3 times every test, and if some fail on one simulator/SDK I have no idea how to know on which SDK it failed.
Any comments and help appreciated, also if such workflow is bad from the beginning.
I used to develop unit tests on Jenkins, running on multiple simulators. I came up with this https://github.com/plu/pxctest allow me to run testing in parallel, saving time as well. In your case it should be multiple simulators with different SDKs.
Regarding the summary, maybe you can export environment variables to tag every test.
Hope it helps!
How does CircleCI and other CI tools help ?
I am not able to fully understand the internals of these tools and how they help with faster deployment of apps.
Are these tools useful only for github based open source projects ? Since the testing requirements for every app is different how is it possible to seamlessly automate it using the CI tools ?
The reason you are using Continous Integration (CI) is to have a well defined build system and always a releasable latest successfullbuild.
You can also integrate unit tests or integration tests.
I think it is not only useful for github-based projects, but also for projects with projects where more developers develop in parallel.
For more information: Wikipedia: Continous-Integration
CI is a developer practice which allows them to integrate code into their shared repository several times a day along with other developers in their team.
Each time a developer checks-in code its been verified auto-build and detect errors early.
It solves issues like
long and intense builds
spend less time in debugging
build more features quickly
How it works
CI server monitors for any changes in the code repo and starts building unit & integration tests. It assigns label for each version of build and also informs the team for a successful build or if it fails, the team fixes the issue and again starts to integrate.
Quick question: If I were to set up my build server to publish to a test environment after every check-in, wouldn't that constantly interrupt the testers if the ASP.Net site they are testing would come down periodically as developers check in their changes?
We are looking to ensure the bugs we have marked as resolved are always available for testing, but we also don't want our testers to have the site come down in the middle of their tests.
Thanks!
Chris
My suggestion is to have a dedicated environment for each tester (TFS Lab is a great way to achieve this). Then allow each tester to manually kick off a build that updates their environment with the latest build whenever they desire.
If you must do a shared test environment, then I suggest not updating every build for specifically this reason, but instead doing a nightly build that updates it (and/or using a manual build that testers can run on demand).