Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OSS雑メンテ / OSS zatsu maintenance #railsdm

sue445
PRO
December 02, 2017

OSS雑メンテ / OSS zatsu maintenance #railsdm

Rails Developers Meetup 2017 ( https://techplay.jp/event/631431 )の発表資料です

sue445
PRO

December 02, 2017
Tweet

More Decks by sue445

Other Decks in Technology

Transcript

  1. OSS雑メンテ
    2017/12/09 Rails Developers Meetup 2017
    sue445

    View Slide

  2. 自己紹介
    ● Go Sueyoshi a.k.a sue445
    ● 株式会社ドリコム所属
    ● 最近作ったgemは omniauth-chatwork
    ○ https://github.com/sue445/omniauth-chatwork
    ● 最近chatwork gemのメンテナになった
    ○ https://github.com/asonas/chatwork-ruby
    ● 「ドリコムのプリキュアの人」として社内外で有名

    View Slide

  3. 今期の嫁:キュアカスタード

    View Slide

  4. 本妻:キュアピース

    View Slide

  5. 今日話すこと
    ● 雑にOSSをメンテするための意識の低い話

    View Slide

  6. アジェンダ
    ● なぜOSSを作るのか?
    ● 僕が気をつけてること
    注:時間足りないので飛ばし気味でいきます

    View Slide

  7. 最初にまとめ
    ● 全自動化
    ● 情報の集約

    View Slide

  8. なぜOSSを作るのか?
    ● 自分が困ってるから作る
    ● 作ったついでに公開
    ○ ソースを隠す必要があるなら非公開にするけど、その理由
    がなければ全公開

    View Slide

  9. 気づいたら
    ● rubygems.orgにあるgem: 41個
    ○ https://rubygems.org/profiles/sue445
    ● その他OSSにしてるアプリやツール類: 10個弱
    ● sue445製主要OSS
    ○ sue445 Advent Calendar 2016
    ○ https://qiita.com/advent-calendar/2016/sue445

    View Slide

  10. 僕が気をつけてること
    ● CIの使い分け
    ● CIでビルドする
    ● CIで定期ビルドする
    ● ビルドログをSlackに流す
    ● ビルド結果を後からまとめて見れるようにする

    View Slide

  11. CIの使い分け
    ● gem(ライブラリ)ならTravis CI
    ○ Rubyの各バージョン x Railsの各バージョン x DBの種類
    のようなマトリクステストが作りやすい
    ● アプリならCircle CIやWercker
    ○ 細かい差異はあるけどだいたい同じことができるので好み
    の問題

    View Slide

  12. CIでビルドする
    ● CIでビルドする理由
    ○ 自分が書いたコードや送られてきたPRを手元で動作確認
    したくない
    ○ 人間がやるべきことを機械にやらせることで自分が楽がで
    きる
    ● どんな雑なコードであっても最低限CIは設定すべき
    ○ CIが全く無い場合、ひょんなことからPRがたくさん来るよう
    になるとPR見るのがつらくなる

    View Slide

  13. 参考: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

    View Slide

  14. CIで定期ビルドする
    ● CIで定期ビルドする理由(gemの場合)
    ○ gem本体のコードに変更がなくても、依存してるgemのアッ
    プデートによって自分のgemのビルドが壊れることがある
    ため
    ○ よくある例)依存gemがアップデートされた時に古いRuby
    のバージョンをサポートしなくなったが、普通にbundle
    installすると最新が入るので自分のgemの古いRubyでの
    ビルドが失敗する

    View Slide

  15. CIで定期ビルドする
    ● CIで定期ビルドしないと急にPRが飛んできた時に前述の理由
    でビルドが失敗することがある
    ● 自分がPR送る時にmasterブランチのビルドが壊れてるのが
    あるとすっごい嫌なので、自分がメンテしてるgemやアプリは
    全部CIで週1回の定期ビルドしてる

    View Slide

  16. Travis CIで定期ビルドする
    ● cron jobs
    ○ https://docs.travis-ci.com/user/cron-jobs/
    ○ Daily, Weekly, Monthlyで定期ビルド

    View Slide

  17. CircleCI(2.0)で定期ビルドする
    ● Scheduling a Workflow
    ○ https://circleci.com/docs/2.0/workflows/#scheduling-a-
    workflow

    View Slide

  18. Werckerで定期ビルドする
    ● 定期実行するための機能が公式で用意されてなくてAPIで頑
    張るしかなさそうなので自分でツールを作った
    ● https://github.com/sue445/wercker_build_trigger
    ● http://sue445.hatenablog.com/entry/2017/10/08/134155
    ● 下記のようなymlを用意して個人鯖のcrontabから雑に実行

    View Slide

  19. アプリで定期的にbundle updateする
    ● 定期的にbundle updateする理由
    ○ 常に最新のgemを使い続けることでGemfile.lockの鮮度
    を保つため
    ○ 一度に大量にアップデートするよりは細かい粒度でアップ
    デートする方がトラブった時の原因調査がしやすい

    View Slide

  20. アプリで定期的にbundle updateする
    ● 手動でやるのはしんどいので自動でやるのがいい
    ● 依存gemがアップデートされたらPR送ってくれるサービス
    ○ http://tachikoma.io/
    ○ https://dependabot.com/
    ● 自動bundle update後にエラーになった時だけ手動対応
    ○ 主にrubocopで新しいcopが追加された時とか
    ○ たまに依存関係がぶっ壊れて古いバージョンのgemがイン
    ストールされてビルドがエラーになることもあるw

    View Slide

  21. 例:tachikoma.ioの場合

    View Slide

  22. 例:tachikoma.ioの場合

    1. 毎週tachikoma.ioからbundle updateするPRがく

    2. CIのビルドが通っていたらPRをマージ
    3. CIがデプロイまで実行
    という雑な運用

    View Slide

  23. ビルド結果を集約する
    ● ビルド結果をチャットに流す
    ● ビルド結果を後からまとめてみれるようにする

    View Slide

  24. ビルド結果をチャットに流す
    ● 使い慣れたチャットツール使う
    ● 開発者向けのサービスはだいたいSlack連携してるのでSlack
    使うのが無難
    ● 自分の場合、個人Slackにログを全部集約してる

    View Slide

  25. 自分の例:アプリごとにチャンネル作成
    CIのビルド結果以外にもデプロイログや
    エラー通知なども同じチャンネルで見たい
    ため

    View Slide

  26. 自分の例:gemのビルド結果は雑に集約
    GitHubのissueやPR通知を流したければ
    リポジトリごとにチャンネル分けた方がい
    いかも

    View Slide

  27. ビルド結果を後からまとめて見れるようにする
    ● Slackにビルドログを流すだけだと後からどのビルド
    が失敗してるのか追いづらい
    ○ ビルド失敗時のみ通知でもいいんだけど、ビルド
    に時間がかかるgemもあるので成功失敗に関わ
    らず終了時の通知はほしい
    ● 自分の場合メンテしてるリポジトリが40個以上ある
    し、CIツールもTravis CI, Circle CI, Wercker,
    GitLab CIを使ってて結果を見に行くのが大変

    View Slide

  28. ビルド結果を後からまとめて見れるようにする
    CIのバッジを並べて表示するだけのサイトを作った
    https://sue445.github.io/my-ci-badges/
    ビルドが失敗していれば
    ひと目で分かる

    View Slide

  29. 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

    View Slide

  30. まとめ
    ● たくさんのOSSを管理していても「全自動化」と「情報の集約」
    を駆使することで1人でも雑にメンテすることができる

    View Slide