回答編集履歴
2
Add expression
test
CHANGED
@@ -1,3 +1,7 @@
|
|
1
|
+
## 元の回答
|
2
|
+
|
3
|
+
|
4
|
+
|
1
5
|
扱っているサービスがどこまでの安全性を求めるかと、
|
2
6
|
|
3
7
|
どれだけデプロイにコストをかけられるかによって方法が変わってきます
|
@@ -85,3 +89,65 @@
|
|
85
89
|
|
86
90
|
|
87
91
|
参考: [デプロイ / リリース 手法 まとめ - galife](https://garafu.blogspot.com/2018/11/release-strategy.html)
|
92
|
+
|
93
|
+
|
94
|
+
|
95
|
+
## 追記
|
96
|
+
|
97
|
+
|
98
|
+
|
99
|
+
> 「そのため、別ディレクトリーに clone した後、
|
100
|
+
|
101
|
+
> シンボリックリンクで参照先を切り替える、など」
|
102
|
+
|
103
|
+
> こちら「シンボリックリンクで参照先を切り替える」とはどういう事なのでしょうか...?
|
104
|
+
|
105
|
+
|
106
|
+
|
107
|
+
もう少し詳細に説明すると、次のような手順です
|
108
|
+
|
109
|
+
|
110
|
+
|
111
|
+
事前準備:
|
112
|
+
|
113
|
+
1
|
114
|
+
|
115
|
+
プロジェクトを、あるパスに clone します
|
116
|
+
|
117
|
+
|
118
|
+
|
119
|
+
2
|
120
|
+
|
121
|
+
Web サーバーのドキュメントルートに指定するディレクトリーを
|
122
|
+
|
123
|
+
シンボリックリンクで作成し、宛先を手順 1 で clone したパスに向けておきます
|
124
|
+
|
125
|
+
|
126
|
+
|
127
|
+
デプロイ時
|
128
|
+
|
129
|
+
1
|
130
|
+
|
131
|
+
更に別のパスにプロジェクトを clone します
|
132
|
+
|
133
|
+
|
134
|
+
|
135
|
+
2
|
136
|
+
|
137
|
+
手順 1 で clone したパスにシンボリックリンクを切り替えます
|
138
|
+
|
139
|
+
|
140
|
+
|
141
|
+
3
|
142
|
+
|
143
|
+
切り戻しの必要がなければ、以前に clone したパスに存在するプロジェクトを削除します
|
144
|
+
|
145
|
+
|
146
|
+
|
147
|
+
さらなる詳細は Ansistrano のワークフローの説明が参考になります:
|
148
|
+
|
149
|
+
|
150
|
+
|
151
|
+
- [Main workflow ansistrano/deploy: Ansible role to deploy scripting applications like PHP, Python, Ruby, etc. in a capistrano style](https://github.com/ansistrano/deploy#main-workflow)
|
152
|
+
|
153
|
+
- [デプロイフロー | Ansistranoでデプロイしてみる - Qiita](https://qiita.com/kawakawaryuryu/items/4843f518e84a6aae26b9#%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%83%95%E3%83%AD%E3%83%BC)
|
1
Fix expression
test
CHANGED
@@ -26,9 +26,13 @@
|
|
26
26
|
|
27
27
|
|
28
28
|
|
29
|
-
または、
|
29
|
+
または、`ローリングデプロイ`してくれるサービスを本番環境として使うか、
|
30
30
|
|
31
|
-
自分でロー
|
31
|
+
自分で`ローリングデプロイ`を行う、または自動化します
|
32
|
+
|
33
|
+
|
34
|
+
|
35
|
+
参考: [ローリングデプロイの仕組み | デプロイポリシーと設定 - AWS Elastic Beanstalk](https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html#environments-cfg-rollingdeployments-method)
|
32
36
|
|
33
37
|
|
34
38
|
|
@@ -60,7 +64,11 @@
|
|
60
64
|
|
61
65
|
|
62
66
|
|
67
|
+
## ローリングデプロイ
|
68
|
+
|
69
|
+
|
70
|
+
|
63
|
-
|
71
|
+
例えば、本番環境を複数台用意して
|
64
72
|
|
65
73
|
本番環境を`ロードバランサー`から 1 台ずつ切り離してデプロイすれば
|
66
74
|
|
@@ -70,6 +78,10 @@
|
|
70
78
|
|
71
79
|
使っているクラウドによっては、
|
72
80
|
|
73
|
-
このようなロー
|
81
|
+
このようなデプロイのワークフローついてもインフラ側で考慮してくれて
|
74
82
|
|
75
83
|
こちらで考える必要がない場合があります
|
84
|
+
|
85
|
+
|
86
|
+
|
87
|
+
参考: [デプロイ / リリース 手法 まとめ - galife](https://garafu.blogspot.com/2018/11/release-strategy.html)
|