Has anyone tried something like this but with OS X running in a VM? As a distributed team we would prefer not to rely on one of us physically hosting a Mac Mini. Thanks for writing this.
IIRC even virtualised the OSX license requires that OSX ultimately run on apple hardware and nowhere else. You could use a colocated host rather than having a member of the team physically owning a mini though.
Setting up iOS continuous delivery with Jenkins and Fastlane
11–20 of 27 posts
Re: Setting up iOS continuous delivery with Jenkins and Fastlane
#12Earlier quoted context omitted.
IIRC even virtualised the OSX license requires that OSX ultimately run on apple hardware and nowhere else. You could use a colocated host rather than having a member of the team physically owning a mini though.
Why should anyone care what hardware a VM runs on?
Re: Setting up iOS continuous delivery with Jenkins and Fastlane
#13Re: Setting up iOS continuous delivery with Jenkins and Fastlane
#14Re: Setting up iOS continuous delivery with Jenkins and Fastlane
#15Isn't it generally considered bad practice to put certificates and profiles in version control? Especially since you're putting your password in the fastlane files here.. does anybody have a different approach for this? because the general setup is really nice
There are Jenkins plugins available that will manage your certs and profiles for you via the web admin UI, makes it pretty to use and keeps all signing-related information out of source control. Not to mention it also manages copying these certs and keys to individual worker machines, which is super nice when you have more than one build boxen.
Re: Setting up iOS continuous delivery with Jenkins and Fastlane
#16Earlier quoted context omitted.
Because their business is the hardware?
I'm talking about why anyone not Apple should care. It's not like I care if my VM runs on a Dell or HP server.
Re: Setting up iOS continuous delivery with Jenkins and Fastlane
#17Earlier quoted context omitted.
Because their business is the hardware?
I'm talking about why anyone not Apple should care. It's not like I care if my VM runs on a Dell or HP server.
Because otherwise they're violating the terms of the license agreement which means at best they get no support and are 100% on the hook for anything breaking and at worst they're at risk of legal action?
Building a hackintosh in your bedroom is one thing, violating the license agreement of the tools you're using to do your job is another.
Re: Setting up iOS continuous delivery with Jenkins and Fastlane
#18Has anyone tried something like this but with OS X running in a VM? As a distributed team we would prefer not to rely on one of us physically hosting a Mac Mini. Thanks for writing this.
If you have Hackintosh[1] experience it won't be too difficult to manage, but if you're unfamiliar with that kind of fiddling it might be a bit of a time-suck.
All things considered, unless you're willing or interested in managing something like that and confident you won't "get caught" by Apple (e.g., if they start detecting apps built on Hackintosh systems and banning related ADC accounts) you're better off finding some other solution (maybe https://macminicolo.net?).
Re: Setting up iOS continuous delivery with Jenkins and Fastlane
#19Isn't it generally considered bad practice to put certificates and profiles in version control? Especially since you're putting your password in the fastlane files here.. does anybody have a different approach for this? because the general setup is really nice
Re: Setting up iOS continuous delivery with Jenkins and Fastlane
#20Awesome write up. I've always been a huge believer in having a great workflow.
Before starting buddybuild, last year, we were going through similar pain trying to set up CI for an app with things like jenkins and travis - so we could work in the simple way our team wanted : eg. One of us hits 'git push' - the team's devices get updated with the newest build, and we all had a quick way to give feedback on the commit.
We realised that, like us, most app developers want a great workflow, but didn't want to have to spend a lot of time setting it up and maintaining it.
With buddybuild, we've been working with hundreds of open source apps and iOS / Android developers to make sure we can automatically understand and build their apps. The setup experience is usually just selecting the repo, and we'll figure out the rest.
Our goal has always been as close to zero configuration as possible. I'm a firm believer these things should just work, and the experience should be, essentially, magical.