rocket-ci でキャッシュや環境変数が利用できるようになりました

こんにちは、コベリンの @numa08 です。アップデート情報をお届けします。

キャッシュが利用できるようになりました

依存ライブラリのダウンロードなどが必要な際に、ダウンロードしたデータを次回以降のビルドでも利用できるようキャッシュ機能が実装されました。ビルド定義ファイルの rocket.sh の中で環境変数 ROCKET_CACHEを参照することで利用できます。

例えば Android アプリの場合

mkdir -p "${HOME}/.gradle"
if [[ -d $ROCKET_CACHE/.gradle ]];then
    cp -r $ROCKET_CACHE/.gradle $HOME
fi 
./gradlew assemble
cp -r ${HOME}/.gradle $ROCKET_CACHE

とすることでダウンロードをした gradlew のバイナリや依存ライブラリをキャッシュとして保存し再利用することが可能です。

なお、キャッシュの上限は1GBで容量を超えるデータを保存しようとするとエラーが発生してビルドが失敗となる可能性があります。

また、キャッシュには最後に成功したビルドのものが保存されます。

環境変数が利用できるようになりました

ビルド一覧画面から開くことのできるリポジトリ設定画面で環境変数をセットできるようになりました。

ビルド時に rocket.sh の中から参照ができます。外部連携しているサービスに関する情報やビルドに関する情報を保存することで、リポジトリには含めたくいデータを与えることが可能です。

Rocket CI は現在クローズドα期間です。テスターとして利用をしてみたい方は Slackチームに参加をしていただいたあと、チーム内のコベリンメンバーに声を掛けていただけたらテスター登録を行います。

それでは、今後共コベリンと Rocket CI をよろしくお願いいたします。

9月のコーヒー

コベリンでは沢山の美味しいコーヒーを飲むことができることを知っていますか？

多くのエンジニアにとって高い開発効率を維持するため美味しいコーヒーは欠かせないものとなっています。

コベリンでは(とりわけ僕の)モチベーションを維持するために沢山の美味しいコーヒーを飲むことができます。

そんなわけで今月のコーヒーを紹介していきたいと思います。

コーヒーのスペックに関しては覚えてる範囲で書きます。

OBSCURA COFFEE ROASTERS

こちらの豆は OBSCURA COFFEE ROASTERS というお店で定期購入を申し込んで発送してきていただいているものです。

コロンビア サン・アグスティン協会

• プロセス: ウォッシュト
• 焙煎度: ハイ・ロースト
• 柑橘系のフルーツやお花の香り。浅煎りのコーヒーをあんまり飲んだことがない人だと酸っぱく感じるかもしれないです。

インドネシア リントン地区オナンガンジャン マイクロロット スプリングクロップ

• プロセス: スマトラ式
• 焙煎度: フルシティー
• 深煎なのでしっかりとした苦味があってコーヒーっぽい味をしてる。誰でも飲みやすいと思います。

カフェテナンゴ

このお店はセミナーを開催していて何度かお邪魔しました。

今まで飲んだことのない特徴的なコーヒーを販売していてとてもおもしろいです。

ニカラグア カサブランカ農園

• プロセス: ナチュラル
• 品種: パカマラ
• 人を選ぶ味わいと驚くような香り(熟れすぎた蜜柑)がします (散々なコメントですが僕はかなり好きです)

コスタリカ サンタ・ロサ農園

• プロセス: イエローハニー
• 誰でも飲みやすいと思います。 熱いうちは焙煎の香りがしますが、冷めてくるとフルーティーな香りが出てきて変化が楽しめます。

堀口珈琲 7番

以下の写真は3種類写っていますがこの中で 7と書いてあるものを持っていきました。

堀口珈琲はストレートコーヒーではなくブレンドコーヒーです。 どれも美味しいのでおすすめです。

ブレリアビーンズ

こちらのお店は極端な浅煎りや深煎は並べておらずどれも飲みやすい豆を販売しています。

イエメン モカ・マタリ アール マッカ

• アール マッカは最高グレードの豆に付く名前
• モカにありがちな好みが別れるような香りはしないでフルーツやお花の香りがします。

コスタリカ エル・バポル農園

• プロセス: ハニー
• 誰でも飲みやすいと思います。しっかりとした味と香りがするので午後の疲れてるときに飲みたくなります。

終わりに

以上がコベリンで9月に提供されたコーヒーです。

