「ソフトウェア業界が直面している最先端のテスト課題」パネルディスカッション聴講レポート #ICST2017

はじめに

  • ICST2017の中で、「Bleeding-Edge Testing Challenges that the Software Industry Faces」(ソフトウェア業界が直面している最先端のテスト課題)というタイトルで、GoogleAppleのエンジニアが登壇して、パネルディスカッションを行いました。

  • ICST2017公式ページ

ICST 2017 | 10th IEEE International Conference on Software Testing, Verification and Validation


セッションのコンセプト(司会のAtif Memonより)

  • 今回のようなセッションに近いこととして「産業界とどのようにやっていくか」という題材をほぼ毎年やっています。
  • 前提として学術界では制約のかかるところからやっていく手法をとってます。
  • しかし毎年「産業界には何も起こらない」という結論になっています。
  • なので今年は少しアプローチを変え、産業界の方々にご登壇して頂き、セッション中に出てくる問題に対して学術界から何かを提供できればと考えております。

登壇者の紹介(司会のAtif Memonより)

  • 話しやすい人を選んでいるつもりです。一人ひとりご紹介します。

John Micco

  • 1日目の基調講演を担当しました
  • GoogleのTACチームにいる
  • テストチームとして自動化を行い、開発者にFeedbackをしている
  • ただし、リサーチもしているし、ペーパーも出している

Murat Ozturk

  • Googleでリサーチをしている
  • パブリッシュもしている。

Adithya Nagarajan

  • Appleに勤めている。
  • リサーチャーの悩んでいることも理解しているはずです。
  • Microsoftなどに転職し、現職はAppleです。
  • Appleのオープン化も進めている。

Bao Nguyen

  • Googleに勤めている。
  • モデルベースをやっている
  • リサーチの結果を使い、業務に活かしている

自己紹介

司会

  • 皆さんはリサーチをサポートしている方々です。
  • まずは5分ずつ話してもらう
  • 特に未解決の部分を話してもらう
  • 登壇者にはこのイベントのFeedbackもくださいと言っている
  • 「ここはリサーチを見ているし聞いている」とか「この部分は産業に関しては必要ない」とか言ってもらいたい。
  • 批判をしていただいても結構です。

Adithya Nagarajan

  • 私の勤めているApple知名度…については聞くまでもないですか。
  • ICSTのような学会イベントには2002年に最後に参加して、そこでは色々なことを学んだ。
  • 15年ぐらいこの業界にいるが、産業界と学術界での色々なGAPを見ていた。
  • 我々は、実は原始的な技術を使ってハイクオリティなサービスを作っている。
    • Fuzzyなツールを使っている。
    • ツールはもっと拡張できるはずだと思っている。
  • 実際にソフトウェア・エンジニアリングを使っている
  • 並列化してアジリティがなければならないと感じている。
  • テスト優位性については変わっていない
  • コラボもできるかもしれないいくつかのエリアがある。
    • データは沢山あります。
      • 仕様データとか。
  • それを使ってテストを改善できるのではないかと思っている。
  • テストスケーリングの問題がある。
    • 優先順位をつけるとか。
  • テストの軽減をしたいと考えている。

