Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2018年12月25日

adachi

チーム開発で Epic branch を運用した話

 
🎅Merry Christmas🎄
 

こんにちは。
ピクトリンク事業部 開発部の足立です。

 

とうとう念願の iPhone XSApple Watch SERIES 4 が手元に届き快適なガジェット生活を満喫しています。
Apple Watch すごくて第1世代の時はWorkoutのWalkingを使っている状態で電車待っててもそのまま計測を続けていたんですが、Apple Watch SERIES 4 だと「ねぇ?Workout終わる?」的な感じで通知してくれるんです。可愛いやつっすよね。

 

では、本題に入りたいと思います。

 

この記事は フリュー Advent Calendar 2018 の 12/25(火) の記事になります。
今回はピクトリンクアプリの開発で導入した Epic branch 運用 のお話です。

 

はじめに

みなさんはチーム開発をする際、どのように作業を進めていますか?
1人で担当できそうな機能開発であればソロプログラミング、少し大きめの機能開発をペアプログラミングなどしている感じでしょうか?

これらの機能開発では基本的にブランチは1本あれば十分ですよね。
 

では、もっと大きな機能をチーム内の複数人で開発するとなった場合、当然ですがブランチ1本を共有して作業するなんてほぼ無理ですよね。
というか、Git使っててそんな運用するなんてちょっと考えものですよね。

 

そこで Epic branch を導入する

はじめに

大きな機能の中にいくつものサブ機能があり、そのサブ機能を複数人で開発する。
例えばこんな感じ。

ニュース機能

  • 画面周り作成
    • プロフィール部分
    • タイムライン部分
    • アルバム一覧部分
    • お気に入り一覧部分
  • サービス層作成
  • API層の作成
  • 画面とサービス層つなぎこみ
  • ログ実装
  • デザイン調整
  • リファクタリング
  • 機能テストのバグ対応
    …..etc
     

ざっくりと例を示すためにタスクを大きく分けていますが、実際に作業する場合はもっと細かい粒度にしても良いと思います。
なぜかというと Github project と併用することで、 Epic branch での開発は活きてきます。
詳しくは Github project の導入事例 を見てください。
 

ブランチを用意する

まずは develop ブランチから Epic branch となるブランチを作成します。

$ git branch epic/enhancement-news develop
作成したらプッシュしておきましょう。チーム開発ですから。
 

次に「API層の作成」を行うとします。
ここで注意するのが develop ブランチからではなく、Epic branch である epic/enhancement-news から作成することです。

$ git branch feature/add-api epic/enhancement-news

あとは、通常の開発と同様に feature/add-api のブランチで作業を進めるだけです。
 

他の人が作業をする場合も、上記「API層の作成」と同様に epic/enhancement-news から作業用ブランチを作成すればOKです。

$ git branch feature/add-vc epic/enhancement-news

 

イメージ図
epic-branch-create
 

ブランチのマージは?

難しいことはなく、自分自身の親ブランチにマージすれば良いだけです。
PRを出す時に base のブランチを epic/enhancement-news に変更することを忘れないようにしましょう。
 

マージタイミングも基本的にはPRレビューが完了した任意のタイミングで大丈夫です。
他の人がすでにマージしておりコンフリクトが起きるようであれば通常通りコンフリクトは解消してあげてください。
 

イメージ図
epic-branch-merge

 

実際、何が良いの?

これだけを見るとメリットらしいものがイメージしにくいですよね。
実際に運用した時のメリットを挙げてみます。
 

  • PRのマージタイミングを調整できる
  • PRレビューの時の差分を必要最低限にできる
  • 指摘事項(機能テストバグとか、企画からの指摘)を即時対応しやすい
    • 仕様がFIXしていなくても作業を進められる
  • 他の機能開発と混ざらない
  • Epic branch のPRレビューはほぼ不要
  • 作業の終わった感を感じられる
  • Epic branch へのマージタイミングで確認用アプリが配布される
    • Circle CI/Deploygate の設定要
  • Github project のカードとして扱いやすい
     

など、色々挙げられそうです。
その中でも特に「作業の終わった感を感じられる」が意外と大きな功績だと思います。
「長時間の開発」「終わりの見えない開発」といったものほどキツイものはないですよね。
 

「タスクを分担し、どんどんタスクを終わらせる」ことを実感するためだけに Epic branch の運用をしてみるのも良いと思います。
Epic branch をチーム開発はもちろん、ソロ開発でもぜひ導入してみてください!!

 
 

adachi

ピクトリンク事業部 開発部 足立
ピクトリンク のiOS版アプリ開発を担当。Swiftでごりごりと書いています💻


2018年12月25日

