My App Store release checklist

For the longest time it seemed that releasing an update to an iOS app was a random whack-a-mole process that I’d invariably get wrong in some way.  It was maddening, especially since iTunes Connect has only recently become a decent web application.  By switching to Jenkins for continuous integration of my iOS app builds I’ve greatly improved my process, but things didn’t really improve until I created a checklist for keeping track of my releases.

Since I’ve been asked many times about this very topic recently – both at work and on Twitter – I thought I’d write a post about how I bring some sanity to my release process so my app updates are timely and predictable.
Continue reading “My App Store release checklist”

Building a static library with Jenkins

One of my pet peeves is Open Source iOS libraries distributed as just a collection of Objective-C classes, rather than being bundled as a static library. I know a lot of people prefer it that way, but from a maintainability standpoint it really doesn’t make much sense to me. So when I’m faced with another library I want to use that doesn’t have a static library readily available for it, I typically wrap it up in my own Xcode project, check it in to Github, and configure my Jenkins continuous integration build server to compile it for me.

I thought I’d walk you through the steps I go through to make this happen, so you can use this technique too. Continue reading “Building a static library with Jenkins”

Building iOS apps for Over-The-Air AdHoc distribution

I’ve written about building iOS applications with Hudson Jenkins, but until recently there hasn’t been a convenient way of getting those applications to your testers. Of course the most important part of your build output will be the app bundle you send to Apple’s iTunes Connect web interface, but throughout your development cycle you’ll want to test your app.  Sure you could build and deploy a debug build straight to your own personal device, but you get the most benefit from having other people beta test your app.

With recent releases of Xcode and the iOS SDK, Apple improved their AdHoc distribution support with two main enhancements:

  1. Mobile provisioning files can now be embedded in the App’s IPA itself, meaning you don’t have to maintain and update separate .mobileprovision files separately;
  2. A specially-formated manifest Plist file can be created that, when linked to properly, allows test devices to install new versions of your AdHoc app without needing to plug into a computer to sync the app using iTunes.

These improvements are huge, but require some changes to your build scripts and your Continuous Integration environment.  I’d like to show you how to do this in your own installations, and show you some options for how to distribute your apps to your testers.

Continue reading “Building iOS apps for Over-The-Air AdHoc distribution”

Recovering from bit rot

One of the things that’s hard as a developer is keeping your legacy code up to date.  It’s all too easy to fire-and-forget; write your code, debug it just enough so that it compiles, and then forget it until it breaks again.  I’m guilty of that as well.  In fact, just today I discovered that my continuous deployment configuration for Boomle was broken…for the past 3 months.

After merging my code from a private repo over to Github, it still didn’t work.  After updating the Hudson build configuration to point at the proper repos and to respond to the proper webhooks (to get automatically triggered on a new check-in), it STILL didn’t work.  You see, not only does configuration change, but SDKs and APIs shift out from under you.  The iOS SDK had changed out from under my project, and the Xcode configuration was pointing at libraries and SDKs that no longer were shipped by Apple.

The lesson for me here is this: I need to get off my ass every few weeks to at least look at my source code.  Kick the tires a little, hit a build every now and then, and check that everything is still okay.  Because the longer you wait, the more things can fall apart.  Each one of those issues I mentioned above would have been simple to fix, had I addressed them right away.  But the more problems that build up, the more difficult it is to clean up your code.

As it is, I still need to integrate Game Center with Boomle, and refactor its drawing routines to be more efficient.

Now, I don’t believe in New Year’s resolutions.  Instead, I believe in making resolutions whenever they’re relevant, and sticking to them without the excuse of a New Year to motivate you.  My resolution is to take care of my projects proactively, instead of forgetting them.  Treat it like the quasi-living thing that I’m anthropomorphizing it to be, because even inactive projects need love too.

Continuous Deployment to CPAN

Recently I was working on a refactor of one of my CPAN modules which, among other things, involved changing its name from Test::A8N to the specific Test::Story.  Doing so made me think about the process I usually go through when I consider releasing a CPAN module.

First, let me explain something about myself: I don’t like tedious or repetitive tasks.  I hate having to do the same thing over and over again, partly because I don’t want to waste my time, but mostly because inevitably one of the following will happen:

  1. I’ll forget a crucial step, and will screw something up;
  2. I’ll forget how to do it, and in my efforts to re-learn it I’ll screw something up;
  3. I won’t care enough to go through the effort, so something will get screwed up.

I expect you’re noticing a trend here.  Really the only reason programmers come into this profession in the first place I suspect is because we’re just so bad at doing things the normal way, we have to automate everything we’ll either do poorly, lazily, or forget to do all together.