Murat Ozturk

  • Adithyaの話を聞いていて、相当似た部分があると感じた
  • Googleに6年以上勤続している
  • ほとんどをテストに関することに費やした
  • マネージャも勉強した。
    • 役割を勉強したいと思った。
    • ロールのカバレッジをしたい
  • ツールとインフラストラクチャもやっている
  • 共通の間違いとして、私たちはテストを書く人だと勘違いされています。
    • 私は最適化をしようとしている。
    • テストケースの効率化などは考えていますが。
  • 問題から始まって、スコープ化して解決しようとしている。
  • Flakyなことをして問題解決をしている
  • 私はあまり良い生徒じゃなかったので、プレゼンテーションの準備が出来ていません。
  • Flakinessは私達のやってきていたことです。
  • どうやったらプロセスの中で緩和できるのか。
  • インフラの中で解決できるのか、これをFlakyテストといっています。
  • どうやって解決するのか。ツールを作って問題を解決したりとか
  • スケールの問題もあります。拡張も重要です。
  • Googleから見た問題に関してお話します。
  • スケールについてはシステムテストレベルだったりテストセットがあります。
  • もっともっと拡張していくと思う。
  • これをうまく最適化できないか考えています。
  • 想像できないぐらい大きいです。
  • ベストなテストケースをなるべく少ない数でできないか考えている。
  • また、その方法を見ていく
  • レイヤーを組み合わせることになると、どのテストをしなければいけないかを見なければいけない。
  • 世の中に非常に多くのアプリケーションが出ている
  • 自動運転車も出ている。
  • この中でももっと調査研究が必要。
  • どういう貢献ができるか、コラボレーションができるか考えている。
  • 皆様に情報を発信し、皆様から情報を得たい。
  • データをどんどん活用してください。
  • 私の方で問題があるので、「誰に聞けば良いですか?」と聞いてくれれば、私が適切な社員を紹介します。

John Micco

  • 解析、仮説については使わなければいけない
  • 問題点は私達が見つけるのとまた違うはず。
  • データセットを見つけてもらえればと思う。
  • 研究もある。
  • もっと大きな産業界のデータセット
  • ただ、問題が少しあります。
  • もっともっとデータを共有するためにオープンにならなければならない。
  • それぞれ独立してリサーチ結果を出している。
  • 同じようなことを同じような問題を抱えていながら別々に発表している。
  • これらを別々にやってはいけないと考えている。
  • 重複してはいけない。
  • 皆さんは接着剤、橋渡しとなるような存在にしてほしい。
  • 機密にするのは意味が分からない。
  • 機密情報でお金を儲けるのではなく、他のところで儲けるべきだ。
  • 全てのデータセットをシェアすべきだと思っている。
  • マニュアルQAはやっていない
  • 2週間1回やっているということを言われたが、本当に必要があればやるべきだと考えている。
  • また他のテクニックについて、Fazzing、自動テストについて。問題はある。
  • 大きなアルゴリズムでバグがあるものはテストしない。
  • リサーチとは違い、適用可能なものからやっていく。
  • 私達ができるものもあった。適さないものもあった。
  • 毎日何百回も起こるので、Flakyの原因を自動的に追求できれば価値があると思う。
  • 似たような問題が他にもあるのだなと驚いた。
  • 現在は99%以上のファームで行われているテストで合格するということです。どれが失敗するか分かる。これはできると思う。
  • 99%を除いた所だけやれば効率良くテストが出来る
  • 回帰テスト・組み合わせテストがある。
  • 例えば、qualityを保証するためにいくつぐらいやれば良いのか
  • 回帰テストを最適化するという話をした。スケジューラの話もした。
  • このようにテストのスケジュールをするにはコンビネーションを考えることが必要です。

Bao Nguyen

  • 私は産業界に移った経歴がある。
  • Scale、スピード、2週間でテストを行う。すぐにテストを行うことがある
  • 同時並行で行うとなると、並行して全部行うことになる。
  • 多ければ良いとなっている。
  • 課題はコミュニケーションの問題がある。
  • Johnさんと同じ。同じ課題に違う方法でやってしまっている。
  • テストもそう。ただし違う意味合いでやっている
  • Googleは仕様を見ていく。
  • 会社によって意味合いが違っていきます。

討論

聴講者

  • スウェーデンの場合、産業界と学会は非常に多くのコラボがある。Ericssonもそう。
  • データがあっても、そのまま使えるわけではない。
  • 例えば関連性が低いものもある
  • このデータは間違っていないのかという確認が必要になっている

Murat Ozturk

  • 確かにそうだと思う
  • 生データはノイズが多くなってしまっている。
  • 研究者のドアを開くという意味で提供したいと思っている。

John Micco

  • 色々なことがデータに入っている。
  • データに有用であるという約束はできませんが、データをサニタイズするだけでも意味がある。
  • とはいえ、リサーチャーによって価値のある物になっていないといけない。

