AWS×github Workshop に参加してきました
11/16(土) にアマゾンジャパン（目黒）で行われた「AWS×github Workshop」に参加してきました。
勉強会の詳細はこちら
http://www.zusaar.com/event/1307006
●Github Training Teamによるgithub基礎演習的なハンズオン
- GitHub Training Team(English)
- Participatory: What is a Git repository? Creating a Git repository.
- Participatory: GitHub Pages.
- Participatory: Using GitHub to collaborate with Pull Requests.
- GitHub Training Team(English)
- Participatory: Branching and merging with ease to showcase the GitHub flow and Pull Requests again.
- Demonstrative: Using Haystack to search for an exception.
- Demonstrative: Using Campfire to build an app and send it to production.
- Participatory: Automatic Issue closing on commits, merging.
gitとは何か、というレベルから説明していただき、gitを使う理由やgitとGithubの違いなどを説明していただいた後、
という初歩の初歩から
- sampleプロジェクトをfork/git clone
- ローカルブランチを作成して、ローカルで変更
- 変更内容をcommit
- ブランチをGithubへpush
- master branchへpull request
といったpull requestの基本的な流れをハンズオン形式で行いました。ハンズオン中もGithubのJohnとMatthewがジョークを交えながら比較的わかりやすい英語で説明していただき、逐次通訳もあったのでしっかりと理解できました。前半の「gitとは」「Githubとは」のあたりでJohnが話していた「gitを使う理由」（Githubを使う理由？）として
- Makes your work much easier（あなたの仕事をより簡単）
- Distributed, Easy to branch and merge（分散型なのでブランチ操作とマージが簡単）
- Easy to collaborate（共同作業がしやすい）
を挙げていましたが、後述するクックパッド高井さんの発表で上記をそのまま実践している印象を受けました。一休では未だsvnなので、gitへの興味が導入への意欲に変わった気がしました。また、Github Pagesという自分のプロジェクトを公開できるサービスなども紹介していただき、改めて「Github良いな～」という印象を持つことができました。
●クックパッドにおけるAWSとGitHub Enterpriseの活用 / How we use GitHub and AWS together at COOKPAD（COOKPAD 高井直人さん）
●発表資料はこちら
https://speakerdeck.com/takai/how-we-use-github-and-aws-together-at-cookpad
クックパッドがAWSとGithub Enterpriseをどのように活用して開発・運用を行っているか、というテーマでとてもためになるお話を聞くことが出来ました。「5つのTipsを紹介します」という内容で以下のようなお話でした。
- 5 pro tips for successful github on AWS
- 毎回プルリクエストでやりとりする
- Github FlowとFeature Toggleを使う
- エンジニアじゃない人もGithubに巻き込む
- 継続的デリバリーのために、Githubをハブとして使う
- DevOpsのインタフェースとして使う
毎回プルリクエストでやりとりする
master branchへのマージはプルリクエストを通してコードレビューを必須とする。これによって今まで「暗黙知」として各エンジニアに蓄積されていたナレッジがシェアされていったそうです。これ、非常に良い傾向ですよね。プルリクエストの内容はGithubに勝手に溜まっていくわけだし、その後に類似のプルリクがあれば「コレ見て直してみて」とかって簡単に言えるし、知識のシェアって言うほど簡単じゃないので、導入メリットは十分にあると感じました。
Github FlowとFeature Toggleを使う
Feature Toggleって概念は元々理解していましたが、初めて聞いたのでちょっと調べてみました。「達人プログラマー」のアンドリュー・ハントが提唱した理論（機能？）で
「新しい機能の効果を試すときにすべてのユーザで試すのではなく、一部のユーザに限定公開することで本番環境へのデプロイをしやすくし、より早くユーザからのフィードバックを得よう」
みたいな、そんな意味合いのようです。で、クックパッドではchankoというフレームワークを使って上記を実現しているそうです。chankoもGithub上で公開しているので、中身も見られます。
chankoはこちら
https://github.com/cookpad/chanko
エンジニアじゃない人もGithubに巻き込む
Githubはブラウザからもコミットできる（Redmine、Backlog的な使い方ですかね）ので、エンジニア以外のメンバーともGithub上でやりとりをしている。これによって非エンジニアはエンジニアに話しかけやすくなってきている。また、開発にはあまり関係しないような話もGithub上で行われている（馴染んできているということでしょうか）。これも羨ましい限りですね。一休ではRedmineによるチケット駆動型開発を他の部署も巻き込んでやりとりしていますが、非エンジニアのRedmineに対する抵抗感はハンパじゃなく、チケットの内容が要領を得ていなかったり、不足しすぎていて何を開発したら良いのかわからなかったり、チケットステータスは全然更新してくれない（Redmineを見てくれない）なんてことが日常茶飯事になっています。導入時にきちんとコミットできなかったというミスはありますが、改善点は山ほどあるという状況なのでクックパッドのような成功例を見習って改善していきたいですね。
継続的デリバリーのために、Githubをハブとして使う
クックパッドでは1日に11回以上という頻度で本番環境へデプロイしている。本番環境へのデプロイルールを整備し、自動化することで継続的にデプロイを可能にしている。というお話。興味深かったのは「本番環境のDBをテスト環境のDBにレプリケーションしている」というお話です。やはりデータ量によってSQLの実行計画も変わってしまうし、テスト環境では再現しないけど、本番環境で再現するという問題も起こりかねないので素晴らしい取り組みだと思って聞いていました。実際にやるとなると色々問題が起こりそうだなと思ったので、発表後に高井さんに
- テストデータやまだ未リリース状態のDB定義変更がレプリとコンフリクトしたりしないか
という点について質問してみたのですが以下の回答をいただきました。
- レプリがコケることはあるが、Cronで自動リトライをかけている
- テストデータについてはID採番のレンジを分けて管理することで回避している
- 未リリースのDB定義変更によってコケるものは無視している
なるほど、という回答ですね。定義変更はもう仕方がないものとして無視する、、納得です。それ以上にメリットがある取り組みなので、一休でもレプリとまではいかないかもしれませんがデイリーとかでやれないか、検討してみたいなと思いました。
DevOpsのインタフェースとして使う
これはDevOpsDaysでクックパッドのインフラ部長である成田さんがお話をしていた内容なのでちょっと割愛しますが、テーブル定義とか、テーブルの説明とかをGithub上に挙げておけばスタートアップメンバーの理解促進や定義変更のプルリクエストなどを比較的容易に管理できる。インフラと開発がシームレスにやりとりできるよ。というお話。
総括として高井さんがお話されていた「コードの品質は事業に影響を与える」という件はまさにそのとおりだと思いました。コードに負債を抱えたまま、突貫工事的な対応を続けていくとテストのないレガシーなコードが新しく作りたい機能に影響を与え、同じようなテストを繰り返しては潜在バグを貯めこんでいくという負のスパイラルに陥ると事業のスピードに開発のスピードがついていけなくなってしまう、ということですね。
最後のOpsWorksについては若干集中力が切れ、あまりメモをとれず、スライドを眺めているという勿体無い聞き方をしてしまったため、今回は割愛させていただきます。申し訳ありません。
今回はAmazonさんの素敵なセミナールームでボリューミーな内容の濃いセミナーで大満足の休日を過ごせました。主催のAmazonさん、Githubさんに御礼申し上げます。また、第二回や類似のワークショップイベントがありましたらぜひ、参加させていただきます。
