本番環境に機能を追加するとき

実現したいこと

AWSで構築したwebアプリがあり、そこに開発環境で作った機能を追加したいです。
今までだと開発環境で新機能を追加し、そのソースコードをサーバーのファイルへコピペするという非常に原始的で危なっかしい方法でやってきました。
また、開発環境でのconfigファイルなどの機密性の高いファイルを環境変数を使うように仕向けるのも今までは手で直してきました。
以上のようなやり方で今まで開発環境と本番環境を完全に分離したものとして作業してきのですが、ずっとこのやり方で行くのはスマートな方法でないのでその対処を知りたいです。
そのあたりの開発環境での変更を本番環境へスムーズに反映させるにはどうすればいいですか。

解決？

私なりの解決策を考えたのですが、これであってますか？

gitで開発環境と本番環境のブランチをつくって云々。
dockerを使う。

68user

2021/01/26 14:41 編集

Web アプリは EC2 を使っていますか? 開発環境と本番環境はソースは完全に同一で、config ファイルのみが異なる状態ですか? git は現在も使っていますか?

Scrutiny0335

2021/01/26 14:43

EC2です。ソースは完全に同一でconfigのみ違います。 gitは使ってます。

行動規範の内容に同意します

回答1件

ベストアンサー

全体的にミスをなくし、品質を上げるためにはどうすればという質問ではないかと思いました。いろいろなアプローチがあると思いますが、こんな方法はどうでしょうという提案ということで。

config のみ、環境により内容が異なると解釈しました。まずは下記のようにファイルを分けて、git に登録してください。

　　config-pro.yaml: 本番用
config-dev.yaml: 開発用
※ファイルにかけない機密情報は、S3 や AWS Secrets Manager などに保存します。

環境変数 ENV に、本番なら pro、開発なら dev と設定されるようにしてください。そうすれば config-$ENV.yaml を参照することで適切な設定を読み込むことができます。
これで全環境の資材が git に入ったので、デプロイは自動化できるはずです。まずは zip や tar で固めて、ssh で本番に転送 & 展開 & Webサーバ再起動するようなデプロイスクリプトを作る、でいいのではないでしょうか。
環境は最低でも開発・ステージング(検証用)・本番の 3つをつくります。ステージングへのデプロイもデプロイスクリプトを使います。スクリプトにバグがあればステージングで発覚するはず。
git のブランチは feature/xxx を開発用、develop をステージング用、master を本番用とします。各メンバの開発中は feature で。プルリクエストでレビューして、develop にマージ。develop をステージングにデプロイし、全体検証。OK なら master マージして、本番デプロイ、という順です。
ブランチ運用は git-flow とか github-flow とかいろいろな流儀があるので調べてみてください (リリースブランチを作ったりします)。
仮に Web2台、DB1台(または RDS) といった構成であり、テーブル追加やカラム追加を伴うリリースがあるとすると、下記のような流れにします。

DB にテーブル追加・カラム追加する。
WebA をロードバランサから切り離し、master からデプロイ。
関係者のみが見られるような IP 制限をかけておいて、WebA で動作確認
OK なら WebA をロードバランサに復帰させ、WebB を切り離し。
WebB デプロイして動作確認し、OK なら WebB も復帰。

上記 Web を 1台ずつデプロイするやり方をブルーグリーンデプロイといいます。もし WebA の動作確認で問題が発生したら、WebB 片肺でしばらく動かし、急いで検証・修正します。DB の新テーブルや新カラムがある状態で、新旧アプリいずれも正しく動作する状況にしておいてください。
ユニットテストを書き、git push 時に自動でテストが動くようにします (CI)。夜間に毎日テストを動かすのもよいでしょう。
インフラ系の設定作業などは徐々に Terraform や CloudFormation などで自動化しましょう。新環境を簡単につくれるのが理想です。
Docker もよいと思います。ソースを含む環境が固定化できるので、開発用 Docker イメージを作成し、それをステージングでデプロイして検証し、さらに本番にデプロイします。OS・ミドルウェアレベルで環境が固定化できるので、操作ミスの余地が減ります。
AWS の CodeDeploy や CodePipeline などのサービスに乗っかるのもよいでしょう。
そのうち EC2 をやめて ECS や Fargate のような PaaS を使うようにすれば、自前で環境構築する範囲が減り、自然と作業ミスも減ると思います。