Rails Developers Meetup 2017 ( https://techplay.jp/event/631431 )の発表資料です
OSS雑メンテ2017/12/09 Rails Developers Meetup 2017sue445
View Slide
自己紹介● Go Sueyoshi a.k.a sue445● 株式会社ドリコム所属● 最近作ったgemは omniauth-chatwork○ https://github.com/sue445/omniauth-chatwork● 最近chatwork gemのメンテナになった○ https://github.com/asonas/chatwork-ruby● 「ドリコムのプリキュアの人」として社内外で有名
今期の嫁：キュアカスタード●
本妻：キュアピース
今日話すこと● 雑にOSSをメンテするための意識の低い話
アジェンダ● なぜOSSを作るのか？● 僕が気をつけてること注：時間足りないので飛ばし気味でいきます
最初にまとめ● 全自動化● 情報の集約
なぜOSSを作るのか？● 自分が困ってるから作る● 作ったついでに公開○ ソースを隠す必要があるなら非公開にするけど、その理由がなければ全公開
気づいたら● rubygems.orgにあるgem: 41個○ https://rubygems.org/profiles/sue445● その他OSSにしてるアプリやツール類: 10個弱● sue445製主要OSS○ sue445 Advent Calendar 2016○ https://qiita.com/advent-calendar/2016/sue445
僕が気をつけてること● CIの使い分け● CIでビルドする● CIで定期ビルドする● ビルドログをSlackに流す● ビルド結果を後からまとめて見れるようにする
CIの使い分け● gem（ライブラリ）ならTravis CI○ Rubyの各バージョン x Railsの各バージョン x DBの種類のようなマトリクステストが作りやすい● アプリならCircle CIやWercker○ 細かい差異はあるけどだいたい同じことができるので好みの問題
CIでビルドする● CIでビルドする理由○ 自分が書いたコードや送られてきたPRを手元で動作確認したくない○ 人間がやるべきことを機械にやらせることで自分が楽ができる● どんな雑なコードであっても最低限CIは設定すべき○ CIが全く無い場合、ひょんなことからPRがたくさん来るようになるとPR見るのがつらくなる
参考：CIを設定しなくて失敗した例https://github.com/sue445/jenkins-backup-script● 最初はシェルスクリプト1つだけ○ https://github.com/sue445/jenkins-backup-script/tree/0.0.1● だんだん使われだしてテスト無いとPR見るのがつらくなってきたので最終的にitamae, serverspec, Wercker, Vagrant,DIgitalOceanでガッツリCI構築した○ https://github.com/sue445/jenkins-backup-script/tree/0.1.9
CIで定期ビルドする● CIで定期ビルドする理由（gemの場合）○ gem本体のコードに変更がなくても、依存してるgemのアップデートによって自分のgemのビルドが壊れることがあるため○ よくある例）依存gemがアップデートされた時に古いRubyのバージョンをサポートしなくなったが、普通にbundleinstallすると最新が入るので自分のgemの古いRubyでのビルドが失敗する
CIで定期ビルドする● CIで定期ビルドしないと急にPRが飛んできた時に前述の理由でビルドが失敗することがある● 自分がPR送る時にmasterブランチのビルドが壊れてるのがあるとすっごい嫌なので、自分がメンテしてるgemやアプリは全部CIで週1回の定期ビルドしてる
Travis CIで定期ビルドする● cron jobs○ https://docs.travis-ci.com/user/cron-jobs/○ Daily, Weekly, Monthlyで定期ビルド
CircleCI(2.0)で定期ビルドする● Scheduling a Workflow○ https://circleci.com/docs/2.0/workflows/#scheduling-a-workflow
Werckerで定期ビルドする● 定期実行するための機能が公式で用意されてなくてAPIで頑張るしかなさそうなので自分でツールを作った● https://github.com/sue445/wercker_build_trigger● http://sue445.hatenablog.com/entry/2017/10/08/134155● 下記のようなymlを用意して個人鯖のcrontabから雑に実行
アプリで定期的にbundle updateする● 定期的にbundle updateする理由○ 常に最新のgemを使い続けることでGemfile.lockの鮮度を保つため○ 一度に大量にアップデートするよりは細かい粒度でアップデートする方がトラブった時の原因調査がしやすい
アプリで定期的にbundle updateする● 手動でやるのはしんどいので自動でやるのがいい● 依存gemがアップデートされたらPR送ってくれるサービス○ http://tachikoma.io/○ https://dependabot.com/● 自動bundle update後にエラーになった時だけ手動対応○ 主にrubocopで新しいcopが追加された時とか○ たまに依存関係がぶっ壊れて古いバージョンのgemがインストールされてビルドがエラーになることもあるｗ
例：tachikoma.ioの場合●
例：tachikoma.ioの場合●1. 毎週tachikoma.ioからbundle updateするPRがくる2. CIのビルドが通っていたらPRをマージ3. CIがデプロイまで実行という雑な運用
ビルド結果を集約する● ビルド結果をチャットに流す● ビルド結果を後からまとめてみれるようにする
ビルド結果をチャットに流す● 使い慣れたチャットツール使う● 開発者向けのサービスはだいたいSlack連携してるのでSlack使うのが無難● 自分の場合、個人Slackにログを全部集約してる
自分の例：アプリごとにチャンネル作成CIのビルド結果以外にもデプロイログやエラー通知なども同じチャンネルで見たいため
自分の例：gemのビルド結果は雑に集約GitHubのissueやPR通知を流したければリポジトリごとにチャンネル分けた方がいいかも
ビルド結果を後からまとめて見れるようにする● Slackにビルドログを流すだけだと後からどのビルドが失敗してるのか追いづらい○ ビルド失敗時のみ通知でもいいんだけど、ビルドに時間がかかるgemもあるので成功失敗に関わらず終了時の通知はほしい● 自分の場合メンテしてるリポジトリが40個以上あるし、CIツールもTravis CI, Circle CI, Wercker,GitLab CIを使ってて結果を見に行くのが大変
ビルド結果を後からまとめて見れるようにするCIのバッジを並べて表示するだけのサイトを作ったhttps://sue445.github.io/my-ci-badges/ビルドが失敗していればひと目で分かる
my-ci-badges● 使ってる技術○ Vue.js○ Bootstrap v4.0.0-beta○ GitHub Pages● ご自由におforkください● https://github.com/sue445/my-ci-badges● http://sue445.hatenablog.com/entry/2017/09/17/190306
まとめ● たくさんのOSSを管理していても「全自動化」と「情報の集約」を駆使することで1人でも雑にメンテすることができる
sue445
hnw
akki_megane
harukasakihara
you
tbaldauf
yururoi
oracle4engineer
yanzm
megabitsenmzq
line_developers
daina0321
____rina____
phodgson
roundedbygravity
geoffreycrofte
jasonvnalue
hatefulcrawdad
sachag
destraynor
quramy
mclloyd
notwaldorf
zakiyama
shpigford