Murat Ozturk

  • 一つ気付いたことがあった。
  • 私はもっと学会に出るべきだと思った。
  • 足がかりはそこからできるのではと感じている

聴講者

  • フライトリサーチをやっている
  • 日常のビジネスと並行することが難しいと感じている。
  • 何かアイディアはありますか?

Adithya Nagarajan

  • モデルベースのテスティングのリサーチャー、学生だった頃、業界はモデルベーステストを使っていなかった。
  • 今やっていることをスケール化していくことができる
  • 業界側ももっと学ぶ必要がある。
  • だんだん起こってくると思う

聴講者

  • リサーチの結果は出ているが、インプリが出来ていない。
  • アイディアはあるが、やり取りをするには時間がかかる。

Murat Ozturk

  • その見方から欠落しているものがある。
  • どう応用し、適用するのか。
  • もしリソースが食うのであれば、インフラも見ていく必要がある。

聴講者

  • リサーチだけでなく業界側も両方必要。
  • How toの部分のチャンス、メソッドをまだ把握できていない。

聴講者

  • 協業していくためにはリサーチのペーパーをソリューションとしてシンプルではないかもしれないが、概念的なものがあれば良い。
    • シンプルなもので適用できるもの
    • 複雑だが適用にローコストなもの。
  • 概念的に素晴らしくても適用が難しいことがある

Bao Nguyen

  • 一つ思うのは、理解し合えていない。
  • ソリューションがシンプルでも進化させていかないと分からない。

Murat Ozturk

  • そのとおりだと思う。
  • 現在だと理論を理解するのにエネルギーを使って、使えるのか考えるのに時間を食う。
  • このソリューションの応用がペーパーでわかると良い

聴講者

  • ソフトウェアエンジニアリングのリーダーをつとめていて、品質などを扱っている。
  • エンジニアは問題を解決するためにできている。
  • 大学、学会と業界にGAPがあるとおっしゃっているが、ソフトウェア・エンジニアリングが科学を用いて解決することをしているはず。
  • デンマークではYahooのクラウドプラットフォームがある。
  • 課題を投げかけてくれれば、これが解決できるかどうかの判断ができるはずだ。

Murat Ozturk

  • 私もそう思う

聴講者

  • 先程の方が仰ったような、シンプルソリューションの話。
  • 通信会社と一緒にやっている。
  • もっともシンプルなものが80%ぐらいしかできない。
  • 洗練することを繰り返すことで皆さんが使えるものになる
  • シンプルソリューションを示すのは産業界としては必要なのかも。
  • もしも必要ならば、こういう可能性があるなという示す

Murat Ozturk

  • そのとおりだと思う。
  • 非常に驚いたが、10年ぐらい学術界に出てなかったが、Industryトラックがあることに驚いた
  • Topicも非常に面白かった。
  • 中間を考えていかなければいけないと感じた。

Bao Nguyen

  • ここで勘違いしてもらいたくないのは、シンプル化はモデルではなくシンボル的なものです。
  • モデルが非常に難しくても、お互いが努力することでもっとわかりやすく出来る。

Murat Ozturk

  • 企業はスケールができる。
  • それがわかった上で、私達が持っているリソースを提供できればと思う。

聴講者

  • おそらく課題を全部が解決したら中小企業になると思う

感想

  • GoogleAppleでも同じようにテストの効率化について悩んでいると知ることができて良かった。
    • ただし、テストケースそのものに興味を持っている点は、テスト設計に興味を持ち、その部分から効率化しようとしている日本のテスト業界とアプローチが異なると感じた。
  • 研究のシンボル化という話はうなずける気がする。
    • 企業の研究についても、結局どうやって他社に適用してもらうかが重要だと思ってる。
  • パネルディスカッションの進め方として、登壇者だけでなく聴講者も参加している形式は良いなと感じた。

テストの教育についてのパネルディスカッションはこちら

nihonbuson.hatenadiary.jp

  • この記事のパネルディスカッションの直後に行われたものです。

「GitLab Meetup Tokyo #1」に参加してきました! #gitlabjp

