Hi there. My name is Hayaishi, and I’m part of the Technology StrategyDepartment here at LINE. I’d like to share a few details about thedevelopment process of the iOS version of the LINE app in this blogentry.
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 ourGit repository browser while developing, so we can take advantage ofGitHub’s pull request and other commands that we’ve all grown so fond ofover the span of many projects.
In addition to GitHub Enterprise, we use a separate ticket managementsystem for LINE iOS app-related tasks. The two systems are integrated soour developers, quality assurance (QA) testers, and designers can keepon top of current development statuses and stay on the same page at alltimes.
The Development Flow Using Git
The development process for the iOS version of LINE mirrors the GitHubFlow in many ways. Instead of having just one master that’s able to bedeployed at any time, our system operates by having deployable mastersfor each version. The flow itself is illustrated in the diagram below.
Each branch is completely releasable. This may come as a surprise, butdepending on the development status of each version, the most recentlycommitted iteration of an older version of LINE may have been updatedmore recently than the most recently committed iteration of the latestversion of LINE.
We decide on which new features and fixes to provide for each version ofthe 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 isreleased, we merge that branch with the highest versioned branch, whichgets rid of the oldest version. We lather, rinse, and repeat thisprocess to eliminate older branches as we go. Sometimes we make aneffort to insert new features included in more recent versions intoolder versions of the app. We have yet to experience any problems withthis flow.
The app was originally developed using git-flow, but our flow has slowlyevolved over time into what we have now.
Multiple Development Environments
The API used by the app is divided into the two development environmentsbelow.
| 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 fordevelopment 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 appusing two methods.
CocoaPods
It’s safe to say that CocoaPods has become the main tool for librarymanagement for our iOS app development team. We also use CocoaPods tomanage both internal and external libraries. Our internal libraries arestored in our in-house git repository and referenced from there.
.gitmodule
The LINE app also takes advantage of Git’s submodule feature. In thepast, pod install was relatively slower than git submodule update,so we decided to go with the latter. It’s also really easy to comparedifferences when editing submodules, which is a nice added bonus. Thereare parts of our internal library that expand along with the developmentprocess 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 theLINE app. Each environment comes with its own unique configurationsdefined in APP_IDENTIFIER, BUNDLE_DISPLAYNAME, andGCC_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 anyrequired elements are simply written over for each environment’s versionof 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 whencreating new builds.
Archive Post Actions
When the LINE development team wants to release a build for any app, weuse our special in-house test app distribution service that has beencustomized to fit our needs. The LINE iOS app also uses this method oftest app distribution. In order to simplify the process of uploadingbuilds to this service, we configured an uploading script forpost-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 theenvironment that the build is running on and creates a separate file.The .ipa file is also created at this point and uploaded along with thebuild.
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 centralrepository and clones it to their local workspace. They then check outthe feature branch used for development from the version of the branchthey will be adding new features to.
Making Pull Requests
When we’ve progressed to the point in development where we havesomething significant we want to be checked by our team, we make a PullRequest. 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 codein order to merge it, they change the status of the ticket to ALPHA Deployed. At this point, the revisions made on the ticket have beenput 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 otherdevelopers, testers, and designers, the ticket status is changed to BETA Deployed. This status signals to QA testers and designers thatthis 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 iscomplete, the RC version of the app that references the same DB as thelive app is made available for download, and the ticket’s status changes to BETA Confirmed. This tells everyone working on the project thatthis revision has already changed to the RC environment.
The Flow of Tickets
The ticket statuses used to manage new features and additions changeaccording to the stages of development listed above. Through thisprocess, the different stages of the build are shared with other peopleworking on the project without having to explain to them all the relatedminor 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 appdistribution tool using Jenkins. Testers and other developers thendownload the build from the distribution tool. However, because Jenkinscontains certificates and other sensitive data used for app builds, onlyLINE client developers are allowed to access it.
All that being said, it’s not like the QA tester has to hunt down thedeveloper to ask for the build that’s on Jenkins when they receive a QAtest request for the build of the app that’s waiting to be released onthe beta environment. For the LINE client app, non-developers caninteract with the build on Jenkins through the LINE app by using thebuild bot known as “LINE SCV”. If the build crashes, the developer isright there to make the necessary adjustments.
Thanks to the LINE SCV Bot, testers are guaranteed a downloadable buildof the latest version of the revisions whenever they need it, all justby checking the ticket status.
LINE Official Accounts
Now for something completely different. LINE SCV takes advantage of thesystem used by LINE official accounts for sending auto-replies tomessages. The official account’s web hook is used to get the messagesent by the user. Commands are then executed based on the content of themessage 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 canonly 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 tothe internal test app distribution tool where the tester can thendownload it, simply by sending a message to LINE SCV saying “build (jobname)”. Afterwards, a message is sent via LINE chat to all thedevelopers and testers registered with LINE SCV notifying them that anew build has been uploaded.
The build of the binary is uploaded to the internal app distributiontool through Jenkins, so recipients just click the URL inside in thenotice to move directly to the download page. This kind of flow allowsour testers to check ticket statuses and other pertinent informationwhile also enabling them to download the latest builds, all withouthaving to rely on developers to send them the necessary files.
Summary
I hope all that information was helpful. Launched in 2011, LINE has arelatively long history as far as apps go. It took a lot of trial anderror to get settled into the workflows we have today, but it’s a goodbet the way we do things around here will continue to evolve in thefuture.
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