023 iPhreaks Show – Build Automation with Patrick Burleson
Show Notes
Panel
Patrick Burleson (twitter github blog) Rod Schmidt (twitter github infiniteNIL) Ben Scheirman (twitter github blog NSSreencast) Andrew Madsen (twitter github blog) Jaim Zuber (twitter Sharp Five Software) Pete Hodgson (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)
Discussion
00:27 - Going Rogue Video
00:42 - Patrick Burleson Introduction
00:27 - Going Rogue Video
00:42 - Patrick Burleson Introduction
BitBQ MartianCraft Briefs
01:23 - Build Automation
02:10 - Continuous Integration
02:10 - Continuous Integration
Changes xcodebuild Ben: Running objective-c tests from the command line (with color)
07:51 - Testing
xctool
10:29 - Automation on a development machine
11:04 - Things to Automate
14:14 - XCode 5 Build Automation
20:08 - Automation
11:04 - Things to Automate
14:14 - XCode 5 Build Automation
20:08 - Automation
Bamboo Version Numbers agvtool cupertino (and friends)
29:50 - Certification
33:21 - Build Time
33:21 - Build Time
Screenshot Lightning guard-xctool-test
Picks
iOS Background Fetch example (Andrew) sprint.ly (Andrew) ASCIIwwdc (Ben) Blues Junior™ III: Hot Rod (Ben) guitarjamzdotcom (Ben) iOS 7 by Tutorials (Ben) Pappy's Smokehouse (Pete) Go (Pete) Bombay By Boat - Moonlight (Pete) xcoder (Pete) xcodebuild-rb (Pete) Paulaner Oktoberfest Bier® (Jaim) Pitching Radar (Rod) Rich Hickey (Rod) ShareMouse (Chuck) Tweetbot (Chuck) Michael Vey (Chuck) Fogo de Chao (Patrick) Briefs (Patrick) Black Bar (Patrick) Test iOS Apps with UI Automation: Bug Hunting Made Easy by Jonathan Penn (Patrick) Bamboo (Patrick) Alfred App (Patrick)
Next Week
64-Bit with Mike Ash
Transcript
64-Bit with Mike Ash
Transcript
CHUCK: Hey everybody and welcome to Episode 23 of the iPhreaks Show! This week on our panel, we have Rod Schmidt.
ROD: Hello from Salt Lake!
CHUCK: Ben Scheirman.
BEN: Hello from Houston!
CHUCK: Andrew Madsen.
ANDREW: Hi from Salt Lake!
CHUCK: Jaim Zuber.
JAIM: Hello from Minneapolis!
CHUCK: Pete Hodgson.
PETE: Hello from a very warm conference room.
CHUCK: I’m Charles Max Wood from DevChat.tv. Before we get going, I want to briefly just remind you that I have put up the GoingRogueVideo.com, where I put up the video talking about how I went freelance. If you’re interested in that, you can go check it out there.
We also have a special guest, and that’s Patrick Burleson.
PATRICK: Hello from Dallas, Texas!
CHUCK: Do you want to introduce yourself since you haven’t been on the show before?
PATRICK: Sure! My name is Patrick Burleson. I run BitBQ software, which is BitBQ.com. I also do quite a bit of consulting with MartianCraft, and also MartianCraft.com – they are the makers of the design application called Briefs.
CHUCK: Cool!
BEN: That was a previous pick of the show!
CHUCK: Yup!
PATRICK: Awesome!
PETE: We should do an episode about Briefs.
PATRICK: You should! I will probably get your wrap on the show.
CHUCK: That’d be awesome. Then we could do one on boxers.
BEN: Yup, quite a history.
PATRICK: Yes, Briefs has a very long history.
CHUCK: That’d be really interesting. We brought you on to talk about “Build Automation”.
PATRICK: Yeah! Build Automation is something that I think everyone should probably definitely look into even if you’re on a team or even a solo developer. That sounds crazy to some people why would a solo developer want to have a build automation…The way I look at it is, on my solo stuff, I want a computer doing as much of the work as I can make it to without me having to get in the way. Automating your build is one of those things where with a click of a button, I can update and ship a new version of any of my products or ship out a beta or whatever. It makes it very, very easy and also reduces the number of mistakes you can make. You don’t have to do anything manually; there’s a chance for a mistake.
CHUCK: So it’s just kind of like continuous integration?
PATRICK: Yeah, it is a lot like continuous integration. You can use it 2 different ways.
Transcript
CHUCK:
Hey everybody and welcome to Episode 23 of the iPhreaks Show! This week on our panel, we have Rod Schmidt.
ROD:
Hello from Salt Lake!
CHUCK:
Ben Scheirman.
BEN:
Hello from Houston!
CHUCK:
Andrew Madsen.
ANDREW:
Hi from Salt Lake!
CHUCK:
Jaim Zuber.
JAIM:
Hello from Minneapolis!
CHUCK:
Pete Hodgson.
PETE:
Hello from a very warm conference room.
CHUCK:
I’m Charles Max Wood from DevChat.tv. Before we get going, I want to briefly just remind you that I have put up the GoingRogueVideo.com, where I put up the video talking about how I went freelance. If you’re interested in that, you can go check it out there. We also have a special guest, and that’s Patrick Burleson.
PATRICK:
Hello from Dallas, Texas!
CHUCK:
Do you want to introduce yourself since you haven’t been on the show before?
PATRICK:
Sure! My name is Patrick Burleson. I run BitBQ software, which is BitBQ.com. I also do quite a bit of consulting with MartianCraft, and also MartianCraft.com – they are the makers of the design application called Briefs.
CHUCK:
Cool!
BEN:
That was a previous pick of the show!
CHUCK:
Yup!
PATRICK:
Awesome!
PETE:
We should do an episode about Briefs.
PATRICK:
You should! I will probably get your wrap on the show.
CHUCK:
That’d be awesome. Then we could do one on boxers.
BEN:
Yup, quite a history.
PATRICK:
Yes, Briefs has a very long history.
CHUCK:
That’d be really interesting. We brought you on to talk about “Build Automation”.
PATRICK:
Yeah! Build Automation is something that I think everyone should probably definitely look into even if you’re on a team or even a solo developer. That sounds crazy to some people why would a solo developer want to have a build automation…The way I look at it is, on my solo stuff, I want a computer doing as much of the work as I can make it to without me having to get in the way. Automating your build is one of those things where with a click of a button, I can update and ship a new version of any of my products or ship out a beta or whatever. It makes it very, very easy and also reduces the number of mistakes you can make. You don’t have to do anything manually; there’s a chance for a mistake.
CHUCK:
So it’s just kind of like continuous integration?
PATRICK:
Yeah, it is a lot like continuous integration. You can use it 2 different ways. Continuous integration typically include unite tests and integration tests with the run. Or, if you don’t have unit test, just doing a build does your stuff compile. Does it make a correct build that you could ship a lot of test that you can run in? A lot of my builds where I’m still adding unit tests to the apps, some of them are just building the app and make sure I check everything in right, which is pretty common. It’s amazing you own or you work in by yourself; you throw and create the image scene, where it’s going to work great on your other machine if you switch to it. Then some of like a build server helps you catch that in this checking in a file or something, or you forgot to check in a submodule update or something like that that would have bitten you or a team member down the road.
BEN:
It’s amazing all the things you’d find it if you will just jump on a brand new machine and install all the things you would think you’d need and then trying to check out your project and run it, and you’d probably missing one or two of those things…
PATRICK:
Changes is one of my products. It was really funny I switched to another machine and it wouldn’t build, and I couldn’t figure out why. Actually, we’re setting up Jenkins for it, it’s what exposed this. It turns out, it had a couple of hard code or paths for where stuff should be. When you’re building up a Jenkins, that path is not the same anymore. So it helped me find quite a few issues in the build for that when I was switching it over to be automated, so I love that stuff.
CHUCK:
One thing that I’m wondering about – you’re talking about Jenkins and some of the other CI Systems – because most of these, you have some kind of command-line interface or commandline command that you give it to do stuff, and that’s how Jenkins and a lot of these others work, is there a way to build your app from a command-line?
PATRICK:
Yes. It was 10 projects for iOS; Xcode has a command-line interface called “xcodebuild”, which takes a bunch of parameters. It’s been pretty easy to do. If you just want to test it in your current project, you can change to the directory of your project on the command-line and just type xcodebuild. That will take your default target with the default configuration of release and build it. You can change all of that if you do an xcodebuild -help. It gives you a lot options like changing which scheme to build, which target to build, which configuration to use, and you can overwrite all of those things.
BEN:
Architecture.
PATRICK:
Architecture, yeah, and you can say do a ‘clean’ in a build, and stuff like that.
BEN:
Yeah, I would definitely recommend a Clean Build just to make sure that you’re starting from a clean slate every time.
PATRICK:
Yeah. You definitely want to use a Clean every time particularly with nib and image changes. Xcode doesn’t always pick those up, that something has changed.
BEN:
Do you have any like tips for like spotting errors in the waterfall of output of text that xcodebuild gives you? Because sometimes, I’m a little inundated by log statements and it’s hard to find out what was the actual error.
PATRICK:
Mostly, I just scan back personally. Usually, the errors are pretty obvious; they’ll be underlined in the output. The output generally puts a little underscores under, it’ll have arrows where it’s pointing to, “Hey, here’s where your error is.” Some of them can be cryptic, like one in particular quote sign has its own fun set of issues. One that most people don’t know is if you’re quote signing right now, if the quote sign binary can’t reach the internet and the Apple time server, it fails to sign. It gives a somewhat cryptic error message about unable to match the time or something like that. Their time server went down about a year ago for a little while, and it happened to be the night I was setting up Changes for the first time in Jenkins, and the build kept failing and I couldn’t figure out why. It turns out that the time server was down. Another common one there is quote sign – I might say that first in Jenkins stuff, but something specific, I most suggest scroll back – if you were to copy that into like a text file, you can grep for error and you generally find it.
BEN:
I had a little hacky solution for this. One of those was to run it through a Ruby script that could use the Popen library to – it was one of those libraries you can pipe stdout through this program and then grep on all the lines and color them red if some condition is met, so I would grep for like error: or whatever. If you grep for error, you’re going to get all of the -w error flags that Xcode uses to compile all the files. But there are some other patterns that you could choose to run so I would do that for test failures and build failures so that I could quickly scroll up and look at like actual red text, which is pretty handy.
CHUCK:
Hah!
PETE:
There’s a couple of Ruby gems that will do the kind of wrap xcodebuild and will you give you nice code, nice app as well. I think the CocoaPods, one of the gems that’s built by the CocoaPods guys does – I can’t remember if that does xcodebuild stuff or just it just does like messing your projects – but I think that one of those guys will do the same thing; it’ll give you nice output, but isn’t just a worthful of nice. If you use xctool, then you get nice output from that as well rather than xcodebuild.
CHUCK:
So do you run the build to actually build the app and then another build to build the tests and run the tests?
PATRICK:
Here’s what I’m going to expose, I don’t have a lot of unit test yet so I don’t run those much. I’m trying to remember what you do…I think you can pass xcodebuild a test parameter…I’m going to type real quickly and find out.
BEN:
I think it’s a Test After Build, yes…
PATRICK:
Yeah.
BEN:
But it depends on how your project is set up. I just tried the Suite Xcode 5, and it’s slightly different now.
PETE:
No surprise.
CHUCK:
[Laughs]
BEN:
Yeah. [Chuckles] One of the things that really annoys me is that on some of my projects, because they were started around in the Xcode 3 where Xcode 4 a timeframe, have different settings in them. So depending on how your project setup, test after build might work, or you might have to create yourself another scheme that is the test scheme, in which case, you would run just build.
PETE:
Yeah. And it really depends how you set up your unit test. If you’re doing like a total stock way that Apple expect you to, then maybe xcodebuild will work. But if you’re doing it in different way, then you’ll probably have to do some tweaking.
BEN:
I will say that xctool from Facebook is, they give you a test command, so it’ll just like you had clean and build then you also have a test, and I think it will use it out for you.
PETE:
Yup. That’s what I was about to say.
BEN:
It worked on my quick test on like side projects. So far, that has been fruitful.
PETE:
I think Facebook are doing a better job of maintaining the command-line testing stuff than Apple are doing ironically. [Crosstalk]
BEN:
I was going to say what happens if you have a test that has the test host flag set so that you should kick off the simulator and run? But Apple scripts, at least as of Xcode 4, would specifically tell you, “Nope, that’s not supported,” even though I have never seen a reason why it couldn’t work. If you run the simulator manually, it just seems like every step of the way, we’ve been fighting to framework and things changed with every version of Xcode. So I’m kind of glad that somebody is taking up the helm of making this stuff run with a consistent command-line interface.
PETE:
Yeah. It seems like it used to be, every time a new version of Xcode came out, stuff would break and then there’d be like 4 or 5 different work around, different random pick logging internet with post, so it’s kind of nice. I feel like xctool is just a nice place for all that stuff to live so that we don’t have to all figure all of those they’re doing; test automation don’t have to figure it all out by hand by splunking around blog post and all that stuff.
CHUCK:
So do you do any automation on your actual development machine?
PATRICK:
Yeah, I do. I have scripts and stuff in my primary projects so that it’d do common tasks. One in particular, I actually have a rakefile that does stuff like runs mogenerator with all the options I want to run to it and does other things for me. Usually, if I end up of self-scripting it, I tune to rather rake thing for it; this thing I’m going to do more than once.
CHUCK:
Yeah, that’s something that I find that I do a lot in my projects as well.
PATRICK:
Break, it’s not just for Rails.
CHUCK:
[Laughs] So what sorts of things do you automate? You mentioned one, but are there other things that you can tell us about?
PATRICK:
There’s a project I’ve worked on where it has a lot of localizations and I get updated strings files from the client. And when you’re talking about 12 localizations, doing that by hand is such a pain so I have a script that copies them over and runs ibtool on everything and then deletes all the unnecessary files, and then gets out of there. It loops every language in which ones have files that have changed and all that. That’s one in particular and it saves me a lot of time. Luckily, I don’t have to automate a whole lot because most of the projects don’t have a lot of funkiness like that.
BEN:
How do you handle localization for like an app that you add a new button and you’re like, “Oh, crap” that I really want to add a button. Maybe I’ll just use [unclear].
PATRICK:
Oh, that’s what I say.
BEN:
[Laughs]
PATRICK:
I say a lot of crap if I got to add this; I got to make this change in full…Oh, you’re kidding me.
BEN:
Yeah, that’s one of the reasons why I was [unclear] like all the icons of buttons went away next in iOS 7 because you’re like you know and you then localize like all kinds of other things in my app.
PATRICK:
There’s the pros and cons for doing everything in just a localizable strings file and doing it all in code, and then also doing it in nibs. Because sometimes, there were couple of languages that needed different UI layouts, they needed to be tweaked so that they could be a little bit wider to show more text…
BEN:
[Coughs] German.
PATRICK:
[Clears throat] Russian.
[Laughter]
PATRICK:
In that case, it was nice to have a nib specifically say, “Hey, what else should I going to do this?” where I didn’t had to like go into code and be looking hard coding looking for Russian. So that was nice. The double edge sword, I think some of that stuff is just painful. I don’t know of a better way to do with it with the tools currently available. But that’s certainly an example of something I do. Another one, I use FastScripts for one specific thing right now – clearing the drive data is the key command on my keyword. It runs a FastScript that runs rm -rf Xcode deriveddata for me; I hit that maybe once or twice a day. It’s just very nice.
BEN:
That’s hilarious.
PATRICK:
[Chuckles]
CHUCK:
[Laughs]
BEN:
I haven’t needed to do that in a long time –
PATRICK:
It has gotten a lot better. Xcode 5 has actually made that almost unnecessary, but it sometimes –
BEN:
There’s somebody run an Xcode plugin where they put a button in the toolbar of Xcode to do that. I was like, “Oh!” it’s just facepalm.
PATRICK:
Yeah, tele-face-palm.
CHUCK:
[Laughs]
PATRICK:
Actually I use Fish Shell as well. And Fish, for a member is like in those the last commands you typed. So as you sort of type them again, it offers to complete the whole command as the way you typed it last time. And it got to the point where you’re just typing R offered me as my completion R -rf…
BEN:
[Laughs]
PATRICK:
Library developer. So I thought that was sort of funny.
BEN:
Yeah. I copy the Brian Simmons’ script. He had a like a [unclear].
PATRICK:
Yeah.
BEN:
Something like that.
PATRICK:
Day-to-day [unclear], various stuff like that.
BEN:
I still have it in my Bash aliases.
PATRICK:
I created a FastScript and assigned some crazy key combination to it.
BEN:
Xcode used to just choke on indexing and like lose syntax highlighting and code completion and stuff, and I wouldn’t have to go and delete that.
PATRICK:
In Xcode 5, I don’t think I’ve actually had to do it with Xcode 5 that I remember at this point. It’s mostly just when I go back to Xcode 4.
PETE:
Speaking of Xcode 5, have you had a chance to check out the new build automation stuff?
PATRICK:
Only briefly enough to know that it was so broken, I couldn’t use it.
PETE:
Okay!
PATRICK:
I’m sure you’d be happy –
BEN:
That’s reassuring?
PATRICK:
Yes.
[Laughter]
PATRICK:
I don’t know how much it is to break the NDA to go – I know that it’s released…
BEN:
That was my NDA anymore.
PATRICK:
Well, with all the seeds --
BEN:
Or, you’re talking about average stuff?
PATRICK:
I’m talking about developer seed notes about like one of the late seeds, there was like, “Yeah, SSH key checkout doesn’t work.”
BEN:
That’s kind of important…
PATRICK:
That’s sort of important for like at how I check on all the code…
BEN:
Yes.
[Laughter]
PATRICK:
I really don’t have a chance to look at it. I really want to because it would be really nice because there’s some kind of aggression there that they’ve got. Watching the WWDC sessions, I was very excited about it. But when impracticality right now, it’s just something that’s still in my radar to go keep an eye on and see if it gets better.
PETE:
Is it wrong of me to think of this Apple stuff was the TFS for Xcode?
PATRICK:
Probably not.
BEN:
You mean like nobody would want to use it?
PATRICK:
[Laughs]
PETE:
Like reinventing a wheel that sort of you can solve better somewhere else.
BEN:
Jenkins is disgusting to look at. I only stick with it because it’s got a great community behind it.
PETE:
Yup, that’s true.
BEN:
And it seems to support everything I want to do so it’s functionally really awesome. But it’s really gross UI and we get to use obscure Java errors from it every once in a while where I have to go change how I launch it to give it more virtual memory and all this crap that I’d rather just use something that’s kind of more integrated better experience; the buildbot dashboard thing is really sexy looking. But I wonder about all these other things we’re talking about. We’ve talked about like compiling and running tests, and those are 2 things that the buildbot should help you with, unless if any of this stuff is public. But I assume some of the build stuff is –
PATRICK:
I know that Xcode 5 is out, although I guess technically, the server side of that is not out.
BEN:
There’s a menu called Buildbot, and it does something that I might be talking about now. [Laughter]
BEN:
Anyway, there’s other things like archiving the build like zipping up dSYMs and submitting to TestFlight or HockeyApp or whatever. If for a Mac App, you might be uploading to some place and…I don’t know what you use for auto-update like Sparkle or whatever. There’s other things, too, like maybe taking the App Store screenshots like some of the other automation you might do. If you could imagine what that would be like if Xcode was doing your CI, all of it would have to be in like FastScripts inside of your post-build block. To me, that seems like it would be really annoying to manage.
PATRICK:
It’s so funny that I actually do that with my Jenkins stuff – all of my post-build stuff is scripted out mostly. I use a couple of plugins, but I’d like to have it pretty portable and I have them as Bash scripts that just Jenkins runs. [Crosstalk]
PETE:
I think that’s a really good idea to say that. I think all of those plugin things are useful, but then (a) are totally locked in to Jenkins; and (b) the only that you can test stuff is running a build on a Jenkins machine rather than just running a script on your language.
BEN:
I’m totally in like violent agreement with you guys. I don’t like the plugins at all. Most of them are poorly written so that they might not support some scenario that you need. But you need to know how these scenes work anyway. You need to know how to make an IPA from a command-line, and that sort of thing. But what I mean is like if it fails to build, I want to notify people. [Crosstalk]
PETE:
That’s the thing I can’t imagine Apple will ever put into whatever tool they build – it’s like nice test reporting and the thing that says, “This test file is the most frequently,” or “This test is the longest running test in your system,” or “Here’s a nice HTML report showing all of your test results, they’d just never going to do that.
BEN:
And the list gets longer. All they like [unclear] task that I do for like a Rails project like running Breakman so that I can see what gems might have known security vulnerabilities. There’s no reason why that same type of code analysis couldn’t be in Xcode, right? Like with the ocLink project, you could say “I want to fail the build if the cycle matter complexity of any method gets beyond some number. Or, if I have a method that takes 15 arguments or whatever, that like when one just fail a build and fix that problem now. [Crosstalk]
BEN:
Yeah.
PATRICK:
I feel like I’m doing enough other build stuff that I’m not sure if I ever be able to go fully to the bots for Xcode. But I could see to nice to have them as like a quick – from what I run now, most of my Jenkins installs for every project, there’s a periodic build that grabs the code every 15 minutes. Our [unclear] and looks for changes every 15 minutes and runs a build just to see if we’ve broken anything. I think Xcode bots would be good for that, but there are so many other things I do that wouldn’t fit in the Xcode model.
PETE:
I think it’s kind of interesting that Jenkins has like such a big ecosystem around it now that it’s quite hard to displace it. ThoughtWorks has a couple of CI tools or CDCI tools and I think one of the biggest barriers to entry is they don’t have all of the secret system and tooling around it. So the first thing that we try and use it’s like, “Oh, how do I do output? How do I get test coverage support,” and all that stuff; it’s hard to rebuild all that stuff from scratch.
CHUCK:
Just out of curiosity, what are all of the things that you have Bash scripts or what have you to automate in your system?
PATRICK:
Popping the version build number, setting the version number of our products, then committing that, and then also have scripted out, copying out, assuming out things like Sparkle a bit of feeds – we have one particular one where if we’re doing a beta build, it updates the beta websites with all the release note changes we’ve committed. What else have I automated? We have redacted build of something that updates since another file and Hockey, actually, it’s the Hockey plugin unfortunately; I don’t want to script that out as a script. One of the reasons I’m building other scripts is actually, I want to switch to Bamboo from Jenkins from my stuff. So my [unclear] on a plugin is going down; it has more to do with that and a lot of things. But we commit back to the version numbers that we’ve submitted once the build succeeds so that we get those and it already has the latest build number in their apps.
BEN:
That’s a good point to touch on. I struggle with that a little bit like when you want your official versions to be rev by like a valid build, then it’d be coming from your build server, which means you need to give your build server permission to check in code.
PATRICK:
Yeah.
BEN:
So at some point, you guys are okay with checking in version numbers…
PATRICK:
Yeah, we have checking of version numbers, and it has its own SSH key, which we can revoke if our build server ever get compromised.
PETE:
Wait, why do you need to check that in?
PATRICK:
The reason we check it in is that, we have 3 builds for each product. We have the Periodic Build which I mentioned earlier, we have the QA Build, and we have the Production Build. Production build builds it for the App Store or for shipping to the website or whatever. So periodic build don’t touch the build number; they’re just there to tell us that, “Hey, everything is still building.” QA is the only build that bumps the version number. So anytime we always do a smoke test build or our designers are kicking off a developers [unclear] done, go get a QA build that bumps the build number. We keep a text file for product that is the version number, and there’s a script that reads that and changes it in the Plist if necessary. Then we do our production build, that production comes off of our master branch. We have 2 branches: we have master and develop. Develop is where we’re doing all of our changes of everything, and master is where production comes from, so master builds are always the last QA build number that we’ve vetted. We do a smoke test build before we go for release, and then that becomes our last build number. That needs to be committed back so that we can merge it to the other branch, and then everybody gets the latest build number from the server. Does that make sense?
BEN:
Okay.
PETE:
I think so. Kind of like simulating a build pipeline using CI I guess so you’re kind of keeping track of the progress of your kind of build through a pipeline, through –
PATRICK:
Right. And the build number happens to coincidentally matches Jenkins build number so we can go back and get the dSYM and anything we need. If something gets a crash from our designer, we can go symbolicate it with that dSYM.
PETE:
Got you.
BEN:
I think that’s a really good thing to focus on for a second. Like, having one of your developers do build for TestFlight or HockeyApp or linear archive build whatsoever, App Store or whatever, the dSYMs end up on their machine and they need to go somewhere else and live for a while. The build server has put a place for this because you don’t want to have that person like quit or move on to another project and they got to go track them down so you can find all dSYM file.
PATRICK:
Yeah. So we don’t upload every dSYM to Hockey or apps we upload to Hockey of the script that does that also uploads the dSYMs so hockey can do symbolication as well. So I definitely agree that you need of …For the longest time I had – I was building a client project and I had all the dSYMs, and I hated that because that means that I’m going to send them out to people. So we’re working as a remote teams, all work in different schedules in the middle of the night, somebody might need that dSYM, they couldn’t get it. So having a launching consistency has helped that quite a bit. To help you with the version and number thing, there’s actually a tool Apple ships for projects using their stuff called agvtool that will set the version number for you. It automatically increment the build number for you, or you can set it. I pull it from the Jenkins environment, but it can also pump it by itself. I’d say the only downside of that tool is that if you have a bunch of targets in your project, they all share the same build number. I think that is a bummer because sometimes, I don’t want to bump every target’s build number if I’m only building one specific target.
BEN:
What do you do when a new tester comes on board and they register a new device or you get a batch of iPhone 5S’s for the office? What’s your process for getting those added to the portal and creating a new profile, ad hoc profile that includes as the devices?
PATRICK:
The way I do it is that I get them all registered to Hockey; going to Hockey, export those devices, and upload the file to the portal. I know there are some command-line tools to do that; I just find that to be more orneriest than just getting a text file from Hockey and uploading it. So I put them on instead of people to register their device; save me time.
BEN:
Yeah. I think, I use TestFlight, but this similar thing is a really good way of getting somebody signed up when it automatically gives me the device information. But you could look at Cupertino if you want to list and add devices if they don’t already exist in there. That way, you might have just like one [unclear] list of devices in your project that you check in, and you can just run that like on every build perhaps. [Crosstalk]
PATRICK:
I looked at the do note Cupertino and maybe I’m too dumb or maybe it has changed, but at the time I was looking at it, I couldn’t automate it because it prompted for passwords and for all sorts of other things that I couldn’t figure out how to get it to stop prompting so it would stop (the script) midway.
BEN:
Yeah.
PATRICK:
On the build server, that’s kind of bad.
BEN:
Yeah [laughs]. I haven’t actually done that yet.
PATRICK:
That’s what I really want it to do; want it to automate and just have it always have the freshest provisioning profile. But instead, I scripted out, reassigning a build with a new profile instead, and re-uploading that to Hockey. I find that’s easier than trying to use Cupertino. I don’t know if it has changed; I need to check into it a little more frequently, but I’m also been a lot to do and have their problems solved. So occasionally, I’ll revisit it if I want to try and get better right now; it’s working pretty well for me.
BEN:
So if you do this process manually and then you generated a new ad hoc profile, do you check that into your repository?
PATRICK:
Yes. We’ve all those checked into our repo, and then part of our build copies it to the right spot in Jenkins. We have library mobile devices provisioning profiles, I think it’s the folder.
BEN:
Yeah, and you got to like grep out the UDID out of the file.
PATRICK:
Here’s a magic trick: you don’t have to – well, I guess if you’re updating it; we also put update – we check in the project into the project file which one is used for ad hoc and probably production build.
So anytime I’m updating the profile, I update the project as well.
BEN:
Okay. PATRICK: So as long as the file is out there, it’ll find it. If you just copy it to that folder with its name you gave it as it comes down where it as, it’ll work just fine. You don’t the [unclear].
BEN:
Okay. Yeah, I had it come off as Hockey thing. Like, the file is binary, but there’s like ASCII text in it so you can grep for the UUID pattern.
PATRICK:
It’s a sign of binary. Jay Graves at Double Encore, he taught me any trick – you can actually read and verify that. He has a post on how you do it on his website, and I’ll add it, give it to guest and give you the show notes, but it’s really neat. Just double check to make your profile as valid; it gives you the openness to sell command-lines to decrypt it or to verify it, and stuff like that.
BEN:
I remember at one point, somebody had like a quick look plugin that would let you like view the devices inside of one of those.
PATRICK:
Yeah, I use that a lot. Actually, I had one installed still. I’ll just double check it and see if it makes show up the device IDs I expect to be in there, or list the ones I just added in there before I upload it up to Jenkins – well, upload it and commit it and then gets uploaded to Jenkins. But yeah, there’s certainly something that that could be better. I think it’d be nice if Apple provided a way themselves. I know that there’s some iTunes connect to command-line stuff now; it’d be nice if we got some device profile and certificate management command-line stuff do. So that’s something to like, I love Cupertino and it’s [unclear], brilliant. But, it’d be nice if we didn’t have to have someone hacking around a solution like that.
BEN:
Right. Yeah, I agree. What about when your certificate expires and you have to download a renewed one? What’s that process like?
PATRICK:
For me, right now, that process is a little painful. I have a Jenkins-specific keychain that we upload
to the server, and then I have a copy of them, there’s a copy in the repo in which that gets a certificate in there. But going back to Jay, he recently had a talk at 360iDev, and I learned a trick from him at that talk that I’m going to start implementing where you have a keychain per project and you can have xcodebuild unlock that keychain, or you can unlock that keychain and use it in the middle of your build, and then close it at the end so that as long as you keep that keychain up to date in the project, you don’t have to do anything else, and you just put it [unclear].
BEN:
That is a pretty cool trick.
PETE:
And you can use a password on that as well, I think.
PATRICK:
Yeah, we recommend it as well, that you put a password.
PETE:
If you want to use like Travis or something to do this stuff, then you can check in the keychain and put it in source code and kind of have it not be too sketchy because you’ve got a secret password that if someone gets hold of your –
PATRICK:
Right. The only sort of sketchy thing you need to do is that you need to give the private key “Allow all access” that if you right click on the private key and get info, there’s a dial up that comes up and you need to choose “Allow all applications to access this item”. Otherwise, when quote sign tries to get it, even when you’ve unlocked the keychain, there’s a prompt that which should be showing. But since you’re running headless, you’d get the lovely “User interaction not allowed” error from quote sign, which basically means that it needed to prompt to access the keychain, and it was running headless so...
PETE:
Uhm-hmm.
PATRICK:
That’s the one Jenkin thing you need to do. It gives me a little bit less secure, but I think, overall, at some point, you got to trust your build server. And generally, you’re running it inside your firewall so, at some point, you got to just skip on your network a little bit.
PETE:
That’s less true if you want to use something hosted. I guess that’s pretty obscure for Apple development to use a hosted CI thing.
PATRICK:
Yeah. There was one out there.
PETE:
There’s a few.
PATRICK:
Yeah.
PETE:
There’s Buildozer and there was that one that I assume got shut down by now where you just upload any IPA –
PATRICK:
They were abusing their enterprise such a bit, yeah.
PETE:
Yeah.
PATRICK:
Their enterprise is I think they get rid of.
PETE:
Surprising.
PATRICK:
It’s a shocker!
CHUCK:
[Laughs]
PATRICK:
I call that the moment I saw that like, “This is going to last like a week,” and it last that. For me, it’s a very personal thing. I want to have as much control on the machine as possible because it also got client source code on it. But I have some contractual obligations to not ship and struck up. I think those would be great for open source projects and stuff that it would be nice to just be able to build them. If it’s something you need, you just pull off GitHub, that’s great. But in general, I’m a bit of a control freak when it comes to my build machine. I wanted to know that it’s something I can control. Then granted, one of my clients, their build machine is hosted at Macminicolo, but we still control the machine.
PETE:
I guess that’s a good random question, does everyone just use Mac Minis for this stuff? Or, is it worth like having like something beefy like Mac Pro?
JAIM:
Probably not.
BEN:
Are you looking for our permission for you to buy a Mac Pro? Because then, ‘Yes, you need one’.
PETE:
Okay. '
BEN:
You need one.
PATRICK:
You need the new one.
BEN:
Yeah, the new one. You have to have it [laughs].
PETE:
Maybe for my builds.
BEN:
We have 2 Mac Minis at our office; one of them is one of the new SSD or the fusion drive ones. It’s got 16 gigs of RAM so we have the host Jenkins use that as like a worker or a note or something…
PATRICK:
Build slave or something like that.
BEN:
Yeah, build slave. It’s cool! You don’t even need to install Jenkins on the other machine…
PETE:
Yeah, it’s pretty magical.
BEN:
You just give it an SSH key so it can log in and it will do the remote Java Web Start like voodoo, and somehow, our builds run on the other server, which is pretty cool. So if you have a Linux box and a Mac Mini, you can have them coordinate and say, “I want all my Rails builds to go on the Linux box, and I want my Mac builds to go on the Mac Mini.”
PETE:
Yeah.
PATRICK:
Yeah.
PETE:
So pro tip for that, if you do have either slow tests or particularly slow compilation, you probably don’t get so much for iOS. SSD is help, but just building I think on a RAM disc, it can have like an orders mango cheats improvement in your compilation time. So you just make RAM disc for all of the files in your RAM disc, and then compile from that because actually, a lot of compilation is reading source code and then RIOT in source code, or writing by means. So that can help.
PATRICK:
Truly, most of our builds, there are couple of minutes so I don’t get to spend a lot of time threading and direct it; its automated and it’s going to be done in a couple of minutes and it’s just kind of out of my hair already.
PETE:
Yeah.
PATRICK:
I get an email in 15 or 10 minutes later…“Oh, good, it’s done.”
BEN:
I just got more HipChat build notifications success after 29 minutes – this is for Rails project, that it has a bunch of tests.
PATRICK:
That’s a bunch of tests, yeah. I think my average build time is easily under 5 minutes for everything, and I think that includes uploading it to wherever. One of our QA Build, it doesn’t take very long at all.
CHUCK:
That’s fairly ideal. I mean you want that fast feedback so you can fix issues while they’re still fresh in your head.
PATRICK:
And if you have a lot of tests that’s at place – I was had it at TFS, one of our builds started taking like an hour, and that was sort of a bummer because we had gated check ins where your check in didn’t actually make it to where other developers could have it until it pass the tests, and our build queue would grow and I lost it; it’d be like, “Where is that change?” and I was like, “Well, it’s in the build queue.” That’s when we started looking at the performance of our tests to see if what we could do there; it helps us find performances used in our code. But overall, your Mac Mini is where I run my stuff on.
ROD:
So if you’re a solo developer, is it okay to do all these on one machine? Or, do you really need to have another machine?
PATRICK:
I haven’t actually – for a long time, I’ve been running it on my iMac in the background, my main iMac, for doing builds, and it’s no big deal; my iMac is pretty fast at it. As a solo developer, you can start with what you have and then keep an eye out for; you used Mac Mini if you want on Craigslist or something or whatever in your country – it’s the fast way to find used stuff.
PETE:
And what does they say like CI is a practice as much of a tool, so you can just do it like from the command-line before you check in code. If you’re the only person doing it, then there’s less of a need to integrate across different developers obviously. There’s just one of you, so you can just have a rake tile score or shell script or whatever that does your CI and just run that before you check stuff in. I guess it means you have to wait for 5 minutes and watch it build.
PATRICK:
And also, you should remember, you had the member to do that and stuff. It’s a lot like Jenkins has my memory to do things…
PETE:
Yeah.
PATRICK:
So any step I can automate in there, I’d try to add it. And it’s something where this stuff changes, too, and things were added overtime as well.
BEN:
I think if you’re having that already in place, it means that all kinds of other opportunities open up. I saw a script, somebody used the Instruments to take screenshots of the application in the various locales or languages or whatever, so that you can get your App Store screenshots in English, Spanish, German, Dutch, or whatever, and you wouldn’t have to do this manually. Because after you’ve done this once, you’re like, “Oh, I’ve got to take those same screenshots again because I changed this stupid label.” It goes back to my comment earlier about like, “I don’t want to change labels ever.”
PATRICK:
Yeah [chuckles]. Part of that script, and this is something recently, I was like, “Oh! I should have implemented that because screenshots would be a lot easier.” I always listen to what other people are doing, and try to, “Hey, could I use that?” like going back a little bit Jay’s tip about the keychain, which was like a head smack moment like, “Why didn’t I think of that?” that would make everything so much easier.
CHUCK:
There are also tools out there for your command-line like Guard that you can use to watch files and then have it do things based on whether or not files change so it’s not quite the same. You could also put it into Git Hook. There are ways of automating it on your local machine.
BEN:
There’s a guard-xctool I saw…
CHUCK:
Oh, really?
BEN:
Yeah. I’ve been looking at probably going to typically –
PETE:
Ben, I know the guy that did that. This is guy that does, god, everything for iOS. He did one for Frank and one for Calabash’s…
BEN:
This is like siuying?
PETE:
I don’t know…
BEN:
One other just sort of random tip, when you upgrade Xcode, a lot of times it will prompt to you interactively to accept terms…
PATRICK:
Oh, yeah!
BEN:
And if you’re running on a build server, you obviously can’t handle that. It turns out, you can do this from the command-line, which to me, if you can automate the acceptance of terms, seems like they’re less effective, but I don’t care. You run pseudo xcodebuild -license, and it will accept the license for you.
PATRICK:
It was just like one of my tips to which that was one gotcha. The area you’ll get is like you’ve not agreed to the Xcode live's code license agreement if you’re on your first time running up Jenkins, and it’s the first time that Xcode running on that machine because the license is partly easier. But if you use pseudo, it clears it for everybody. One more tip, either backup your Jenkins configurations that works based directly, or it’s built jobs directly, or version control it. Because as you make changes and script things and add stuff, you don’t want to have your Jenkins ever go down and lose it all. So at the very least, backup that folder.
PETE:
Same thing with the artifacts as well. If you want to keep those and publicate it, you want to be able to symbolicate in all build then Jenkins is set to clean up all builds, then you’d probably want to put them somewhere.
PATRICK:
Yeah. Or, I think there’s a plugin to add to Jenkins to say, “Mark this build as permanent; no matter what, don’t delete this build.”
PETE:
Right, that’s true.
PATRICK:
But definitely, have a backup for that stuff because sitting it up isn’t painful, it can be a little time consuming digging all the tweaks just right of you’ve made some pretty gnarly changes that you don’t want to have to repeat, definitely you want to back it up or put it in version control. Or, write it in version control just so you can see what you’ve changed.
PETE:
And then you have a Jenkins for your Jenkins so you can build your CI where you’re CI-ing your CI.
CHUCK:
[Laughs]
PATRICK:
Exactly [chuckles].
PETE:
I actually know someone that does that.
BEN:
You forgot it, doug!
PETE:
Dawg! I know someone has a build pipeline for their build pipeline [chuckles].
CHUCK:
Very nice.
PETE:
Yeah.
PATRICK:
Oh…we marrieds are awesome.
[Laughter]
CHUCK:
Alright, let’s go ahead and get into the picks then. Let’s start with Andrew.
ANDREW:
Sure. I have 2 picks today. One is just a small one, but it was helpful to me recently, and it’s a short article as an example of “How To Do Background Fetching on iOS 7” so this is where your app can actually download, update a content from the web in the background like a Twitter client can download and do tweets without you having to open it. It’s on a blog called (I don’t know how you say this) ‘Hayageek’. And the second one, there was a little discussion about project management stuff, so my pick is a tool called “sprintly”. We’ve been using it at work for the last, I don’t know, 6 months or something, and it’s actually pretty decent. That’s sprintly. It’s sort of agile issue tracking system, but it’s fairly flexible. Those are my picks!
CHUCK:
Awesome. Very nice. Alright, Ben, what are your picks?
BEN:
I asked you if I can go early because I figured I was going to steal somebody’s pick [chuckles].
CHUCK:
[Laughs]
BEN:
I have 4 picks; the first pick is “ASCIIwwdc.com”. Our good friend Mattt Thompson has downloaded all of the transcripts from WWDC and put them in a searchable site online. So go to ASCIIwwdc.com, it’s really awesome.
ROD:
Does that guy ever sleep?
PETE:
[Laughs]
PATRICK:
Or, how long has he been up?
BEN:
Apparently, he did this in the week end. I think some of the stuff might still under the NDA because it’s Mac, but I don’t know, we’ll see. But for now, it’s a pretty awesome idea. And apparently, Apple gives you the SRT files that contain the transcripts. So there’s that. Also, I just bought a new amp for my guitar; I’m trying to get more into electric guitar. So I bought a “Fender Blues Junior”, and I really like it. It’s still too loud for my small house; my family is, they give me like the ‘me nice’ when I start playing. But anyway, it sounds really good. Also, I’ve been really enjoying this YouTube channel called “guitarjamzdotcom”. I think either he’s just really good at sort of blues licks and that sort of thing, and those sort of getting me excited about guitar again. And my last pick is a Ray Wenderlich book on iOS 7 called “iOS 7 by Tutorials”, and it already sort of saved my bacon this week. It’s full of information. When you’re looking for stuff on iOS 7, sometimes, you run into stuff that is just not documented at all. And you go back and watch the WWDC video and it’s not helpful. Then you go look at a simple code for that session and you find that it’s not present. And then you email your Apple developer evangelist, and you don’t get a reply. So that’s been my week – anyway, luckily, this book has full of information, it’s really good. I will link to all of those things in the show notes.
CHUCK:
Cool! Pete, what are your picks?
PETE:
I just got really confused because I was looking at the website for one of my picks and it started playing blues at exactly the same time… [Laughter]
PETE:
And I think, “Is someone listening to this [unclear]? What? He don’t know [unclear]…” Okay, my pick; my first pick is “Pappy’s Smokehouse”. If you go to their website, they have a blues song that starts playing when you open [chuckles] the browser window. I was just in St. Louis, Missouri, for Strange Loop, and we went for barbeque at this place and it was as amazing! It was really, really good. So if ever you’re in St. Louis, go to Pappy’s Smokehouse. The line is like half an hour long; it’s absolutely worth-waiting for 2 hours. My next pick is a shameless plug for a product by my company so you make a continuous delivery tool called “Go”, which is definitely not as popular as Jenkins, but it’s very useful if you want to do more advanced continuous delivery stuff rather than just CI stuff – plug, plug. My next pick is a beer; it is “Bombay By Boat” from Moonlight’s Brewing, where based just near here in Santa Rosa, the snowy county, California; really, really good IPA. That’s hard to get outside of the Bay Area, but everyone should be living in the Bay Area anyway, so…
[Laughter]
PETE:
And my last 2 picks, 2 gems that wrapped around Xcode. There’s “xcoder” by this smart Australian guy called rayh something…I can’t remember his last name, and “xcodebuild-rb” from the inimitable lukeredpath, who never sleeps also. That’s it!
CHUCK:
Alright! Jaim, what are your picks?
JAIM:
I’m going to make a beer pick today; talk about lagers…
PETE:
Yes!
BEN:
Awesome.
JAIM:
By lagers, I don’t mean those dudes in the woods that dress like hipsters…
BEN:
[Laughs]
JAIM:
I’m talking about beer.
CHUCK:
[Laughs]
PETE:
[Laughs]
JAIM:
So every brewery in America is, they’ve switched their production to brew exclusively quadruple IPAs, right? There’s like cops and everything, getting just taste of like a grapefruit. But it’s that kind of fall season, it’s time for a good lager. Who makes great loggers? The Germans, right? So you guys know where I’m going with this?
ROD:
Yah!
BEN:
Yah! It’s like Oktoberfest time, have like a German Oktoberfest; not too many hops, just perfect. They’ve been doing this for 500 years; they’ve got it down. So grab a set like in Oktoberfest like a Paulaner / Hacker-Pschorr, have one of those mimic beers, give yourself a big mug – it doesn’t have to be like a 30 liter monster mug – something weird, knows what’s in there, take a sip, kind of give that a smell (that just smells like heaven), little bit of hops, little bit of malts…
BEN:
Now, I want a beer! [Laughter]
JAIM:
That’s my goal, man. So have one of those “Oktoberfest Biers”, it’s fantastic. Your buddies going to have their quadruple IPAs, but you’re doing something a little bit different.
ROD:
Are you getting commission?
JAIM:
What’s that?
ROD:
Are you getting commission?
JAIM:
No, I’m just getting thirsty.
[Laughter]
PETE:
Best pick!
CHUCK:
Awesome. Alright, Rod, what are your picks?
ROD:
Alright, I want to pick everything that’s been mentioned in the show; it’s all good stuff. And then I’ll pick my new app that just came out; it got really some start called “Pitching Radar”. It kind of turns your phone into a radar gun for baseball pitches and you can count pitches and all that, so that might come in handy for the leaguers and such. And then I want to pick “Rich Hickey”. I’ve been watching a lot of his presentations and his ideas in values and state and what’s wrong with modern programming; pretty, pretty insightful. That’s it!
CHUCK:
Alright! Well, I’ll go ahead and jump in with some picks. My first pick is “ShareMouse”, it’s a program that allows you to share your mouse and keyboard across multiple machines, kind of like Teleport or Synergy, except that it actually works.
BEN:
[Chuckles] That’s an important requirement.
CHUCK:
You have to pay for it, but it works really nice that I have been really happy with it. I’m also using “Tweetbot” to keep track of tweets to this particular podcast and other podcasts. This podcast’s twitter account is iPhreaks, so I’m really enjoying that. And then my wife turned me on to a couple of books that I’ve been really enjoying. They are the “Michael Vey Books” by Richard Paul Evans; just really, really fun books. I’m about halfway through the second book. I’ll put links into the show notes for all of those. And well Patrick, give us some picks?
PATRICK:
For a food pick, if your city has a “Fogo de Chao”, I would highly recommend you visit it; it’s a Brazilian steakhouse, where unlimited meat comes to your table, and it’s very delicious and very, very yummy. Another pick, a shameless plug for MartianCraft’s “Briefs”, a great app for designing prototypes for your iOS apps where you can then run the Brief on your device and see how things would interact. Great for tool for designers to be able to ship as it’s in everything over to a developer with exact precise layout of where everything should go. A game that I enjoyed recently playing through is a Neven Mrgan and I forgot his partner’s name, “Blackbar”, which is a game for the iPad and the iPhone where it’s a game based on censorship, where you have to guess words and things that are blacked out in text. It’s a lot of fun. I also like to recommend a book by Jonathan Penn called “Test iOS Apps with UI Automation: Bug Hunting Made Easy”. It goes through all of the stuff Apple had with UI automation to be able to test your app’s UI, which is something that’s typically hard to go through for iOS apps, and then it will run through your UI and make sure everything is working just fine or as you expect. And also, we’ve talked a lot about Jenkins, so I would also pick “Bamboo” as a pick. Bamboo is a great build server from Atlassian. And if you use JIRA, it also has great integration between the two. And finally, I’d like to pick “Alfred” which I use every Instruments for the day, which is I have tool for the Mac that lets you launch apps, run workflows, open files, find files, and everything you just command with all the keystroke. I love it and use it all the time.
CHUCK:
Awesome. Well, I think we’re going to wrap up the show. Thanks for coming, Patrick. It was awesome talking to you and getting your insight on Automating Builds.
PATRICK:
Thank you! It was a lot of fun!
BEN:
Yeah, those are really useful.
PETE:
Great stuff!
CHUCK:
Alright! Well, we’ll wrap up the show. We’ll catch you all next week!
023 iPhreaks Show – Build Automation with Patrick Burleson
0:00
Playback Speed: