Git Rich Quick: The Development Process for the iOS Version of LINE

Hi there. My name is Hayaishi, and I’m part of the Technology Strategy
Department here at LINE. I’d like to share a few details about the
development process of the iOS version of the LINE app in this blog
entry.

The Development Environment for the iOS LINE App

Managing the Source Code

We manage our source code with Git. We also use GitHub Enterprise as our
Git repository browser while developing, so we can take advantage of
GitHub’s pull request and other commands that we’ve all grown so fond of
over the span of many projects.

In addition to GitHub Enterprise, we use a separate ticket management
system for LINE iOS app-related tasks. The two systems are integrated so
our developers, quality assurance (QA) testers, and designers can keep
on top of current development statuses and stay on the same page at all
times.

The Development Flow Using Git

The development process for the iOS version of LINE mirrors the GitHub
Flow in many ways. Instead of having just one master that’s able to be
deployed at any time, our system operates by having deployable masters
for each version. The flow itself is illustrated in the diagram below.

Each branch is completely releasable. This may come as a surprise, but
depending on the development status of each version, the most recently
committed iteration of an older version of LINE may have been updated
more recently than the most recently committed iteration of the latest
version of LINE.

We decide on which new features and fixes to provide for each version of
the iOS LINE app. We also avoid committing to a single master version.
This makes carving up the testing process a lot easier for our QA team.
When a revision of the lowest version currently still in development is
released, we merge that branch with the highest versioned branch, which
gets rid of the oldest version. We lather, rinse, and repeat this
process to eliminate older branches as we go. Sometimes we make an
effort to insert new features included in more recent versions into
older versions of the app. We have yet to experience any problems with
this flow.

The app was originally developed using git-flow, but our flow has slowly
evolved over time into what we have now.

Multiple Development Environments

The API used by the app is divided into the two development environments
below.

Environment Description
Dev/BETA  References a development DB that differs from the live app DB.
RC  References the same DB as the live app, used for testing the app before releases.

We try to avoid unexpected oopsies by using a separate environment for
development from the one used for the live version of the app.

Managing the iOS Library

Generally speaking, we manage the library for the iOS version of the app
using two methods.

CocoaPods

It’s safe to say that CocoaPods has become the main tool for library
management for our iOS app development team. We also use CocoaPods to
manage both internal and external libraries. Our internal libraries are
stored in our in-house git repository and referenced from there.

.gitmodule

The LINE app also takes advantage of Git’s submodule feature. In the
past, pod install was relatively slower than git submodule update,
so we decided to go with the latter. It’s also really easy to compare
differences when editing submodules, which is a nice added bonus. There
are parts of our internal library that expand along with the development
process for the app itself, so it’s just easier overall this way.

Configurations and Schemes

We use separate environments for development and the live version of the
LINE app. Each environment comes with its own unique configurations
defined in APP_IDENTIFIER, BUNDLE_DISPLAYNAME, and
GCC_PREPROCESSOR_DEFINITIONS.

All the LINE app configurations for the above are managed and stored in
“xcconfig” files.

Multiple xcconfig files:

Multiple configuration settings:

Shared configurations are defined in the Base.xcconfig file, and any
required elements are simply written over for each environment’s version
of the file. When compared to project settings configured with Xcode,
the method we use offers a higher degree of readability.

Schemes are prepared for each LINE app environment and switched out when
creating new builds.

Archive Post Actions

When the LINE development team wants to release a build for any app, we
use our special in-house test app distribution service that has been
customized to fit our needs. The LINE iOS app also uses this method of
test app distribution. In order to simplify the process of uploading
builds to this service, we configured an uploading script for
post-actions when archiving.

The script takes the username of the author of the build, branch name,
commit, tag, and other information related to the build from the
environment that the build is running on and creates a separate file.
The .ipa file is also created at this point and uploaded along with the
build.

Next, let’s take a look at the development process itself.

Workflow for the LINE iOS App

Starting the Development Process

At the beginning of new projects, each engineer forks the central
repository and clones it to their local workspace. They then check out
the feature branch used for development from the version of the branch
they will be adding new features to.

Making Pull Requests

