TaskRabbit is Hiring!

We’re a tight-knit team that’s passionate about building a solution that helps people by maximizing their time, talent and skills. We are actively hiring for our Engineering and Design teams. Click To Learn more

Jeremy Eaton


A QA Pain Point

One small pain point I’ve felt while working on features for the Tasker App is Acceptance Testing: verifying that a feature is to spec. We do our best to provide instructions on how to test a particular feature, on what server side code needs to be deployed to a staging enviornment and how to install the correct iOS or Android build, but we still find that, on occasion, confusion about which build to download on Crashlytics can arise.

I decided to take a stab at eliminating confusion by automating the deployment of each pull request and posting a link to its corresponding Pivotal Tracker story.

Deploy to Staging Host

I first decided to abandon Crashlytics for Acceptance Testing because 1. our entire company uses Crashlytics internally and 2. I couldn’t find a link that references specific builds. The one I found only points to the latest release. So, I decided to use a nifty Fastlane plugin to upload builds to our Amazon S3 bucket, which also generates an HTML page that can be viewed on mobile to download builds to device.

The Post-Deploy Hook

I then wrote a script using the tracker_api gem to post a link to the Tracker story if it isn’t already posted. I’m assuming that developers are including the Pivotal Tracker ID in the branch name, which is the norm here at TaskRabbit.

#!/usr/bin/env ruby

require "tracker_api"

DEPLOY_TEXT = "DEPLOYED TO STAGING".freeze

client = TrackerApi::Client.new(token: ENV["PIVOTAL_TRACKER_API_TOKEN"])

# get the story from the branch name prefix
branch_name = ARGV[0]
raise "must pass branch name to script" unless !branch_name.nil? && branch_name.length > 0
story_id = branch_name.split('-').first.to_i
if story_id.nil? || story_id < 1
  puts "no story_id found from branch #{branch_name}. exiting."
  exit
end

project = client.project(ENV["PIVOTAL_TRACKER_PROJECT_ID"])
story = project.story(story_id)

# return if we have already posted a link to a build on this story
if !story.comments.empty? && story.comments.any? { |c| c[:text] && c[:text].match(/^#{DEPLOY_TEXT}/) }
  puts "story [##{story_id}] already has a link to s3. exiting"
  exit
end

# POST a comment to the story with a link to DL the android and ios builds from s3
url = "https://obfuscated-taskrabbit-amazon-host/#{Time.now.year}/#{Time.now.strftime("%m")}/#{branch_name}"
comment_text  = [
  DEPLOY_TEXT,
  "[link to iOS](#{url}/ios/index.html)",
  "[link to android](#{url}/android/index.html)"
].join("\n")

story.create_comment(text: comment_text)
story.save

puts "link to s3 posted to story [##{story_id}] successfully!"

Tie it all together

The final step was to add the Fastlane and Pivotal Tracker scripts to our Continuous Integration/Deployment Pipeline so that with each push to Github and successfull run against our test suite, we’d deploy to S3 and post a link on the Tracker story to the latest build. If your CI/CD server is happy and healthy, this works pretty well and can save you time in the form of reduced communication regarding builds because the link speaks for itself.

Push. Post. Profit.

Comments

Coments Loading...