どれも特徴的 & 高品質なものなので気になるものがあったら是非飲んでみてください。

特徴的な味わいなので好みかどうかは保証致しませんのでその点だけご了承ください m( )m

新しいCIサービスのクローズドアルファを公開しました

こんにちは。コベリンの @numa08 です。

この度、合同会社コベリンでは新しい事業として rocket ci のクローズドアルファテストを公開しました。

Rocket CI

あなたのチームにフィットする CI サービス

現在、 CI をソフトウェア開発のフローに導入することで品質や開発効率の向上を狙う個人やチームは多いと思われます。CI のツールとして有名な物は jenkins が挙げられますが、それ以外にも Cirlce CI や Travis CI と言ったサービスが存在します。

自分達でメンテナンスを行う jenkins を除き、 Circle CI や Travis CI は基本的に月額課金を採用しています。そのため、少数チームでの開発や長期休暇などで開発スピードが落ちる期間でも変わらず料金が発生し、少し課金体系に不満がありました。

私達が提供をするサービスは従量課金制を採用します。具体的な金額については現在は非公開ですが、利用した分だけ料金が発生する仕組みですので、小規模チームや開発スピードに変化の発生するチームであっても気軽に利用できるサービスとなります。

rocket-ci の今後

マイルストーン にも掲載をしていますが、年内に正式版としてリリースを行い、合わせて料金体系の公開、マネタイズを実施する予定です。

テスターを希望される方へ

テスターを希望される方は Slackチーム へ参加をしていただいたあと、チーム内のコベリンのメンバーへ声をかけてください。

それでは今後も rocket ci とコベリンをよろしくお願いいたします。

Pull Request を見なおして開発をスピードアップする試み ~レビューをしないという選択肢~

こんにちは。 コベリンの @numa08 です。

コベリンには3人のエンジニア (@numa08, @mironal, @ryohey) がいて、動いているプロジェクトがいくつかあり、うち複数人で回しているものが4つあります。

内訳は

• iOS/Android版feather
• 新期開発中の自社サービス
• 新規開発中の受託サービス

となっています。

それぞれのプロジェクトでは Pull Request を通してコードや進捗の共有、品質の向上を目指しています。

しかし、多くのプロジェクトがそうであるように、 Pull Request を軸にした開発フローでしかも人数が少ないとなると「待ち時間の発生」というボトルネックが生まれます。

「待ち時間の発生」に対するアプローチはチーム毎に様々な方法があると思います。「様々な方法がある」ことを認めた上で「ケース・バイ・ケース」で判断するという方向に舵を切ってしまうと、どうするべきかの判断の基準が人によって異なったり、また決断をすることによってメンバーにストレスがかかることが懸念されます。

そこで、プロジェクト毎にどう言った方法が適切なのか、どうするのがベストなのかを調査し、話し合い、「Pull Request のレビューを行うのか」あるいは「行わないのか」を定めたルールを試験導入することにしました。

今回は、試験導入することになった方式を紹介します。

レビューをやるのか/やらないのか

iOS版/Android版 feather の場合

• コードレビューをやるもの
  • 全てのソースコードの変更
• コードレビューをやらないもの
  • 依存ライブラリのアップデート
  • typo の修正

twitter 非公式クライアントの feather は Android版はリリースをしてからそろそろ1年、 iOS版は2年以上経ちます。いずれもソースコードの量も多く、変更が及ぼす影響はどうしても大きい物になってしまう可能性を秘めています。

そのため、コードの変更を行った場合は Pull Request の作成とレビューの実施を絶対に行う物としました。ただし、依存しているライブラリのバージョンを上げるだけの変更や typo を修正するだけの場合は Pull Request を作るものの、コードレビューの依頼はせず、変更者本人によるマージの後、 slack などを利用して変更を行った事をメンバーに通知します。

また、 Clashlytics を利用しているので、依存ライブラリのバージョン変更による見た目や挙動の変更確認はコードを見なくてもベータ版を誰かにインストールしてもらうことで確認可能です。

そういった理由から「基本的にコードレビューは行うものの、小規模な修正と考えられるライブラリのアップデートや typo の修正はレビューは行わず、マージ後に周知をする」としました。

新規開発中の自社サービス

• コードレビューをやるもの
  • 変更者の主観で「不安だ」と感じた物
• コードレビューをやらないもの
  • 全部