When we’ve progressed to the point in development where we have
something significant we want to be checked by our team, we make a Pull
Request. It’s no problem to make this request as a “work in progress”,
or WIP. When a developer wants another team member to review their code
in order to merge it, they change the status of the ticket to ALPHA Deployed. At this point, the revisions made on the ticket have been
put up for review.

Merging Pull Requests

Once the code has been reviewed and the Pull Request has been merged,
the ticket’s status is changed to ALPHA Confirmed. At this point,
the revision is ready to be released as a beta version of the app.

Testing Newly Developed Features in Beta

Once the beta build is released and ready to be downloaded by other
developers, testers, and designers, the ticket status is changed to
BETA Deployed. This status signals to QA testers and designers that
this revision is a beta build now available for use.

Releasing Newly Developed Features in RC Post-QA Testing

Once the quality assurance testing process for the beta build is
complete, the RC version of the app that references the same DB as the
live app is made available for download, and the ticket’s status changes
to BETA Confirmed. This tells everyone working on the project that
this revision has already changed to the RC environment.

The Flow of Tickets

The ticket statuses used to manage new features and additions change
according to the stages of development listed above. Through this
process, the different stages of the build are shared with other people
working on the project without having to explain to them all the related
minor details.

Status Description
Open  Development started.
Alpha Deployed  Code review requested.
Alpha Confirmed  Code review complete and code merged.
Beta Deployed  A build containing the revisions can now be used in the beta environment.
Beta Confirmed  The revisions have been QA tested and can now be used in the RC environment.
Closed  The revisions have been released in the related app store.

I Can’t Build There: The LINE SCV Bot

Builds of the LINE app are generally uploaded to our internal app
distribution tool using Jenkins. Testers and other developers then
download the build from the distribution tool. However, because Jenkins
contains certificates and other sensitive data used for app builds, only
LINE client developers are allowed to access it.

All that being said, it’s not like the QA tester has to hunt down the
developer to ask for the build that’s on Jenkins when they receive a QA
test request for the build of the app that’s waiting to be released on
the beta environment. For the LINE client app, non-developers can
interact with the build on Jenkins through the LINE app by using the
build bot known as “LINE SCV”. If the build crashes, the developer is
right there to make the necessary adjustments.

Thanks to the LINE SCV Bot, testers are guaranteed a downloadable build
of the latest version of the revisions whenever they need it, all just
by checking the ticket status.

LINE Official Accounts

Now for something completely different. LINE SCV takes advantage of the
system used by LINE official accounts for sending auto-replies to
messages. The official account’s web hook is used to get the message
sent by the user. Commands are then executed based on the content of the
message received.

Remote builds are possible with Jenkins by using the format $ curl -v {$JENKINS_URL}/job/{$JOB_NAME}/build?token={$TOKEN}.
LINE SCV sends requests based on this type of request.

Build Bot Commands

The following commands can be used with LINE SCV. These commands can
only be used to send messages in LINE chats.

Command Description
help  Displays the help menu of available commands.
jobs  Displays a list of job names with available builds.
build (job name)  Request a build of the designated job.
queue  Displays a list of job names currently awaiting builds.

A build of the latest version of the code is compiled and uploaded to
the internal test app distribution tool where the tester can then
download it, simply by sending a message to LINE SCV saying “build (job
name)”. Afterwards, a message is sent via LINE chat to all the
developers and testers registered with LINE SCV notifying them that a
new build has been uploaded.

The build of the binary is uploaded to the internal app distribution
tool through Jenkins, so recipients just click the URL inside in the
notice to move directly to the download page. This kind of flow allows
our testers to check ticket statuses and other pertinent information
while also enabling them to download the latest builds, all without
having to rely on developers to send them the necessary files.

Summary

I hope all that information was helpful. Launched in 2011, LINE has a
relatively long history as far as apps go. It took a lot of trial and
error to get settled into the workflows we have today, but it’s a good
bet the way we do things around here will continue to evolve in the
future.

Links

CocoaPods : http://cocoapods.org/
git flow : http://nvie.com/posts/a-successful-git-branching-model/
github flow : http://scottchacon.com/2011/08/31/github-flow.html