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

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