Rancher完全に理解した

こんにちはこんばんは、フリューのジョンです。
この記事はフリューAdvent Calendar 2018の12/24分となります。(ちなみに弊社はお休みです)

Dockerやってたりすると、オーケストレーションをしたくなりますよね。
そこでよく使われるのがKuberneteであったりするのですが、やっぱり構成が大変だったり、取っ掛かりが難しいとかあるような気がしています。
それでよく使われるのが、GoogleやAWSのKubernete、GKEやKESなどのサービスが多いのかなと思います。

ただ、もしそういうのが使えない。。。という方、Rancherはどうですか?と思っています。

Rancherとは

GUIでポチポチっとdocker imageのオーケストレーション構成を簡単に組み立てられるありがたいツールになります。
内部でのLoadBarancerなどの配置、アプリケーションのスケーリングが簡単にできるのは良い点かなと思います。

最近Rancher2系がリリースされており、DockerHubでは rancher/rancher となっています。rancher/serverでは1系がダウンロードできます。

Rancherの起動はDocker(Docker Compose)を使います。docker-compose.ymlは以下のようになります

無事に立ち上がりましたら、https://(host名):8443 にアクセスしてみてください。ログイン画面が出ると思います。デフォルトはadmin/adminです。

スクリーンショット 2018-12-21 14.59.57

スクリーンショット 2018-12-21 14.57.48

今回触る上で試しに、構成としては下の図のような構成を作成しようと思います。

スクリーンショット 2018-12-21 11.06.59

Rancherをつかってみる

ポチポチやっていきましょう。まず、clusterを作ります。名前は「kotlin-sample-cluster」です。コマンドが表示されていますのでそれをコピーしておいてください。

スクリーンショット 2018-12-21 15.05.37

スクリーンショット 2018-12-21 15.06.50
次にアプリケーションを起動するサーバを登録します。先程のコマンドをサーバ上で叩いてください。

sudo docker run -d --privileged --restart=unless-stopped --net=host -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run rancher/rancher-agent:v2.1.4 --server https://${①}:8443 --token ${②} --ca-checksum ${③} --worker

するとNodesのタブの画面で以下のようにサーバが登録が開始されているのを確認できるはずです。暫く待つと登録完了となるはずです

スクリーンショット 2018-12-21 15.23.46

スクリーンショット 2018-12-21 15.36.45

では実際にアプリケーションを配置します。
まずkotlin-sample-httpd(Apache)

スクリーンショット 2018-12-21 16.05.15

kotlin-sample-tomcat(tomcat)

スクリーンショット 2018-12-21 16.07.04

LB(LoadBalancer)

スクリーンショット 2018-12-21 17.01.08

kotlin-sample-httpd、kotlin-sample-tomcatは私が作成したアプリケーションをimageにしたものになります。

LBでkotlin-sample-httpdへ向けているので、しばらくしてから、http:(ホスト名)/hello にアクセスしてみてください。
hello, world!! という形で表示できていれば、Rancher完全理解したという状態になっているはず、、、です。

まとめ

Docker Imageをクラスタリングできました。ただし、プロキシ環境では難しくなってくるかもしれません。
皆様、困ったときにRancherを思い出してもらえればと思います!


2018年12月21日

araki

Firebase A/B TestingでアプリのABテストをしよう!

この記事は フリューAdvent Calendar 2018の12/21分です。

こんにちは。ピクトリンク事業部開発部の荒木です。普段はピクトリンクというアプリのAndroid版を開発しています。世間ではスマブラの話が多いなかで、まだスプラトゥーンをやってます。ウデマエはエリアのS+が最大なので、まだXに到達してません。知り合いの子供(ガチホコのウデマエX)に「エリアでS+ならすごいよ。僕はエリアはA+だし。」とフォローされて心が折れそうですが、Xになるまで頑張りたいと思います。

今回は、Firebase A/B Testingをピクトリンクアプリに導入した話を書きたいと思います。

Firebase A/B Testingとは?

https://firebase.google.com/docs/ab-testing/?hl=ja

Firebase A/B Testingを使うと、Remote ConfigまたはNotifications Composerを使ってアプリの画面や通知に関するABテストの実施ができます。A/Bパターンの振り分けはもちろん、結果の分析も実施され、Firebaseのコンソール上で見ることができます。

今回は、Remote Configを使ったABテストについて説明します。

Remote Configを使ったABテスト

テストの作成

ここからは、テスト作成の手順について説明します。画像多めでやっていきます。

① コンソールの左ペインからA/B Testingを選択

左ペインのABTesting

②「テストを作成」を選択

テストを作成

③ Remote Configを選択

RemoteConfigを選択