現段階でリリースをされていない新期開発中サービスについては、レビューを実施することよりも速く開発をしてリリースをすることを優先したいと考えています。ただし、その前提として、 Issue を利用して設計をいつも以上に詰めることや、他のサービスと連携をする I/O 部分について変更が必要となった場合はメンバー全員に周知をすることとします。

そのため、「基本的にコードレビューは行わないが、設計については細かく共有し変更の通知をすぐに行い、早期のリリースを目指す」としました。

新規開発中の受託サービス

• コードレビューをやるもの
  • 不安なもの
• コードレビューをやらないもの
  • 全部

こちらも未だリリースされていないサービスのゼロからの開発のため、自社サービスと同じ仕組を導入します。また、実は開発がスタートしてから1ヶ月近く経ちますがこの方式で問題は出ていません。 Issue を利用した情報共有や設計の共有が行われているからだと考えられます。

まとめ

コベリン社内でコードレビューの実施を行うかどうかのルールを決定し、試験導入することにしました。こういった大切なルールはやはり昔ながらの「紙に印刷して眼につくところへ貼り付ける」が有効だと思うので、早速印刷をして貼り付けました。

今後、この試みがうまく言っているかどうかを検証する必要があります。開発効率の向上を検証することは難しいといえますが、幸いにもコベリンではイテレーションを作ってベロシティを計測する手法が確立しているため、それによる計測が行えるはずです。

「Pull Request を作ってコードレビューを行いマージをする」という、 開発フローは一見メリットが多いようにも思えますが必ずしも全てのプロジェクトについて万能であるとは言えません。我々は常に今までの当たり前を見直すことが求められていると言えますね。

なお、この試みを行った結果についてもブログで紹介をする予定ですので、しばらくお待ち下さい。

引越ししました

こんにちわ。 コベリンの山口です。

先日の記事でもお知らせしましたが、池袋に引っ越しをしましたヽ(•̀ω•́ )ゝ✧

2016/7/16(土)はコベリンが池袋に引っ越した日として何処かに永遠に刻まれることでしょう。

以前のオフィスとは違って広いのでこんなことや

こんなことをして楽しめます。

まだダンボールが散らばっている状態ですが、これからおしゃれな感じに内装をアレコレする予定です(早速ディアウォールを買いました)。

こちらが例のリストです。

引越しします

どうもこんにちは。 暑さも厳しい季節になってまいりました。 亀山です。

弊社は今度池袋西口に引越します！立教大学の近くです。 またマンションの一室ですが、今より少し広くなるので業務が捗りそうです。 おしゃれな内装を目指して、色々想像中です。

ところでブログをWordpressからはてなブログに引越しました。 Wordpressは自由度も高く慣れていて良かったのですが、使い方に合わせてプラグインをいっぱい入れたりテーマを自分で作ったりした分、管理も面倒になって古いままになり、更新頻度も落ちていったのが問題でした。 はてなブログにはWordpressのインポート機能もあり、有料プランで独自ドメインも使えるのと、株式会社ネクストさんもはてなブログだったなぁと思って引越してみました。

引越しが終わったらまた写真でも載せます！ それではまた。

Android 版 feather 進捗20 #feather_android

Android 版 feather 開発担当の @numa08 です。

皆様こんにちは😎

コベリンでは先日、名刺のデザインを刷新しました。実はメンバー毎の背景のデザインが違うので、もし交換をする機会があれば、見比べて貰えると楽しいです。

さて、Android 版 feather の進捗ですが、 esa にまとめていますのでご確認ください。

イテレーションまとめ

ここでは上記のまとめをふまえて、メンバーの所感を書いていきます。

numa08

ギャップに関する実装を始めたのだが、調査の部分が多いのでリリースに結びつかないのがちょっと歯がゆい。仕方ないので、空いた時間を使って fastlane でビルドとかリリースをする仕組みを作った。以前より CI 環境の管理が手軽になった感じがして良い。

mironal

タブ編集画面のissueに手をつけ始めたが、 issue の粒度が荒かったためバーンダウンチャートに作業の進捗が反映されなかった。もっと細かい粒度で issue を作り進捗が反映されるようにしたい。

ryohey

見た目の修正に慣れてきてできることが増えて楽しいです。今回あまり時間がとれなかったので、次回からそろそろ機能の実装にも加わっていきたいと思います。