GitHubとクラスメソッドの勉強会に行ってきた #github_method

GitHubとクラスメソッドの勉強会に行ってきました。簡単に所感をまとめます。

classmethod.connpass.com

今回のテーマは「GitHub x AWS の最新 DevOps 事情」です。

  • DevOps はインフラ自動化やリリース自動化など、ひとによって捉え方は違う
  • 価値を無駄なく遅滞なく届けることが重要
  • かつてはスコープに対してスケジュールやリソースを決めていた
  • 近年はこの関係が逆転して、スケジュールとリソースがある上でスコープを決める
  • VCSによるコラボレーションをやりやすくする
    • 中央集権型から分散型へ
  • CI は必須のベストプラクティス
  • Continuous Delivery : 継続的にデリバリーする
  • Continuous Deployment : 継続的にデプロイする
  • GitHub の開発者は世界中にいる
    • それでも1日のデプロイは100回に及ぶことも
    • それを支えるのは GitHub FlowHubot (ChatOps)
  • master を常にデプロイ可能に保つ (本番とイコール)
    • 本番にデプロイして問題がないものを master にマージする
      1. master から feature を作ってコミットを加える
      2. PR を作って開発者みんなでレビューする
      3. レビューで問題がなければ PR ブランチを本番にデプロイする
      4. 本番で問題がなければ master にマージする
    • 本番にデプロイした PR ブランチに問題があれば master をデプロイする
  • master にマージしてからデプロイすると問題があった場合に master が不安定な状態になってしまう
  • 1回本番にデプロイされると、問題ないことが保証されるまでは次以降のデプロイはロックされてキューイングされる
  • Chat は Shared Console である
    • オープンなコンソール (みんなで見ることができる)
    • 誰がやっても同じ結果になる
    • ゆくゆくは AI が絡んでくるかな?

GitHub Flow は2011年頃に出てきたものですが、中のひとたちは割と早い段階で今の運用に変えていたようです。当時、日本にはそのあたりの情報があまりなかったため、池田さん自身もチーム開発実践入門を執筆した段階ではご存知なかったらしいです。
また、1回でデプロイされる変更ボリュームは数十行程度。敢えて小さくしている。1日のトータルは3000行くらいだが、一気にデプロイするのではなく、30行を100回に分けてデプロイするような感じ。とのこと。

www.slideshare.net

  • DevOps の目的はビジネスに使う時間を増やすこと
    • 決まりきった運用や手運用を自動化する
    • 障害対応の時間を減らす
  • CodeDeploy ではデプロイとプロビジョニングを混ぜないように注意
    • プロビジョニングは OS やミドルウェアのための設定
    • プロビジョニングとデプロイではライフサイクルが違う
    • CodeDeploy ではプロビジョニングはしない
  • AWS を使うならマネージドサービスを使うことを第一に検討する
    • 安定性やサービス連携、運用負荷を減らす観点から
    • 標準のサービスでは要件に合わない場合には自前で作る
  • GitHub Enterprise を使う場合は標準で提供している設定や機能を使う
    • アップデートで /data/user 以外が上書きされるため
    • 運用負荷を減らす

AWS については圧倒的経験不足のため、CodeStar をはじめ、多くの DevOps 関連のサービスが提供されていることを初めて知りました...。