Setting up iOS continuous delivery with Jenkins and Fastlane(labs.kunstmaan.be)
labs.kunstmaan.be
Setting up iOS continuous delivery with Jenkins and Fastlane
https://labs.kunstmaan.be/blog/ios-continuous-delivery-with-jenkins-and-fastlane
26 comments
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.
Thanks for writing this.
Yes, you're allowed to run 2 VMs per OS X license. Our entire infrastructure is set up like this using Parallels. We have the machines hosted by MacStadium, so they're available to everyone. You could also run the VMs locally, but you'll need to keep the VM image up to date.
Yes, licensing issues aside. You can setup an OSX VM on Linux that is kicked off by a Jenkins job running on the Linux host.
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?).
[1] http://www.tonymacx86.com
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?).
[1] http://www.tonymacx86.com
Why not try out a hosted mac mini solution like https://macstadium.com or http://macminivault.com? Travis-CI does all of their OS X testing at MacStadium - http://www.macstadium.com/blog/how-travis-ci-halved-boot-tim...
[I work at MacStadium, fyi.]
We can help you setup firewalls and have your hosted/rented Mac mini appear as part of your network for your team to access from anywhere.
[I work at MacStadium, fyi.]
We can help you setup firewalls and have your hosted/rented Mac mini appear as part of your network for your team to access from anywhere.
You can replace Jenkins easily with https://www.bitrise.io, but i'm not sure imagemagick and ghostscript are installed there.
[Bitrise co-founder here]
We have a fastlane integration step ;) That said imagemagick & ghostscript are not pre-installed, but you can install both with a simple script step. All of the integrations (https://www.bitrise.io/integrations) are open source and you can add your own with a Pull Request to our Step Library anytime.
You can check out what's preinstalled on our VMs here: http://devcenter.bitrise.io/docs/virtual-machines-updates
Visual Studio Online can do hosted builds of iOS apps (XCode and Xamarin). That must be running on OSX. The good thing is you don't have to mess with OSX VM's or Hackintoshes as it's fully managed.
There's also sample deployment scripts in github for HockeyApp that can be used in your build processes.
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?
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.
> I'm talking about why anyone not Apple should care.
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.
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.
If you violate the license agreement from apple there's potential for legal repercussions, and when you are trying to make money from their distribution channel (app store) it's generally better to not violate any of their rules. Especially since they don't have to give you much of a reason when rejecting or retracting your app from their store.
Isn'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
As far as I can tell the certs/profiles aren't in version control, but their paths are, and it's pretty concerning that the cert password is right there in plaintext in a file committed to the repo.
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.
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.
We store the .p12 files in git with a fairly long password. Using CircleCI we are able to put the password in as an environment variable which is non-readable through the admin UI once it's set.
I had the same thought. Seems like Chef would be a better fit?
I was thinking about doing this with TeamCity (I don't trust myself to get security settings right with Jenkins).
I'm worried that Apple will just shut it down though.
Also does anyone have any recommendations for hosting stuff like this? I'd buy a cheap Mac Mini or build a hackintosh but It can't go out of date as Xcode often requires the latest OS version.
I'm worried that Apple will just shut it down though.
Also does anyone have any recommendations for hosting stuff like this? I'd buy a cheap Mac Mini or build a hackintosh but It can't go out of date as Xcode often requires the latest OS version.
We use two Mac Minis with Teamcity at my current job and it works great.
Every once in a while I VNC in and update Xcode/OS X. That has never been an issue.
Every once in a while I VNC in and update Xcode/OS X. That has never been an issue.
We run Jenkins on a Mac Mini located inside our office. It works pretty well. Easy to VNC in and update it when required.
Setting up a Jenkins Slave is pretty easy as well, if it needs to run alongside an already existing Jenkins installation somewhere else:
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+buil...
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+buil...
Does anyone know what the terminal colour scheme is on that page? (this one: https://labs.kunstmaan.be/uploads/media/5654b5aa96880/06-fas... )
This fastlane tutorial was also published yesterday. It might also be of interest.
http://www.raywenderlich.com/116065/fastlane-tutorial-gettin...
http://www.raywenderlich.com/116065/fastlane-tutorial-gettin...
Why not use OS X Server with Xcode bots and the CI features that offers?
Not saying Jenkins and Fastlane is bad (it sounds great actually, and nice writeup!) but curious what people see as missing in the Apple tools.
Not saying Jenkins and Fastlane is bad (it sounds great actually, and nice writeup!) but curious what people see as missing in the Apple tools.
[deleted]
Awesome 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.