3月2日、GitLab Meetup Tokyo #1に参加してきました。

gitlab-jp.connpass.com

全体的な感想

  • GitLab CIが当たり前のように出てくるなー

  • GitLab.com事件があったからか、バックアップがHOTな話題だなー

  • 結構改善されてるんだなー

という感じ。

各発表内容の紹介

当日中に記事を書いたので、そのリンクを貼っておきます。

GitレポジトリからCI/CD・コンテナ化を含めた開発統合プラットフォームとしてのGitLabと今後の展開

nihonbuson.hatenadiary.jp

  • GitLabがどれだけ活発なコミュニティなのかということがすごい理解できました!

GitLabの実践的な運用

nihonbuson.hatenadiary.jp

  • 生半可な気持ちでMySQLにしない方が良いということが分かりました。
  • バックアップ大切!

GitLabコミュニティへのコントリビュート

nihonbuson.hatenadiary.jp

  • GitLabに限らず、コミュニティへの貢献方法が学べました!

ここがすごいよGitLab CI

nihonbuson.hatenadiary.jp

  • Twitter上と変わらぬ @sue445 さん節炸裂の発表でした。
  • yamlでスッキリ書けるのって本当に良い!
    • 私もその虜になった一人

GitLab LT

nihonbuson.hatenadiary.jp

  • 4名の方々のLTがありました
  • チームでの運用・大規模な場合の運用など、様々な立場の人の発表でバラエティに富んでいました!

第2回開催決定

  • 第1回の開催中に第2回の募集が開始されました!

gitlab-jp.connpass.com

  • もう一般参加枠は埋まってしまったみたいなので、是非、発表者とかスポンサーでの参加を!

「GitLab LT」聴講レポート #gitlabjp

GitLabを利用したプロジェクト運営

自己紹介

  • @uchienneo

pixivisionの運用

運用方法

Board
  • 自由にレーンを増やせる
  • Issueとの同期はできていない
milestone
  • Issueとの同期は出来ている
  • 期日とかは表示できない
  • 今は自前でタイトルに書いて管理中
長所と短所
  • 開発が活発
  • Markdown記法なのが良い
  • スケジュールを立てたりは難しい

GitLab CIでDocker in docker

自己紹介

  • @jvasseur
  • 日本で12年ぐらい働いている

なぜdocker?

  • 同時実行することが多い
  • docker runnnerでええやん

問題点

  • hostのSELinux設定でコンフリクトの可能性
  • ビルドのcacheがされない→ビルドが長くなる
  • 無理やり実行すると破滅する

簡単なソリューション

  • DIDNをやめてshellを使おう
  • ただ、あまり推奨されない
    • セキュリティの問題とか

良いソリューション

  • Docker v1.13の--cache-fromオプションを使用する
  • 先に最新のイメージをpullしてから--cache-fromする。その後、pushする

Gitlabのバックアップについて

自己紹介

  • @Kirika_K2
  • 社内の開発基盤を見ている
  • GitLabはgitorius統合前から

スナップショットとは

LVMとは

  • 複数の物理ディスクをグループにまとめて論理ディスとして扱う方法
  • lvcreateで論理ボリューム単位でのスナップショットが取得できる
  • ボリュームグループに未使用の領域があること
  • unmountしてからlvconvert --mergeをすることでスナップショット時点に戻せる
  • PostgreSQLもバックアップを取得できる
  • 無停止するには、WOLというトランザクションログもバックアップする必要がある

メリデメ

  • 手軽なバックアプ手段として使える
  • 大量の差分があるとスナップショット領域があふれるかも
  • unmountする必要があるので無停止ができない

まとめ

  • LVMは世代別バックアップのような用途ではなく、静的な状態でバックアップを。

わりと大きい会社でGitLabをホスティングしてみた話

発表資料

www.slideshare.net

自己紹介

  • @jeffi7
  • 社内の開発部門向けにサービスを提供

GitLab前夜s

  • 偉い人からOSSを使った開発環境を作れと言われた