④ 基本情報の入力

④基本情報の入力

これが、Remote ConfigによるABテストの作成画面です。まずは、テスト名とテストの説明(任意)を入力してください。
今回は、ボタンの色を変えるテストを想定して「ボタンの色」としてみました。

⑤ ターゲット設定

⑤ターゲット設定

テスト対象となるユーザーを設定します。

ターゲットユーザー  アプリのIDやバージョン、ユーザープロパティによって対象を絞ります。
ターゲットユーザーの割合  ターゲットユーザーのうち、何%がテスト対象になるかを設定します。
100%ならターゲットユーザー全員が対象になります。
アクティベーションイベント
(任意)
 このFirebaseイベントが送信されることで、ユーザーがテスト対象になります。
たとえば、特定の画面に遷移したイベントなどを指定します。

⑥ 目標設定

⑥目標設定

コンバージョンの設定をします。

メインとなる目標としてFirebaseのイベントを1つ選択します。このイベントの送信が、コンバージョンとしてカウントされます。また、別のFirebaseイベントを追加したり、推定収益やクラッシュフリー率などを目標に設定することができます。

 ⑦ バリアントの設定

⑦バリアントの設定

次は、バリアントの設定です。バリアントの設定をすることで、Remote Configで取得できる値が変化します。「パラメータ」の部分には、Remote Configのパラメータキーを設定します。「値」の部分にはパターンごとにRemote Configが返す値を設定します。

今回は、 ab_test_param キーで、コントロールグループ(Aパターン)ではBLUE、BパターンではREDを返すような設定にしました。

この設定をしておくと、アプリ側でRemote Configを使って ab_test_param キーで値を取得するとBLUEまたはREDのどちらかが50%の確率で取得できます。

④〜⑦の設定が終わったら画面下の「確認」ボタンを押します。

⑧ テストの開始

⑧テストの開始

テストの内容を確認したら、「テストの開始」を押すとテストが開始します。

ちなみに、「テスト端末を管理」を押すと特定の端末でABパターンを固定する設定ができます。

テスト結果の確認

2週間ほど待つとテストの結果がでます(十分なサンプル数がない場合は終わらないかもしれません)。

下の画像のように、最も効果的なパターンが表示され、コンバージョン率や改善率も提示されます。

ABテストを終了する際に、オリジナルのパターンに固定するか、最も効果的なパターンに固定するかを選択することができます。

テスト結果①

テスト結果②

さいごに

この記事では、Firebase A/B Testingの導入方法と結果の確認について説明しました。Firebase A/B Testingを使うことで、とても簡単にABテストを実施することができます。

ABテストを上手く活用しながらどんどんサービス改善をしていきたいと思います!


2018年12月20日

Hashimoto Naoto

複数のファイルの中身を検索して、条件に一致した行だけ消す方法

ピクトリンク事業部開発部インフラ課の「アドベントカレンダー3記事目で若干ネタ切れの気配を感じ始めたエンジニア」の橋本です。

むしろ12月中はもろびとがこぞってアドベントカレンダーするので、6月くらいにやったほうが目立てるんじゃないかなとか現実逃避しています。梅雨明けとか讃えましょうよ。

 

本記事は フリューAdvent Calendar 2018 の12/19の分です。

今回は、複数のファイルに横断検索をかける方法、ヒットした情報だけを消す方法をご紹介しようと思います。

どういう時に便利?

いろんな場面で活用できる余地のあるテクニックだと思いますが、実例をあげるとメーリングリストの管理などに便利に使えます。

mlsample1

このように、ひとつのメーリングリストにユーザ名を連ねる形で運用している場合を想像してみてください。
社内の関係者に一斉に情報が行き渡るよう、いい感じにメーリングリストが構築されているような環境ですね。

 

この状態で、「桐島、弊社やめるってよ」と言われた場合にリストの管理者がやらないといけないのは、

mlsample2

ファイルの中に「桐島」が含まれるものを全て探し、

mlsample3

このように「桐島」を削除した状態で上書き保存する必要があるはずです。

 

この例だとファイルは3つだけですが、これが20も30もあったら大変面倒なうえに、そのうち作業ミスも発生しかねません。

 

これをスクリプト一発で終えることができたら幸せですよね!

実際のスクリプト

以下の例は「ファイル名が.qmail-から始まるファイルから対象者を探して消す」スクリプトです。

以下のようにして使います。例のごとく実行権限付与を忘れずに。

実働部分の解説

「本当に消していいの?」と聞く部分が長いだけで、中身は至ってシンプル。

これで探して、出てきたファイルのリストを

これで対象者を削除して上書き保存しているだけです。グッバイ桐島。また会う日まで。

 

