継続的デリバリーと読み解く Web 開発あるあるとその対策

4,996 views

Published on

これまで Web 開発の現場で経験してきたあるあるを継続的デリバリー片手に振り返ってみます。また最近どういったツールを現場で活用しているかについてもご紹介します。

※ どんな主旨で作ったスライドかはてなブログに書きました。
http://beniyama.hatenablog.jp/entry/2014/06/18/011411

Published in: Technology
0 Comments
25 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,996
On SlideShare
0
From Embeds
0
Number of Embeds
301
Actions
Shares
0
Downloads
45
Comments
0
Likes
25
Embeds 0
No embeds

No notes for slide

継続的デリバリーと読み解く Web 開発あるあるとその対策

  1. 1. 継続的デリバリーと読み解く Web 開発あるあるとその対策 山邉 哲生
  2. 2. 某外資系携帯メーカーの研究所 ↓ 解散になったので大学に出戻り ↓ フィンランドで1年 ↓ 渋谷で Web エンジニア(今ココ)
  3. 3. Web 開発の現場で起きている問題 と カイゼンの取り組み
  4. 4. 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 (アスキー・メディアワークス)
  5. 5. いつまで手動で デプロイしているんですか?
  6. 6. 2年前の話
  7. 7. とあるサービス開発現場
  8. 8. Apache Tomcat Struts / Java MySQL
  9. 9. 開発用サーバー (dev)個人の開発環境 (local) SVN リポジトリ チェックアウト 開発&確認 コミット アップデート ビルド&確認
  10. 10. 開発用サーバー (dev) SVN リポジトリ チェックアウト ビルド&デプロイ (rsync) 本番用サーバー群 (live) リリース 確認
  11. 11. 何か問題でも?
  12. 12. ありすぎました
  13. 13. 1. 君と僕の開発環境は違う
  14. 14. 開発用サーバー個人の開発環境 SVN リポジトリ チェックアウト 開発&確認 コミット アップデート ビルド&確認 Wiki に書かれた不完全な手順 誰もがはまるインストールエラー 構築するたびに変わるバージョン
  15. 15. 『僕の環境なら動くんですけど』 © 地獄のミサワ (http://jigokuno.com/)
  16. 16. 『僕の環境では動きません』 © 地獄のミサワ (http://jigokuno.com/)
  17. 17. 君と僕の開発環境は違うし 開発用サーバーも違うし なんなら本番だって違うかもしれない
  18. 18. 止まらない不信感 終わらないデバッグ
  19. 19. あるプロジェクトで、本番環境へのデプロイメントが謎 の失敗を起こすことがあった。デプロイメント用のスク リプトがハングしたのだ。原因を追跡した結果わかった のは、運用サーバーのログインシェルが sh に設定されて いるのに対してステージングサーバーでは bash になっ ているということだった …(中略)… 本当に微妙な違 いを見つけるのは、これよりもずっと難しいことだ。総 合的な構成管理は必須である。 コラム『構成管理がまずいとリリース当日にデバッグ作 業をするはめになる』 (p351) ( ゚∀゚)・∵.グハッ!!
  20. 20. よくあることだが、開発者自身の作業端末はおろか開発 チームの継続的インテグレーション環境でさえも職人芸 になってしまっており、長期間にわたって粗雑な管理が 続けられている。 これらの環境は、アプリケーションが 実際に動作する環境と関連があるとはとても言えない状 態だ。 非効率の根源にもなり得る。 11.4.1 サーバーのプロビジョニング (p349) ( ゚∀゚)・∵.グハッ!!
  21. 21. 『構成管理』 『プロビジョニング』
  22. 22. 2. 気まぐれなテスト
  23. 23. 開発用サーバー (dev)個人の開発環境 (local) SVN リポジトリ チェックアウト 開発&確認 コミット アップデート ビルド&確認 勘と経験による打鍵テスト 既存機能を破壊する新機能 IE/Chrome/FF/iOS/Android … という多様な 機種をカバーする限界 trunk に混入し続ける動作しないコード
  24. 24. 開発用サーバー (dev) SVN リポジトリ チェックアウト ビルド&デプロイ (rsync) 本番用サーバー群 (live) リリース 確認 リリースしてから気づいてバージョンを 戻して再デプロイ
  25. 25. 機能が増える度に低下する サービス品質
  26. 26. 機能が増える度に低下する コード品質 ≒ 怖くてできないリファクタリング
  27. 27. 明確でない受け入れ条件 (機能・品質)
  28. 28. 『継続的に実行されるテスト』 『既存の振る舞いを保証する』 『不純物の混入を避けるプロセス』 『受け入れ条件』
  29. 29. 3. オレオレデプロイ
  30. 30. 開発用サーバー (dev) SVN リポジトリ チェックアウト ビルド&デプロイ (rsync) 本番用サーバー群 (live) リリース 確認 対象サーバーに入って rsync -> ビルド -> AP 再 起動を行う独自スクリプト 似たような名前の様々なスクリプトが存在 (html_deploy.sh, app_deploy.sh, template_deploy.sh …)
  31. 31. 作った人しかわからない 亜種スクリプトが量産される (e.g., html_deloy_bk_20140616.sh)
  32. 32. エラー検知が甘かったり rsync が同期しきれて いなかったりする
  33. 33. 各サービス・各サブシステムの デプロイがオレオレすぎてつらい
  34. 34. 『手順どこでしたっけ?』
  35. 35. そこで取り組んでみたこと
  36. 36. 個々人が、他者に影響されない 本番環境と同じ構成の開発環境を持つ
  37. 37. 個々人が、他者に影響されない 本番環境と同じ構成の開発環境を持つ
  38. 38. 開発用サーバー (dev)個人の開発環境 (local) Web AP DB Web AP Web AP Web/AP の動作環境を 揃えるのが大変
  39. 39. 開発用サーバー (dev)個人のPC Web AP DB リモートログイン 何か障害や大きな負荷が あると開発できなくなる DB 共有するとスキーマの変 更やテストがしづらい
  40. 40. 開発用サーバー (dev)個人のPC Web AP DB Web AP DB 仮想環境 リポジトリ (git)
  41. 41. 環境設定を手作業でやっているせいで個々の環境が微妙 に異なってしまい、それが原因で問題が発生するという ことについてはすでに議論してきた。仮想化技術を使え ば、本章で紹介してきたテクニック (サーバーや環境のプ ロビジョニングの自動化)の恩恵をさらに膨らませること ができる。 11.7 仮想化 (p364)
  42. 42. http://www.vagrantup.com/
  43. 43. Vagrant • VirtualBox や VMWare といっ た仮想化技術を開発用途に使い やすくするためのツール
  44. 44. vagrant init
  45. 45. VAGRANTFILE_API_VERSION = "2" Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = "chef/centos-6.5" config.vm.network :private_network, ip: "192.168.33.10" end
  46. 46. vagrant up/halt
  47. 47. vagrant destroy
  48. 48. おかしくなったら すぐ壊してやり直せる
  49. 49. 個々人が、他者に影響されない 本番環境と同じ構成の開発環境を持つ
  50. 50. 『構成管理』 『プロビジョニング』
  51. 51. http://www.getchef.com/chef/ | http://www.ansible.com/home
  52. 52. VAGRANTFILE_API_VERSION = "2" Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = "chef/centos-6.5" config.vm.network :private_network, ip: "192.168.33.10" config.vm.provision :ansible do |ansible| ansible.playbook = "./roles/web/site.yml" ansible.inventory_path = "./roles/web/hosts.local" ansible.limit = 'all' end end
  53. 53. vagrant provision
  54. 54. • Ruby の DSL を利用 • opscode に登録された第三者の recipe を再利用できる • 結構タイトに構造化されている Chef
  55. 55. • YAML でデータをいじるので Python を意識しないで良い • ほぼ全部入でクライアントレス • 柔軟なディレクトリ構造 Ansible
  56. 56. 一元化された手順で 『自動的に』 環境構築する
  57. 57. ローカルで仮想マシンを立てて 何度もプロビジョニングして 最後まで通るようになったら リポジトリに push する
  58. 58. 環境のコーディング
  59. 59. Code as Infrastructure
  60. 60. http://serverspec.org/
  61. 61. Serverspec • プロビジョニングコードをテス トするためのツール
  62. 62. 開発から本番まで一気通貫で 仮想マシンを活用した開発を 行うための試み
  63. 63. http://www.docker.com/
  64. 64. Docker • コンテナ型仮想化による軽量な仮想 環境の提供 • 設計思想として1コンテナ1サービス • 状態を保持しない ”使い捨て” イメー ジ (Immutable Infrastructure)
  65. 65. 隔離 検査 破棄
  66. 66. 再生成
  67. 67. これは、我々の知る限りで最も強力なリリース管理テク ニックである。本番環境としてまったく同じ環境を2組 用意するという考え方で、それぞれをブルーおよびグリー ンと呼ぶ。 10.4.3 ブルーグリーン・デプロイメント (p319)
  68. 68. (キャッシュ目的とはいえ) ミドルやライブラリを構造化して 管理している Chef や Ansible とは 対象的にコマンドの羅列に なっている点が興味深い
  69. 69. 定式化されたデリバリーフローを 定義する
  70. 70. trunk/master ブランチを守る
  71. 71. A successful Git branching model http://nvie.com/posts/a-successful-git- branching-model/ x GitLab x コードレビュー
  72. 72. http://nvie.com/posts/a-successful-git-branching-model/
  73. 73. https://www.gitlab.com/
  74. 74. テスト・デプロイ自動化
  75. 75. Jenkins • 継続的インテグレーションを行 うためのツール • リモートマシン上でのテストを 駆動したりメトリクスを可視化 したりいろいろできる
  76. 76. Capistrano • デプロイ自動化のためのツール • デプロイ対象のサーバーとその ロール、処理内容などを記述 • 過去履歴を保持してロールバッ クを行うこともできる
  77. 77. OS/MW => Chef/Ansible アプリ => Capistrano
  78. 78. http://capistranorb.com/
  79. 79. 誰でも統一された手段でデプロイを 実行できる
  80. 80. 誰でも安易にデプロイを 実行して既存環境を変更できてしまう
  81. 81. まだまだお話したいこと たくさんありますが
  82. 82. 続きは Web で
  83. 83. たとえば 『アジャイル開発手法 (スクラム、 XP) の導入事例』 http://recruit.gmo.jp/engineer/ jisedai/blog/20140509_agile/
  84. 84. まとめ • Web 開発の現場で活用されている技術につい てご紹介しました • Web サービスは作って終わりではなく、リリー スしてからの開発・運用プロセスをいかに効 率的・効果的に回すかが重要 (DevOps) • 継続的デリバリーに興味を持った方は、ぜひ アジャイル開発についても調べてみてください
  85. 85. ご清聴ありがとうございました

×