GitLabへの道

  • チームメンバーがGitLabが良いと言ったのでGitLabにした
    • チームメンバーには従いましょう(MGRへ)

救世主現る

  • Docker Version1.0が出た
  • GitLabのイメージが出た

システム構成

  • nginxを加えた以外はシンプルな構成
  • worm stanby
  • PosgreSQLに乗り換えようとしている

トラブル

  • CIのbuild詳細が重い
    • CPUが100%で張り付いていた
  • 10〜70回/分リロードしていた
    • Prometheusを運用中

悩ましいこと

  • 深化早すぎ
  • 部分的にスケールアウトしづらい

これから

  • 楽してDevOpsしたい
  • issueを上げているが、MRを出したい

野望

  • GitLabをもっと流行らせたい
  • Githubを使いたい派が多いけど、社内で使うにはGitLabで
  • DBをぶっ壊しても責められない組織風土が良い
  • 「もしかして:Github」をなくしたい

「ここがすごいよGitLab CI」聴講レポート #gitlabjp

発表資料

ここがすごいよGitLab CI #gitlabjp

自己紹介

  • @sue445
  • ドリコム
  • 絶対にフォローしないで下さい!

GitLab関連でも色々と作成した

  • gitlab_awesome_releaseとか作成

ドリコムとGitLab

ジョブの記述方法

  • yamlだけでスッキリ書ける
  • 2つ以上のジョブの合流もできる
  • 複数のDocker fileを1つのyamlファイルに記載できる
  • 画面でポチる必要があるのが難点
  • ビルドパラメータの軸が2つ以上ある場合は難しい

「GitLabコミュニティへのコントリビュート」聴講レポート #gitlabjp

発表資料

docs.google.com

自己紹介

  • @hiroponz
  • (株)ルビー開発
  • 勤務地は仙台
  • 今日はこれのために出張してきた

GitHubとの違い

  • GitLab ECは開発に参加できる!

類似のOSSとの違い

  • 似たようなものがあるが、それぞれ開発言語が違う
  • 開発リソースが違う
  • マシンスペック
    • 他よりもマシンスペックをくう
      • Gogs < GitBucket < GitLab
  • 大規模利用
    • GitLabはGitLab.comで利用されているので、スペックを上げれば大丈夫(数千人単位も可能)

コントリビュートの話

  • ソースコードの修正
    • 今回メインで話す
  • ドキュメントの整備
    • タイポ直し
  • バグ報告
    • twitterで文句を言ってないで
  • 新機能の提案

きっかけ

  • 前職でGitLabを導入したらバグを踏んだ
    • ShiftJISのバグ
  • わかりそうだったので修正してPRを投稿
  • すんなりマージされた
    • You are Welcome!

わーい、たのしー

  • いっぱいPRを出した
  • GitLab MVPに選ばれた
  • 毎月22日に新バージョンがリリースされる
  • 各リリースのブログポストで発表される
  • 基本的には栄誉賞

コントリビュートのメリット

  • GitLabが便利になる
  • 効果的な使用方法を学べる

GitLabが便利になる

  • 仕事の効率が上がる
  • EEに追加予定の機能をCEにも追加できる
    • EEのissueで見て、実装してCEにMRを送れば良い
    • EEに追加された後のMRはリジェクトされる
  • 社内のGitLabを魔改造しなくてよい
    • GitLabはVerUpのサイクルが早いので辛くなる

GitLabの効果的な使用方法を学べる

  • GitLab社自身がヘビーユーザー
    • 使い方を学べる
    • リリースサイクルの仕方とか
    • 6000を超えるissueの捌き方
      • 多分捌けてない
    • 高速な機能追加の実現方法
  • 開発者間のコラボレーションを眺められる
    • GitLab社はフルリモートチーム
    • 効果的なコードレビューの方法

実践的なRailsの開発知識が身につく

  • Gem fileの参考
  • メンテナンスしやすいコードの書き方
    • コミットログを眺めるだけでも学べる
  • テストコードを書くことをルールとしている
  • 比較的モダンなJS開発ができる