対象となるファイル名の.qmail-* があまりにも長すぎるとオーバーフローを起こしてしまう可能性があります。その場合はxargsを使うなど調整してみてください。

おわりに

今回はメーリングリストの管理を例にしましたが、

「複数にまたがったファイルから条件に合致するものだけを探す」

「ヒットしたものを置き換える、削除する」

などの操作は、ときおり発生するものです。

 

一回だけで済む場合はこの限りではありませんが、何度もやらないといけない可能性がある場合は、少しでも楽に運用できるようにしていきたいものですね。


2018年12月19日

furusin

私が勉強会の開催を推し進めるモチベーション

こんにちは。ピクトリンク事業部の古川です。

この記事はフリューAdvent Calendar 2018の12/19分となります。
エンジニアの登壇を応援する会 Advent Calendar 2018 に触発されて、
「なぜ私が勉強会の開催を推し進めるのか」をブレイクダウンしていきます。

はじめに

どんな勉強会をやってるのか

京都Devかふぇという勉強会を、だいたい隔月で開催しています。
技術関連の情報共有や関西の参加者同士の交流を目的としています。

我々は京都で働いていますので、関西の技術交流をもっと活性化し、関西の技術レベルの向上に少しでも貢献できればと考えております。

また、個人的には

Kansai.kt
大阪開催 北海道応援プロジェクト 小春の大LT大会!
v-kansai
にも参加しています。

そもそも

なぜ勉強会をやろうと思ったか

私自身、元々は非常に非常に非常にヒジョーーーーーーーーに引っ込み思案でして、人前に立つとか、
ましてや勉強会をやろうだなんて考えもしませんでした。

そんな私を、10年ほど前にコミュニティに誘って頂いたのが大きな転換期でした。
それ以来、コミュニティの中で活動することの楽しさを覚え、積極的に外部へ発信していくようになりました。

「コミュニティの中で活動することの楽しさ」とは

以前、Qiitaで私が個人でアプリ開発を続けるたった1つの理由でも触れましたが、
「楽しい」にもいくつか種類があります。

 

私が感じる「コミュニティの中で活動することの楽しさ」とは・・・
・自分の知り得なかった情報を知ることができる
・たくさんの「はじめまして」がある
・参加者みんなが楽しそうにしている

 

以上の3点に分類されました。
それぞれ噛み砕いていきます。

自分の知り得なかった情報を知ることができる

エンジニアとしての「知的好奇心が刺激される」といった表現が正しいかもしれません。
「すっげぇぇーー!!!こんなことできるのかよーーー!!!」
といった新しいことを知れる。楽しいですね!

とてもコアな情報や「こんなのどこで使うんだよ…」といったニッチな情報も多く出てきたりもしますが、
それはそれで「マニアックだなぁ!」という面白さがあります。楽しいですね。

たくさんの「はじめまして」がある

これは更に2つに分類されます。
・初対面の方と出会う
・初対面の技術と出会う

後者は上で述べたことです。
前者は参加者との出会いです。

 

参加者の皆さんには十人十色のバックグラウンドがあり、色々な知見や視点を持っていらっしゃいます。
そのような方々と技術的な議論をしたり、プライベートなお話をするのは非常に刺激的です。
楽しいですね。

 

京都Devかふぇの常連さんで、日本在住のカナダ人の方がいらっしゃいます。
個人的には、この方とずっと英語で会話しているのも非常に刺激的で、英語の勉強にもなるので非常に楽しいです!

参加者みんなが楽しそうにしている

私はディズニーリゾートが大好きなのですが、その理由が
「ゲスト(お客様のこと)の皆が、キャスト(従業員)の皆が、全員が笑顔なこの空間。幸せで溢れてる!!」
ということです。

勉強会では、人々の笑顔を見れる。その笑顔を作り出すことができる。
最高じゃないですか!すごく楽しいです!

 

また、運営として助けてくれているメンバー(足立荒木ジョン橋本まさお)の皆も
とても楽しそうに活動してくれているのも、私にとっては非常に嬉しい、楽しいことのひとつです。
感謝感激雨あられです。

 

私にとっては、ここの「楽しい」が最も大きな比重を占めています。

人々が笑顔になれる手助けを少しでもできればと思っています。

まとめ

私にとって、 楽しい とは
・知的好奇心が刺激される
・たくさんの出会いがある
・笑顔に溢れる幸せな空間に居る

この3つに分類されました。
「なんで勉強会やってるの?」の答えは一言で「楽しいから」ですが、色々な意味が込められていることが改めてわかりました。

これからも、もっと皆さんに楽しんでもらえて有意義な勉強会を企画していきたいと思っています。