これまで Web 開発の現場で経験してきたあるあるを継続的デリバリー片手に振り返ってみます。また最近どういったツールを現場で活用しているかについてもご紹介します。 ※ どんな主旨で作ったスライドかはてなブログに書きました。 http://beniyama.hatenablog.jp/entry/2014/06/18/011411

1. 継続的デリバリーと読み解く
Web 開発あるあるとその対策
山邉 哲生

2. 某外資系携帯メーカーの研究所
↓
解散になったので大学に出戻り
↓
フィンランドで１年
↓
渋谷で Web エンジニア（今ココ）

3. Web 開発の現場で起きている問題
と
カイゼンの取り組み

4. 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 (アスキー・メディアワークス)

5. いつまで手動で
デプロイしているんですか？

6. ２年前の話

7. とあるサービス開発現場

8. Apache
Tomcat
Struts / Java
MySQL

9. 開発用サーバー (dev)個人の開発環境 (local)
SVN リポジトリ
チェックアウト
開発＆確認
コミット
アップデート
ビルド＆確認

10. 開発用サーバー (dev)
SVN リポジトリ
チェックアウト
ビルド＆デプロイ (rsync)
本番用サーバー群 (live)
リリース
確認

11. 何か問題でも？

12. ありすぎました

13. 1. 君と僕の開発環境は違う

14. 開発用サーバー個人の開発環境
SVN リポジトリ
チェックアウト
開発＆確認
コミット
アップデート
ビルド＆確認
Wiki に書かれた不完全な手順
誰もがはまるインストールエラー
構築するたびに変わるバージョン

