4/26(水)、「GitHubとクラスメソッドの勉強会〜GitHub x AWSの最新DevOps事情〜」参加レポート
はじめに
東京丸の内：株式会社IDOMさんで開催されたGitHub社・クラスメソッド社の合同開催勉強会「GitHubとクラスメソッドの勉強会〜GitHub x AWSの最新DevOps事情〜」に参加してきました。以下、聴講メモ。
メモ
開催概要・諸注意
- クラスメソッド：佐々木大輔さん
- How we ship GitHub
- DevOps
- 色んな人が色んな意味で使ってる
- インフラ効率化
- リリース自動化
- ただの何かのツール
- 大事なのは
- 価値を無駄なく遅滞なく届けること！
- 近年起きていること
- アジャイル
- 三角形はさかさまに
- スコープがFix、リソースとタイムを動かす
- →リソースと時間がFix、スコープを動かす
- →世の中の変化の方が早いので
- イテレーティブに開発しましょうね
- コラボレーションがやりやすく
- 中央集権型→分散型へ
- CI
- 必須のプラクティス
- Continuous deliveryy
- 今のDevOpsブームが目指しているところ
- Continuous deployment
- 常に本番にデプロイされている状態
- ここまで行くべき
- 例
- ネットフリックス
- GitHubでは？
- 数十回デプロイ/日
- GitHubberは世界中に散らばっている
- 60%はリモート
- 日本は11人
- 実際にはもうちょっといる
- 米国が明らかに多い
- 米国各地に散らばっている
- 地理的にもタイムゾーン的にもバラバラ
- どうやっているか？
- GitHub Flow
- Guide.github.com
- Masterを
- 常にデプロイ可能な状態に保つ
- 本番とイコールに
- 必ずブランチを作って開発
- 生存サイクルを短く
- 溜め込まずすぐPull Requestを作り、フィードバックをもらう
- Hubotが大活躍
- Pull Requestブランチを各環境にリリース
- 問題ないものだけMasterにリリース(マージ)
- もし現在のMASTERブランチの内容がPull Requestブランチに無い場合は、まずMSTER→Pull Requestにマージ
- もう一度テスト
- Masterにコミット
- Hubot(ChatOps)
- ディスカッション上で重要な役割
- OSSチャットボットの仕組み
- GitHubで一番働いてるのは人間じゃない！
- チャット上で様々なオペレーションを行う
- なぜチャットか
- Shared Console
- 誰がやっても同じ結果が出る
- 他人がやってる様子をチャット上で見て学べる
- いつでもどこでもリモートワーク
- デプロイだけならスマホでもできる
- さすがにコード書くのにはPCが必要
- Pull Requestリリース時に、自分がどこにリリース可能か、教えてくれる
- Deplyment API
- チャットコマンド上で手軽にリリースできる
- 「queue for github」
- プロダクションへのデプロイ待ち状況をHubotが教えてくれる
- 待ちが発生している間は他の人がデプロイはできない
- Deployment confidence
- デプロイしたものが本番環境でどのように動作しているかを確認できる
- 様々な形での支援
- 自動でISSUEを立ててくれる
- etc
- チャットやグラフで確認可能
- 様々なことを全てChatで
- CIのセットアップ
- 営業的な見積
- メンバーの居場所通知
- Google Map確認
- 画像(ランダム)
- GIF画像
- 近くにいる人
- メンバーのプロフィールをhubotが紹介
- 様々なツールを活用
- GitHub
- Hubot
- Slack
- Janky
- Heaven
- Heroku
- gPanel
- sentinel
- etc...
- まとめ
- 市場のニーズはすごいスピードで変わっていってる
- DevOpsは必須
- さらにその先へ
- リモートで非同期に
- ChatOpsは企業をグローバルかつフレキシブルなスタイルに
- AIが絡んでくる？
DevOpsとAWSサービス
- DevOpsとは？
- DevOpsの目的
- ビジネスに使う時間を増やす
- デプロイ：月1回→毎日10回
- 運用者：10人→3人
- -
- CIとは？
- ビルド・テストの自動化
- 小さくたくさん回す
- 継続的デリバリー(CD)とは？
- CIにデプロイまで含む
- 統合テスト
- AWSサービス紹介
- CodeCommit
- CodeBuild
- CodeDeploy
- CodePipeline
- ビルド・テスト・デプロイ・承認などのワークフロー管理
- CodeStart
- ここまでのCodeXXXを使ってCI/CD環境を一発で作成できる
- マイクロサービス
- Lambda
- API Gateway
- ECS
- Dockerオーケストレーション
- ECR
- コンテナレジストリ
- 他色々
- 時間がないので猛ダッシュで
- サービスをどう選ぶ？
- 時間がないので後で見てね♪
- 実装例
- 例1：CI/CD EC2でBlue/Greenデプロイ
- 例2：CI/CD ECS
- まとめ
- 安全に早くたくさんリリース
- ユーザーに提供する価値を増やす
- リリースフローの見える化、自動化
- モニタリング可能に
- 開発者・運用者・経営者、三方良しに！
感想
とりあえず「GitHubすげえな！」と。チャットってあんなに活用できるもんなんですね。正直ビックリしました。
同様にhubot凄い。オレの友人に頻繁に承認欲求を満たすために褒めることを要求してくるメンドクサイ奴がいるんですが、そいつのメンタルも管理してくれねーかな。(冗談ですよ、ジョーダン)
個人的にはお二人目の千葉さんの発表はかなり参考になりました。ちょうどAWS使い始めたばかりだというのもあり、サービス概要を把握してなかった、というのもありますが、今すぐ活用できそうなサービスがあったのも個人的には嬉しかったです。早速明日試してみようかｎ……いや、明日はダメだ、見積資料作らないとマズイ。
逆に三人目の中山さんのお話は、そもそも情報量が多かったことと、かなりディープな内容だったこともあって、AWSもGitHub Enterpriseも初心者なオレはあっという間に振り落とされました(笑)。最初の事例くらいまでは理解できたんですけどねぇ、GitHub Enterpriseってそんなに色々やんないと使いにくいモンなのかな？ 全然使い込みが足らないオレには、その辺がいまいちピンと来なかったです。でもまぁ実際にニーズがあってお客さんがあっての事例でしょうから、必要なんだろうなぁ。
それはそれとして、クラメソさんの勉強会って、だいぶ久々(数年ぶり？)に参加しました。Adobe Flexとかの頃にはよく参加させて頂いたんですけど。オレ自身、遅まきながらここ最近になってAWSを触り始めたので、また積極的に参加したいですね。