英語でのコミュニケーション能力が身につく

  • ソフトウェア開発の共通言語
  • 応用範囲が広い
  • キャリアにも繋がる

その他諸々

  • 転職の時にプラス
  • 執筆依頼が来る
  • スピーカー依頼が来る

コントリビュートの方法

  • ガイドラインを熟読して下さい
    • 3回ぐらい読めばなんとなく分かる
  • Community Contributionのラベルを貼られた他人のMRを参考にする
    • 社員以外の人

マージされやすくなるポイント

  • Issueがあるかどうか
    • なければ起票してから
  • バグ修正の方がマージされやすい
  • 機能追加の場合、簡単なテストを追加する
    • 1個の正常系のテストだけでも良いので…
  • UIの修正の場合、修正前後のスクリーンショットを貼る
  • パフォーマンスの場合はベンチマークの結果を載せる

注意点

  • DBマイグレーションが必要な場合はダウンタイムを発生させないようにする
    • カラム削除とか
  • パフォーマンスを著しく悪化させない
    • アクセスを著しく増加させるのはNG
  • コードのライセンス
    • CEのマージはEEのマージもされるので、商用利用を認めていないのはNG
    • 機械翻訳のコピペはNG
      • 近々多言語対応されそう
  • 礼儀正しく

英語の壁

  • 高校レベルの英語でもOK
  • 分からなかったらGoogle翻訳
    • 相手も慣れてる
  • GitLab社社員は親切

GitLabIssueBash

「GitLabの実践的な運用」聴講レポート #gitlabjp

資料

qiita.com

自己紹介

  • @catatsuy
  • 会社のアドベントカレンダーで運用方法を公開した
  • Pixivで働いている

  • 個人的には、以前のJTF2015で登壇している印象が強いです。

nihonbuson.hatenadiary.jp

GitLabのインストール

  • インストールはそんなに難しくない

セットアップサーバについて

  • グローバルIPを持つサーバー上に立てることが前提
  • サーバーは1台であることが前提
  • 複数台構成は現実的ではない
    • DBは別IPでもOK

GitLab.comのバックアップ体制

  • 今回問題になったのはあくまでもGitLab.comの問題

GitLabの持っているデータ

  • Radisは最悪吹っ飛んでも問題ない
    • セッションとかキャッシュしか持ってない

GitLabのデータベース

RailsMySQL

  • MySQLの知見がない限りMySQLを使わないほうが良い
    • ハハパパ問題とか

GitLabのバックアップ

  • bundle exec rake gitlab:backup:createでバックアップできる
    • git db create はmysqldumpとかをしているだけ
    • git bumdle createを叩いて保存しているだけ
    • git upload create はファイルをコピーしてtarで固めているだけ
  • 最終的には1つのtarファイルに纏められる
  • 様々なサーバにバックアップファイルを送ることも可能
    • cronしたり
      • 環境変数でcron=1を設定するとエラーしていない場合にログ出力しないことが可能

MySQLのバックアップ

  • dump以外にも、停止してdata_dirをコピーしたりする手段がある
  • リストアも可能

バージョンアップ

  • バージョンアップにはDBのバックアップを録るように書かれている
  • GitLabのバージョンアップで関わるのはDBぐらい
  • 一気にVerUpを上げることも可能
  • 一部、特殊な作業が必要

無停止VerUp

  • ほぼ無理
  • master,slaveでも可能だが手間がかかる
  • アプリケーション起動中に行うことはできない
  • ある程度短くすることは可能だがrakeの時は停止する必要あり

最後に

  • ソースコードもシンプルなので動きを追うことは比較的容易
  • 昔はGHEと呼ばれた時代もあったが、ソースコード公開によるメリットが大きい

「GitレポジトリからCI/CD・コンテナ化を含めた開発統合プラットフォームとしてのGitLabと今後の展開」聴講レポート #gitlabjp

発表資料

qiita.com

自己紹介

  • @tnir
  • Takuya Noguchi
  • Git利用歴10年
  • GitLabはパブリック公開した日から使っていた
  • 所属していた会社で2013年から使っていた
  • 2014年から管理者として利用
  • 2015年からはGitlab.comの混んとりビューア

