オールアバウトの DevOpsと リリースフロー
•Download as PPTX, PDF•
1 like•1,319 views
Remixing with All About, Inc. 2015-06-27（土）13:15 - 17:00 https://remixing.doorkeeper.jp/events/26208
Recommended
More Related Content
What's hot
What's hot (20)
Similar to オールアバウトの DevOpsと リリースフロー
Similar to オールアバウトの DevOpsと リリースフロー (20)
More from Kazuto Ohara
Recently uploaded
Recently uploaded (7)
オールアバウトの DevOpsと リリースフロー
- 2. Remixing 自己紹介 名前 大原和人 (やまと) 略歴 2012年4月～ インフラエンジニア サーバ、ミドルウェアの設計・構築 2015年4月～ 開発エンジニア メディアのエンハンス等 Team TechBall 運用改善、技術力向上 おすすめガイド 男の夜遊びガイド 山田ゴメスさん Copyright 2015 All About,inc. 2
- 3. Remixing 男の夜遊び Copyright 2015 All About,inc. 3
- 4. Remixing アジェンダ オールアバウトが進めてきたDevOps リリースフローの変化(一例として) Copyright 2015 All About,inc. 4
- 5. Remixing はじめに オールアバウトDevOps活動の始まり Copyright 2015 All About,inc. 5
- 6. Remixing 当時の状況 内製化から3~4年経過 開発・インフラ基盤は整ってきた 人数増えてきた サービス増えてきた • アプリケーション(リポジトリ)数 43 • デプロイ数 3/day Copyright 2015 All About,inc. 6 0 10 20 30 40 50 60 70 80 90 Feb-12 Mar-12 Apr-12 May-12 Jun-12 Jul-12 Aug-12 Sep-12 Oct-12 Nov-12 Dec-12 Jan-13 Feb-13 Mar-13 月間デプロイ数
- 7. Remixing 当時の悩み Copyright 2015 All About,inc. 7 なかなか実現速度が 上がらない…orz
- 8. Remixing 原因 開発者と運用者(インフラ)のオーバヘッド リリースを依頼 調査を依頼 多い手動作業 手動テスト 手動リリース たまる技術的負債 コードレビューはたまに 仕様が属人化しまくり スキル不足 Copyright 2015 All About,inc. 8
- 9. Remixing DevOps Copyright 2015 All About,inc. 9 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and- ops-cooperation-at-flickr 開発者と運用者の壁を無くして ビジネスを円滑に進めるためのプラクティス
- 10. Remixing DevOps DevOpsで重要なこと 変化を容易にし、変化によるリスクを低減する サイロ化の排除 具体的には ツール (+スキル) • 高速に、安心してリリースできる環境作り • サーバにログインしない運用 文化 • お互いを理解し、信頼する • 情報の見える化 Copyright 2015 All About,inc. 10
- 11. Remixing オールアバウトのDevOps ツール 高速に、安心してリリースできる環境作り サーバにログインしない運用 Copyright 2015 All About,inc. 11
- 12. Remixing オールアバウトのDevOps 文化 お互いを理解し、信頼する 情報の見える化 Copyright 2015 All About,inc. 12 ワークショップ (勉強会) チームビルディング (飲み会) Team TechBall (技術推進ユニット)
- 13. Remixing リリースフローの話 もう少し具体的に リリースフローの話 Copyright 2015 All About,inc. 13
- 14. Remixing 過去の光景 Copyright 2015 All About,inc. 14 Dev Ops リリースお願いします リリースしました エラー出てます、確認して下さい 直しました、再度リリースお願いします
- 15. Remixing リリースは誰がする？ 開発者が責任をもってリリースするべき 開発者も責任をもってエラーやパフォーマ ンスを確認するべき もちろん、インフラエンジニアも共に確認する Copyright 2015 All About,inc. 15
- 16. Remixing リリースの開放 考慮した点 サーバにログインしなくて良い GUIで簡単に設定できる 履歴が管理できる 権限が管理できる 通知できる テスト自動化できる Copyright 2015 All About,inc. 16
- 17. Remixing 変えなかった点 リリースフォーム リリース日時、理由等を記入 開発者、インフラメンバーに通知される →関係者全員がリリース内容を把握 後から確認もしやすい Copyright 2015 All About,inc. 17
- 18. Remixing リリースフロー Copyright 2015 All About,inc. 18 ・ ・ ・ Staging Production Local Web DB Pre Production Web DB Web DB Testing
- 19. Remixing 結果 リリースサイクルの高速化を実現！ アプリケーション(リポジトリ)数 192 デプロイ数 10/day Copyright 2015 All About,inc. 19 0 20 40 60 80 100 120 140 160 180 200 月間デプロイ数
- 20. Remixing 監視の開放 Kibanaによるパフォーマンスの可視化 パフォーマンス管理ダッシュボード Copyright 2015 All About,inc. 20
- 21. Remixing 監視の開放 Kibanaによるパフォーマンスの可視化 エラーサマリーメール Copyright 2015 All About,inc. 21
- 22. Remixing 結果 アプリケーションエラーが減少！ 開発者が自発的にエラーを確認し対処 Copyright 2015 All About,inc. 22 0 10000 20000 30000 40000 50000 60000 70000 80000 Oct-14 Nov-14 Dec-14 Jan-15 Feb-15 Mar-15 Apr-15
- 23. Remixing 現在の取り組み Infrastructure as Codeを開発者へ 手順書→シェルスクリプト→Chef インフラエンジニアがやる→開発者もやる Copyright 2015 All About,inc. 23
- 24. Remixing 今後やっていくこと より抽象化したインフラ構築 全てコンポーネント化し、それを組み合わせ てインフラ構築 AWS OpsWorksみたいな インフラエンジニアはこういった基盤の整備 ・標準化を行うことが求められる Copyright 2015 All About,inc. 24
- 25. Remixing まとめ ツールの活用 CI、モニタリング 文化 勉強会、ソーシャルコーディング、情報共有 いきなり大きく変えず、課題となっている 部分を少しずつ変えていく Copyright 2015 All About,inc. 25 変化によるリスクを低減する サイロ化を排除する
- 26. Remixing 最後に 無駄な運用の削減 スキルアップ Copyright 2015 All About,inc. 26 クリエイティブな仕事を！
- 27. Remixing JOIN US! WEBエンジニア iOS・Androidエンジニア データ集計・分析エンジニア UI/UXデザイナー Copyright 2015 All About,inc. 27
- 28. Remixing 参考資料 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr John Allspaw & Paul Hammond http://www.slideshare.net/jallspaw/10-deploys-per- day-dev-and-ops-cooperation-at-flickr DevOpsって何？ 宮下剛輔 http://www.slideshare.net/mizzy/devops-4156440 基礎からわかるDevOps 吉羽龍太郎 http://www.slideshare.net/devsumi/2013a1devops Copyright 2015 All About,inc. 28
Editor's Notes
- 2週間くらい前に移転した。70歩くらい。 懇親会はオフィススペースでやります！ これまでのオールアバウト勢をみていただければわかると思いますが、地に足の付いた、辛い部分をさらけ出していくスタイルの発表です。 最先端ではないですが、実際にいかに組織の中で導入してきたか、みたいな部分を感じていただければと思います。
- 3年間インフラエンジニアをやり、この4月から開発をやっています TeamTechBallという技術推進ユニットの活用もやっています オールアバウトには900人くらい専門家がいるのですが、その中で自分の推しメンは山田ゴメスさんです。
- 男子の皆さんには非常に気になる記事たちがあります。
- 内製化から3~4年経過し、開発・インフラの基盤はある程度整ってきました。 内製化を進めるため、人数も増やしていました。 作っているサービスも増えてきました しかし、この頃に感じていたことがありました
- 原因は色々あったと思いますが、大体この辺りが挙げられます リリースは本番サーバでインフラエンジニアが行っていました。エラーの確認などもインフラエンジニアが行っている状況でした。 そこで、開発速度を早めるために活動を行っていかないと行けないと考えていました。
- そこで出会ったのがDevOpsです。 DevOpsは開発者と運用者の壁を無くして、ビジネスを円滑に進めるためのプラクティスです。
- DevOpsで重要なことは変化を容易にし、変化によるリスクを低減する サイロ化というのは言い換えるなら属人化とか壁とかそういうことです。 具体的には、ツールと文化によってこれらを実現していきます。 ツール面では、高速に、安心してリリースできる環境作りや、サーバにログインしない運用というものが求められると思います。 文化面は、お互いを理解し、信頼することと情報の見える化が重要になると思います。
- オールアバウトでも、ビジネスを円滑に進めるためにDevOpsに取り組んできました。 こちらはDevOpsの実現のために導入したツールです。 クラウドの活用も高速なリリースに必要ですし、モダンなフレームワークを導入することも開発速度を速くするという意味ではDevOpsだと考えています。
- 文化面では、bitbucketやQiita Teamといったツールを活用して、ソースコードや仕様等の見える化を行ってきました。 また、勉強会やチームビルディングによって相互理解や知識共有を進めてきました。
- ここからはもう少し具体的に、リリースフローに絞ってお話します。
- こちらは過去の光景です。 開発者は開発が終わるとインフラメンバーにリリースを依頼します。 すると、インフラメンバーが本番サーバ上でリリース作業を行います。 リリース後、エラーが発生した場合はインフラメンバーが確認し開発者に確認を依頼します。 直したら再度リリースを依頼します。 これを繰り返すと、効率も悪いですし、お互いちょっと気まずい感じになります。
- そこで、開発者が責任をもって自分が開発したものをリリースするべきなのではと考えました。 また、開発者もエラーやパフォーマンス確認を行うべきではないかと話し合いました。
- そこでリリースを開発者に開放することにしました。 元々はインフラエンジニアが本番サーバでリリース作業を行っていたので、様々なことを考慮する必要がありました。 ここでもやはり、DevOpsで重要な、高速で安心なリリース環境や、サーバにログインしない運用というところを意識しました。
- ひとつ、リリース開放前後で変えなかったことは、リリース依頼フォームです。 これは、リリース日時や理由が関係者に通知され、リリースカレンダーとして残るものです。 開発者がリリースするようになっても、リリース情報の共有は残したほうが良いと考え、残しました。
- 実際のリリースフローはこちらです。 Bitbucketでレビューしたものをtesting環境でテストし、Staging環境で動作確認を行います。 問題なければ、プレ本番環境にアップし、任意ですが本番データで確認を行います。 そこまで確認が済めば、jenkinsを使って本番にコードをデプロイします。
- 実際にリリースフロー改善した結果、現在では1日に10回程度リリースが行われるようになりました。 もちろんこの取組以外にも人が増えたりなど色々な要因がありますが。
- リリースの次に、監視の開放も行いました。 これまでログデータの確認が煩雑だったのをkibanaを使って簡単に確認できるようにしました。
- 1日のエラーのサマリーを送信し、修正を促すということも行っています。
- こちらの取り組みも、アプリケーションエラー数の減少を実現できました。 何より、開発者が自発的にエラーを確認し対処するという文化が出来たのが良かったです。
- その他現在取り組んでいることとして、Infrastructure as Codeがあります。 インフラエンジニアがChefを触るところまでは出来たので、開発者も触れるように啓蒙活動を行っています。
- その先には、opsworksみたいなものを使って、ポチポチと簡単にサーバ構築できるように持って行きたいと思っています。
- ツールを活用し、少しずつ文化を変えていくことで変化によるリスクを低減し、サイロ化を排除するといった感じです。 ひとつのポイントとして、いきなり大きく変えず、課題となっている部分を見つけ、少しずつ変えていくということが大事だと思います。
- 現在オールアバウトでは、無駄な運用の削減とメンバー個々のスキルアップ活動を積極的に推進しています。