15. 『僕の環境なら動くんですけど』
© 地獄のミサワ (http://jigokuno.com/)

16. 『僕の環境では動きません』
© 地獄のミサワ (http://jigokuno.com/)

17. 君と僕の開発環境は違うし
開発用サーバーも違うし
なんなら本番だって違うかもしれない

18. 止まらない不信感
終わらないデバッグ

19. あるプロジェクトで、本番環境へのデプロイメントが謎
の失敗を起こすことがあった。デプロイメント用のスク
リプトがハングしたのだ。原因を追跡した結果わかった
のは、運用サーバーのログインシェルが sh に設定されて
いるのに対してステージングサーバーでは bash になっ
ているということだった …（中略）… 本当に微妙な違
いを見つけるのは、これよりもずっと難しいことだ。総
合的な構成管理は必須である。
コラム『構成管理がまずいとリリース当日にデバッグ作
業をするはめになる』 (p351)
( ﾟ∀ﾟ)・∵.ｸﾞﾊｯ!!

20. よくあることだが、開発者自身の作業端末はおろか開発
チームの継続的インテグレーション環境でさえも職人芸
になってしまっており、長期間にわたって粗雑な管理が
続けられている。 これらの環境は、アプリケーションが
実際に動作する環境と関連があるとはとても言えない状
態だ。 非効率の根源にもなり得る。
11.4.1 サーバーのプロビジョニング (p349)
( ﾟ∀ﾟ)・∵.ｸﾞﾊｯ!!

21. 『構成管理』
『プロビジョニング』

22. 2. 気まぐれなテスト

23. 開発用サーバー (dev)個人の開発環境 (local)
SVN リポジトリ
チェックアウト
開発＆確認
コミット
アップデート
ビルド＆確認
勘と経験による打鍵テスト
既存機能を破壊する新機能
IE/Chrome/FF/iOS/Android … という多様な
機種をカバーする限界
trunk に混入し続ける動作しないコード

24. 開発用サーバー (dev)
SVN リポジトリ
チェックアウト
ビルド＆デプロイ (rsync)
本番用サーバー群 (live)
リリース
確認
リリースしてから気づいてバージョンを
戻して再デプロイ

25. 機能が増える度に低下する
サービス品質

26. 機能が増える度に低下する
コード品質
≒ 怖くてできないリファクタリング

27. 明確でない受け入れ条件
（機能・品質）

28. 『継続的に実行されるテスト』
『既存の振る舞いを保証する』
『不純物の混入を避けるプロセス』
『受け入れ条件』

29. 3. オレオレデプロイ

30. 開発用サーバー (dev)
SVN リポジトリ
チェックアウト
ビルド＆デプロイ (rsync)
本番用サーバー群 (live)
リリース
確認
対象サーバーに入って rsync -> ビルド -> AP 再
起動を行う独自スクリプト
似たような名前の様々なスクリプトが存在 (html_deploy.sh,
app_deploy.sh, template_deploy.sh …)

31. 作った人しかわからない
亜種スクリプトが量産される
(e.g., html_deloy_bk_20140616.sh)

32. エラー検知が甘かったり
rsync が同期しきれて
いなかったりする

33. 各サービス・各サブシステムの
デプロイがオレオレすぎてつらい

34. 『手順どこでしたっけ？』

35. そこで取り組んでみたこと

36. 個々人が、他者に影響されない
本番環境と同じ構成の開発環境を持つ

37. 個々人が、他者に影響されない
本番環境と同じ構成の開発環境を持つ

38. 開発用サーバー (dev)個人の開発環境 (local)
Web
AP DB
Web
AP
Web
AP
Web/AP の動作環境を
揃えるのが大変

39. 開発用サーバー (dev)個人のPC
Web
AP
DB
リモートログイン
何か障害や大きな負荷が
あると開発できなくなる
DB 共有するとスキーマの変
更やテストがしづらい

40. 開発用サーバー (dev)個人のPC
Web
AP
DB
Web
AP
DB
仮想環境
リポジトリ (git)

41. 環境設定を手作業でやっているせいで個々の環境が微妙
に異なってしまい、それが原因で問題が発生するという
ことについてはすでに議論してきた。仮想化技術を使え
ば、本章で紹介してきたテクニック (サーバーや環境のプ
ロビジョニングの自動化)の恩恵をさらに膨らませること
ができる。
11.7 仮想化 (p364)

42. http://www.vagrantup.com/

43. Vagrant
• VirtualBox や VMWare といっ
た仮想化技術を開発用途に使い
やすくするためのツール

44. vagrant init

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. vagrant up/halt

47. vagrant destroy

48. おかしくなったら
すぐ壊してやり直せる

49. 個々人が、他者に影響されない
本番環境と同じ構成の開発環境を持つ

50. 『構成管理』
『プロビジョニング』

51. http://www.getchef.com/chef/ | http://www.ansible.com/home

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. vagrant provision

54. • Ruby の DSL を利用
• opscode に登録された第三者の
recipe を再利用できる
• 結構タイトに構造化されている
Chef

55. • YAML でデータをいじるので
Python を意識しないで良い
• ほぼ全部入でクライアントレス
• 柔軟なディレクトリ構造
Ansible

56. 一元化された手順で
『自動的に』
環境構築する

57. ローカルで仮想マシンを立てて
何度もプロビジョニングして
最後まで通るようになったら
リポジトリに push する

58. 環境のコーディング

59. Code as Infrastructure

60. http://serverspec.org/

61. Serverspec
• プロビジョニングコードをテス
トするためのツール

63. 開発から本番まで一気通貫で
仮想マシンを活用した開発を
行うための試み

64. http://www.docker.com/

65. Docker
• コンテナ型仮想化による軽量な仮想
環境の提供
• 設計思想として１コンテナ１サービス
• 状態を保持しない ”使い捨て” イメー
ジ (Immutable Infrastructure)

69. 隔離
検査
破棄

70. 再生成

71. これは、我々の知る限りで最も強力なリリース管理テク
ニックである。本番環境としてまったく同じ環境を２組
用意するという考え方で、それぞれをブルーおよびグリー
ンと呼ぶ。
10.4.3 ブルーグリーン・デプロイメント (p319)

73. （キャッシュ目的とはいえ）
ミドルやライブラリを構造化して
管理している Chef や Ansible とは
対象的にコマンドの羅列に
なっている点が興味深い

74. 定式化されたデリバリーフローを
定義する

75. trunk/master ブランチを守る

76. A successful Git branching model
http://nvie.com/posts/a-successful-git-
branching-model/
x
GitLab
x
コードレビュー

77. http://nvie.com/posts/a-successful-git-branching-model/

78. https://www.gitlab.com/

79. テスト・デプロイ自動化

80. Jenkins
• 継続的インテグレーションを行
うためのツール
• リモートマシン上でのテストを
駆動したりメトリクスを可視化
したりいろいろできる

82. Capistrano
• デプロイ自動化のためのツール
• デプロイ対象のサーバーとその
ロール、処理内容などを記述
• 過去履歴を保持してロールバッ
クを行うこともできる

83. OS/MW => Chef/Ansible
アプリ => Capistrano

84. http://capistranorb.com/

85. 誰でも統一された手段でデプロイを
実行できる

86. 誰でも安易にデプロイを
実行して既存環境を変更できてしまう

87. まだまだお話したいこと
たくさんありますが

88. 続きは Web で

89. たとえば
『アジャイル開発手法 (スクラム、
XP) の導入事例』
http://recruit.gmo.jp/engineer/
jisedai/blog/20140509_agile/

90. まとめ
• Web 開発の現場で活用されている技術につい
てご紹介しました
• Web サービスは作って終わりではなく、リリー
スしてからの開発・運用プロセスをいかに効
率的・効果的に回すかが重要 (DevOps)
• 継続的デリバリーに興味を持った方は、ぜひ
アジャイル開発についても調べてみてください

91. ご清聴ありがとうございました