Why Pulsara's iOS Developers Have More Fun!

EDITOR'S NOTE: Special thanks to Jeff Lutzenberger, Ph.D., for writing today's blog post. You can connect with him on LinkedIn. 

At Pulsara, we like to think of ourselves as a mobile-first company. We currently support the two most common mobile platforms: iOS and Android. In this post we’ll show you why Pulsara iOS developers have more fun!

Communication & Collaboration

We believe communication and collaboration are critical components to our success as a company. Our software development workflow hinges on efficient communication and collaboration. Our “go-to” tools include Jira, Hipchat and, my personal favorite, Github. We use Jira for issue tracking and release management. Hipchat is our tool for daily communication, video chats, PR tracking and, of course, all the things. Finally, we use private Github repositories to host our code and do most of our code reviews.

Code

Over the past year and a half our coding workflow has evolved into a developer-friendly process that we’re all quite happy with. While it certainly isn’t set in stone, it’s working pretty darn well for us at the moment. So what does a day in the life™ look like for a Pulsara iOS developer?

Coffee first! Then check Jira for tickets in the “Ready for Development” column. We groom and (re)prioritize our Jira tickets on a weekly basis - so I guess that’s Kanban-esque - but I wouldn’t say we strictly adhere to any one methodology. Anyway, I turn on the iOS filter in Jira and pick out a juicy ticket near the top of our board. I read through the ticket, maybe add a comment and perhaps even ping the reporter on HipChat for clarification. When I have enough information to get started, I drag the ticket to the “In Progress” column and switch over to a terminal. In my terminal I navigate to my local iOS repository, checkout the latest changes on our develop branch and then create a new branch for my ticket as follows:

git checkout develop

git pull origin develop

git checkout -b jeff/APP-941-super-juicy-ticket

Where our branch name convention is as follows:

<developer name>/<jira ticket>-<brief description of ticket>

Now it’s time to start writing code! Depending on the nature of the ticket, I need to choose a server to connect to. This could be my local vagrant stack, a staging server or my live developer stack (check out this article to see how we set developer-specific configuration settings). Additionally, if the ticket involves completely new functionality I may choose to use Swift (ah, startup life)! Once I’m pointed at the right server and I’ve settled on a language, I start working on the ticket. Any questions that arise during development are typically sent out on HipChat. I might use our “Mobile” chat room or I might just send it to a specific person, depending on the question. Due to the small size of our team and the caliber of the developers I work with I can typically get an answer in a matter of minutes. If I can’t get an answer or feel that the ticket needs further discussion, I raise it as a discussion item for our daily stand up at 2 pm.

So, I write my code, and I even write some tests! Yes, we write unit tests, and we do our best to write testable code (we’ll save that discussion for another post). We believe that writing tests during development (not after) is a good thing. We also encourage test-driven development (TDD) when it makes sense, but we’re not militant about it.

Code Review & Testing

I’ve written my tests and I’m pretty happy with my code at this point. I’ve committed to our private Github repo a few times, run clang-format (using a slightly modified LLVM code style), and verified all tests are passing (both locally and on Travis CI). At this point I’m ready for code review. I start by creating a pull request from my branch into our develop branch. Travis CI lets me know the build and tests are good to go:

I move my Jira ticket from the “In Progress” column to the “Code Review” column and wait for comments from my peers. Most of our code reviews are done directly in Github. We take full advantage of the collaborative nature of Github’s code review interface. Once I receive two +1’s I am free to merge my PR into our main branch. Merging into develop triggers a Travis CI build that does the following:

1. Builds the app

2. Runs our unit tests

3. Signs the app with an ad hoc provision profile

4. Creates a .ipa

5. Submits the .ipa to Crashlytics Beta

(stay tuned for a follow up post detailing our Travis CI setup)

Finally, the ticket is moved to “Testing” and our Quality Assurance engineer takes it from there.

Conclusion