なぜMeetupを開くのか

  • 日本語の情報がなかったから
    • あっても古い
  • Gitlab.comが話題になったから…ではなく、準備していたら事件が起きた

GitLab.JP

  • 仙台で発足して、3,4回やっていた
  • 鹿児島でも勉強会が開催されていた
  • 東京でもやろう

よく聞くGitLabのイメージ

  • インストールが大変
  • ウェブアプリが遅い
  • GitLab.comでデータがロストした

GitLabの歴史

  • GitLabは後発のサービス
    • 後発の製品でどうやって優位性を持たせるか

GitLab.comの競合

  • GitHub + ecosystem
  • BitBukket + ecosystem

GitLab CE/EEの競合

  • GitHub Enterprise
  • GitBucket
  • Gogs
    • GO言語で出来ている

GitLab CE/EE

  • RailsベースのソースではGitHubの中でスターが一番だった(2016年)

4種のGitLab

  • CE
    • 一番ユーザーが多い
  • EE
    • 有償版
  • .com
  • GitHust.io
    • Saasではなくプライベートで運用したい
    • デジタルオーシャン上で
    • アップグレードやセキュリティを担保
    • $80/月

GitLabマイルストーン

  • 半年ごとにVerUpしていた
  • Ver6からは1年半に1回ぐらいのVerUp頻度
  • 現在はVer8
  • その間に4回資金調達して40億円調達した
  • 3/22のVer9が出る

2016年を振り返る

  • 8.4〜8.15をメジャーリリース
  • 機能がどんどん追加されて

パフォーマンス面

  • 2014から2015年あたりにパフォーマンス劣化が著しくなった
  • 2016年はパフォーマンス改善した
    • 1月にInfluxDBを利用したモニタリング開始
    • 後半はPrometheus導入

管理面

  • omnibus-gitlabが一番手軽なインストール
    • 色々な個人ブログではソースでのインストールも書かれているけど、オススメしない
  • Dockerでもサポート
    • まだまだ巨大なイメージなので、デフォルトの状態だときついかも

PostgreSQL

  • 登壇する人はMySQLユーザーが多いみたい

Radis

  • 現在、2.8から3.2に上げるMRを出しているところ

コンテナレジストリ

  • これもGitLabが提供している

モニタリング

  • 改善はしているがGithub.comに比べるといまいちな部分も

Docs

  • ドキュメント大事
  • docs.gitlab.comがリニューアルされた
  • 英語さえできれば貢献は可能

開発

  • OSSなのでGitLab.com上でコントリビュート可能
  • 日本人は少なそう
  • GitLab Development Kitで簡単に構築可能

Backend

  • 普通のRailsアプリだが、一部GOで書かれている

Frontend

  • jqueryが多い
  • テストはJasmine+Karma

UI/UX

  • 最初はデザイナーが少なかったが、最近増えた
  • GL社員がちょっと多すぎる気がする

パッケージング

  • chef/omnibusパッケージを使用している

コミット以外の貢献方法

  • イイねを押すことも貢献の一つ
  • GitLab Pagesもいいねが100を超えて実現した

個人的な野望

  • Cloud-native
  • Server-less
    • 現状だと難しいかも

250人のチームで運用してみてわかったこと

  • Gitの習熟度がバラバラ
  • 高品質化のためにトレーニングが有効的
    • GitLab Docsが有効
    • ただし日本語訳がない

バグフィックス

  • 昼、起票
  • 夜、修正
  • 時差があるので、夜活動が他国の人にとって良いみたい

今後に向けて

  • 組織の方針とGitLab.incの方針(技術選択)が合致したのでうまくやってこれた。
  • 組織毎に主体的な開発戦略が必要

今日伝えたかったこと

  • かなり改善されてきた
  • OSSに貢献してよりよいツール・プラットフォームを使いましょう
    • 社内でパッチを当てるとかではなくMRを!

宣伝

  • 第2回を開催決定しました。
  • 4/11にリクルートでやります!