Agile software development using Kanban & Scrum. We code Flex & Ruby on Rails in Auckland, New Zealand.

  • Viewing all posts tagged "Hudson"

  • Ad Hoc IPhone Distribution and CI (pt 1)

    What I need to do

    1. Build our IPhone App
    2. Build it using Continuous Integration (Hudson Rocks)
    3. Follow Agile, deploy often to customers to get feedback and to keep them as up to date as possible.

    Our customers don’t typically use a portal (like app store) to find us, we use ‘traditional’ sales.

    Which deployment?

    App Store?

    We’ll need the app store, at some point.

    The oft discussed turnaround time for App Store deploys is sounding worrying. It doesn’t really fit with Agile development… does it?

    Ad Hoc

    Ad Hoc is a nightmare with a CI server. You need to update your provisioning profile on the CI server and it’s not simple. I’ve worked out theoretically how to make the process speedier, but am yet to implement. More on this in part 2.

    We need Ad Hoc because of how the app store approach fails us. That is, it’s a better (not necessarily good) way to be Agile.

    Enterprise

    Enterprise just doesn’t apply to us. It probably won’t to you either. If all our customers were enterprise we could suggest they all use this license, but they aren’t. Not even close.

  • Add Hoc IPhone Distribution and CI (pt 2)

    Here I propose the final process for our team to add a device to the ad hoc provisioning profile and getting it into our CI system (Hudson, still rocking). This process is not what I would like it to be, just the best I can hope for.

    Locate the device UUID.

    As you only get 100 changes to the distribution profile per year, it’s not a good idea to get the UUID wrong. So rather than manually typing it in, we need a way to copy it to the clipboard and pasting it to the developer portal. ITunes doesn’t allow you to use the clipboard, and not everyone here has a mac (and thus no XCode). So instead, we’ll use the Ad Hoc Helper which emails the ID to whomever you wish.

    Add devices to the profile

    If you have an IPhone developer account over at apple, there’s an adequate howto on this. Bottom line is, add as many devices in one go as you can.

    Overwrite existing .mobileprovision in Source Control

    We use git for this project, and we keep a copy of the current .mobileprovision in a directory that, when changed, naturally triggers a new build.

    What happens in the CI Script

    1. Clear the library folder. This will force the build to fail if the profile is not updated within the project.
    2. Move the .mobileprovision file into place
    3. Sed the .mobileprovision file for the UUID of the profile
    4. Update the project config to use the new profile UUID
    5. Allow chain access. Currently using plain text password. Is there a better way?
    6. Build
    7. Grab the .app and the .mobileprovision files as artifacts for distribution

    Note: The slave machine is forced to run a single build at a time (one Hudson Executor) to make this work reliably

    My Hudson Script

    Heres the Hudson ‘Execute Shell’ script I used to achieve the above. It’s designed to work with our rhomobile app. I’ve tried to highlight what you need to change etc.

    # (1) Clear the library
    rm -f ~/Library/MobileDevice/Provisioning\ Profiles/*
    
    # (2) Move the .mobileprovision file into place
    # keep the provisioning profile in <workspace_root>/provisioning_profiles
    # change the provisioning profile name to match yours.
    cp provisioning_profiles/Ad_Hoc_Scheduling.mobileprovision ~/Library/MobileDevice/Provisioning\ Profiles/
    
    # (3) Sed the file for it's UUID
    # keep the provisioning profile in <workspace_root>/provisioning_profiles
    # change the provisioning profile name to match yours.
    PROFILE_UUID=`grep "<key>UUID</key>" provisioning_profiles/Ad_Hoc_Scheduling.mobileprovision -A 1 --binary-files=text | sed -E -e "/<key>/ d" -e "s/(^.*<string>)//" -e "s/(<.*)//"`
    
    # (4) Update the project to use it.
    # The zerg_provision file is shown later. 
    # First argument is the location of the XCode project
    # Second argument is my the target configuration for the build
    # Third argument is the project target (you'll need to call this command repeatedly for more targets)
    # Last argument, the UUID of the profile being injected
    ruby tools/zerg_provision.rb platform/iphone AdHoc rhorunner $PROFILE_UUID
    
    # (5) Allow chain access
    # Replace ***** with your chain password
    security unlock-keychain -p ***** ~/Library/Keychains/login.keychain
    
    # (6) Build.
    cd platform/iphone/   # location of the project
    xcodebuild -configuration AdHoc -sdk iphoneos2.2.1 # AdHoc is my configuration.
    

    tools/zerg_provision.rb

    require 'rubygems'
    require 'zerg_xcode'   # http://github.com/costan/zerg_xcode/tree/master
    require 'pp'
    
    project = ZergXcode.load(ARGV.shift)
    
    configuration = ARGV.shift
    target = ARGV.shift
    key = ARGV.shift
    
    build_configurations = project["buildConfigurationList"]["buildConfigurations"]
    configuration_object = build_configurations.select {|item| item['name'] == configuration }[0]
    configuration_object["buildSettings"]["PROVISIONING_PROFILE"] = key
    configuration_object["buildSettings"]["PROVISIONING_PROFILE[sdk=iphoneos*]"] = key
    
    target = project["targets"].select {|item| item['name'] == target }[0]
    build_configurations = target["buildConfigurationList"]["buildConfigurations"]
    configuration_object = build_configurations.select {|item| item['name'] == configuration }[0]
    configuration_object["buildSettings"]["PROVISIONING_PROFILE[sdk=iphoneos*]"] = key
    
    project.save!
    
  • Visfleet’s Radiator (v 0.0.1)

    I started a project not too long ago to implement an information radiator here at Visfleet. The first milestone has been reached: Show the status of important Hudson builds

    And here it is:

    The source is on github

    I started out with the intention of using Flex 4 skinning to make a super-modern, slick looking radiator like Panic’s. But somewhere along the way I ended up with a two tone border, it reminded me of my Commodore days, and the rest is ugly :)

    Near term plans include:

    • Show C64 raster bars around building jobs
    • Use a horrible blink to highlight broken builds
    • Show who has claimed a build

    Then:

    • Show which of our feature build servers has been claimed for a feature branch.
    • Show our twitter feed.
    • Get a much bigger screen.