For those of us who are programmers, many times we’re so lazy that we won’t want to do the same thing within our programs more than once, so we abstract functionality into reusable modules.  By that token the Perl community must be some of the most inventively lazy group of people, because CPAN is full of useful tidbits like that.  Getting modules to CPAN requires a contributor to actually, you know, submit their project.  And this is, in itself, a somewhat manual process.

I do all of my development in a version control repository, and I write a decent amount of unit tests to prove my functionality works.  So once I come to the decision that a set of new features is worthy of a new release, this is the process I go through:

  1. Run “perl Makefile.PL && make && make test” to verify everything runs okay;
  2. Run “make dist” to create the distribution tarball;
  3. Noticing the version number is wrong, I go in and change it in the main Perl module;
  4. After running “make dist” again, I realize I forgot to change the README;
  5. Potentially after another “make dist“, I’ll remember I’m supposed to update the Changes file to indicate what I’ve added;
  6. It’s at this point I realize that I forgot to add new documentation to cover this new feature;
  7. I run “make test” again, this time with TEST_POD=1 set to ensure my documentation checks are run;
  8. I’ll then try to remember what the command is for uploading a new CPAN module, which involves searching on CPAN for something related to “Upload”;
  9. Finding “cpan-upload“, I’ll have to look at its documentation to figure out how to use it;
  10. I run “cpan-upload“, only to realize I forgot to set my PAUSE credentials in ~/.pause.

At this point, if I’m lucky, the upload will succeed.  This process isn’t meant to be a negative reflection on CPAN, but rather on my own forgetfulness and need to automate.

Read on to find out how I managed to automate this part of my life as well.

Continue reading “Continuous Deployment to CPAN”

Building iPhone apps with Hudson, Part 2

I’ve already posted before on how to set up Hudson to compile and build iPhone applications, but I just had a “OMG I ❤ Hudson!” moment just now, and felt I had to share it.

I do most of my mobile development literally while I’m mobile; on the train during my morning commute, from coffee shops on the weekend, or in front of the TV in the evenings when I’m winding down for the night. Because of this, I don’t have any consistent time when I’m making checkins, nor do I have the time to create builds for my beta users.

One of the iPhone apps I’m building is for a client, and because my time is limited, I want to streamline communication as much as possible, especially since I have a day job that I really like and uses 8 of my precious 24 hours per day. I don’t want to have to tell them every time new features are ready to be tested. Additionally, if I have to manually compile and send a beta build to them whenever I complete a new feature, I’ll never have enough time to actually get any work done. Add to that the fact that many mail servers will block iPhone applications for one reason or another (file size limits, misfiring antivirus filters, or any number of reasons).

So the solution I’ve come up with is an extension of my iPhone application build scripts combined with some nice plugins for Hudson. All of the above steps are completely automated away and handled for me just by checking my code into git.

  1. The first thing I did was updated my build scripts to generate an “.ipa” archive for Distribution builds containing an iTunesArtwork file, and a “.zip” archive for Release builds.
  2. My build script sets the version number of my application to the $BUILD_NUMBER of my Hudson job, so that the version is guaranteed to be unique.
  3. I added the SCP plugin to Hudson and configured a location on my web server where Hudson could upload completed builds to the website. This enables my clients to access the page to download new releases.
  4. In order to inform my clients that a new build is available, I’ve used the customizable email support in Hudson to send an email to a custom list of email addresses when a successful build is completed. In this email I include a link to the uploaded IPA so they can easily download the beta archive.
  5. So that I don’t have to go through the trouble of describing what changes I made, I use the $CHANGES_SINCE_LAST_SUCCESS variable in my custom email template that lists all the commit messages I’d submitted to git that were included in this build.
  6. For good measure, I SCP to the website a copy of the “.mobileprovision” certificate file that was used to build the application, so the beta tester can add it to iTunes if the contents have changed.

The result of all this work is that I can work wherever I am, continually committing changes into git. When I’m ready to cut a new build, I submit my changes to github where a webhook script will notify Hudson that changes have been made. Hudson checks out my changes, builds them on my Mac Mini at home, SCP’s the resulting archive up to my web server, and notifies my beta testers that a new archive is available and what changes they should keep an eye out for.

For a copy of the build scripts and configuration I use inside my projects, take a look here:

https://nachbaur.com/wp-content/uploads/2010/06/444377.js

This assumes there’s a file in the build user’s home directory called “.build_password” that contains the password used to unlock your keychain. Run “chmod 600” on that file in order to make it hidden to anyone else on your system.  And make sure you check in the “.mobileprovision” files your XCode project file references.  If you change your certificates, you’ll need to copy the updated mobileprovision files from your “Library/MobileDevice/Provisioning Profiles” directory.

So you can see why I’m excited about this.  I hope you are too.