Q&A
(2)がダブってますが(3)じゃなくて良いのでしょうか？
Webの開発現場では以下のうちどのスタイルが
一般的でしょうか？
①本番やテスト時と同等の環境（OSやミドルウェア等）を
ローカルマシンとして用意し、そこで開発を行う。
②本番やテスト時と同等の仮想環境を
Vagrant, docker, VM等を使用して作り、
ローカルで編集したソースを仮想環境に送り
動作確認をする。
③開発用のサーバーが別途用意されており、
編集したソースを逐一そこにアップして
動作確認をする。
現場レベルでの意見を教えていただきたいです。
①だとこういうデメリットがある、とか
②だとこういうメリットがある～等。
よろしくお願いします。
ありがとうございます。③でした。
回答1件
0
ベストアンサー
一般的なのは(２)です。
- (1): ありよりの無し、支給パソコンが低スペックなら致し方なし
- (2): 仮想マシンはパフォーマンスをエディタやブラウザと食い合いになる
- (3): ありえない、Aさんが破壊的変更加えたら、Bさんが涙目で自分の修正箇所を見直したり犯人探しになる
(1)は依存ライブラリや言語のバージョンをまたぐ場合地獄になります。
例えば、前のプロジェクトはPHP5.6で作ってたけど、
新しいプロジェクトはなんか全てのコードが２倍速で動くPHP7にしましょう、サーバのコストも安く済みますよ！
みたいな感じで導入したとしましょう。
新しいプロジェクトの開発の為に、PHP5.6をアンインストールしてPHP7をインストールしました。
１ヶ月後、そこそこ新しいプロジェクトが起動に乗りいい感じです。
上司「takitsuboくん、PHP5.6の前プロジェクトで不具合が出たらしいからちょっと見てくれんかね？」
どうするんですか？
実際、支給マシン１個でもphpenv等を入れて頑張る事は可能です。
しかし、複数プロジェクトを面倒見るようになれば破綻します。
Aプロジェクトの依存モジュールを動かす為にインストールしておいたものが、
Bプロジェクトでも同じ依存モジュールが必要で、手順書に盛り込み忘れたにも関わらず、エラーが出ずにBプロジェクトが動作するケースが発生するからです。
そうなれば本番環境の検証中に初めてエラーが発生して右往左往することになります。
俗に言う「ぼくの環境では再現しませんでした」に繋がるわけです。
従って、本番環境と開発環境は常に必要最小限な依存モジュールのみが導入されたパソコンで有ることが望ましいのです。
それが出来るのは(2)が最善であり、(1)を利用する場合はプロジェクト数*メンバー人数分のマシンの準備が必要となります。
投稿2018/03/22 06:05
総合スコア21158
詳しく書いてくれてありがとうございます。
納得な理由がかなり多かったです。
1点確認したいことがあるんですが、
>>(3): ありえない、Aさんが破壊的変更加えたら、Bさんが涙目で自分の修正箇所を見直したり犯人探しになる
これについて何ですが、例えばAさん、Bさん、Cさんがいたとして、
サーバーにそれぞれにディレクトリA,B,Cを作っておき、
A,B,Cさんがそれぞれのディレクトリを使って開発や
実行の確認を取ったとしたらどうでしょうか？
それでそれぞれの実装が終わったら、
全員の変更や実装を反映させたソースを
新しいディレクトリDにでも入れて本番の実行テストを行う、
というものです。これなら実際の実行環境でのテストが
できると思ったのですが、この場合もやはり不都合はありますか？
> サーバーにそれぞれにディレクトリA,B,Cを作っておき
仰るとおり、それならば(1)よりはありですね。
でも、色々と問題が出てきそうですね。
・DBはどうするんですか？
・一人ジョインした時にやるべきことが多くなりすぎませんか？
・この対応でhttpd.confが結構歪められますが、本番環境に近いテスト環境がもう一つ必要では？
・実装中Aさんが無限ループを起こしたり、DBの負荷テスト始めたらどうしますか？
例えばConoHaのVPS(月額630円〜)とAnsibleみたいな環境構築ソフトを利用して、
開発者毎に独自の開発用サーバーマシンを用意した方が色んな面で楽だと思います。
ステージング環境や本番環境も殆ど同じノリでポコンと生やして使えば良いですからね。
それでもGUIのエディタやIDE使ってるメンバーには不便を強いる形になるかもしれません。
そういった意味で、開発者毎にVPSを用意したと仮定しても(2)より上は無いんじゃないかなぁと思います。
回答ありがとうございます。開発に関して
ほぼ素人のため色々聞いてみたいことがあります。
>>・DBはどうするんですか？
これつまり、DBをA,B,Cの3人で共有すると
処理が重くなりすぎるといった意味合いでしょうか？
>>・一人ジョインした時にやるべきことが多くなりすぎませんか？
例えばですが、ディレクトリを増やしたり
プライベートキーを作ったりといった作業が
増えてしまうといった意味合いでしょうか？
>>・この対応でhttpd.confが結構歪められますが、本番環境に近いテスト環境がもう一つ必要では？
すみません、ここが知識不足すぎてうまく
把握できませんでした。
>>・実装中Aさんが無限ループを起こしたり、DBの負荷テスト始めたらどうしますか？
Aさん一人のせいで全員が影響を受け、
他の人の開発効率がダウンしてしまう、
という意味合いでしょうか？
>・DBはどうするんですか？
まず、同じDBに接続するのはありえません。
Aさんの業務で既存のテーブル構成を変更すると、BさんとCさんの環境がエラーで動作しなくなります。
MySQLはデータベース名という項目で縦割りに出来るので、帯域を奪い合う問題さえ解消出来れば共存可能ですが、各々のデータベース名はどうやって管理しますか？
手作業での管理が増えるのでそれがコストになります。
> ・一人ジョインした時にやるべきことが多くなりすぎませんか？
フォルダ分けのルール、上の項目でも話しましたがDB名の管理、httpd.conf等の変更
新規メンバーが増える度に手順書を引っ張り出してきて、
既存のメンバーがサーバマシンをガシャガシャ触る事になります。
操作ミスると全員の開発環境が吹っ飛びますので、始末書？いやいや、失敗しない方法考えてくださいよ。
…という訳で短期的には大したことないコストですが、じわじわと効いてくるコストになることでしょう。
> ・この対応でhttpd.confが結構歪められますが、本番環境に近いテスト環境がもう一つ必要では？
基本的にWebサイトのHTMLに記載したファイルのパスは、ルート(/)から記載した方が便利です。
しかし、フォルダ分けするとサブディレクトリ起点になるのでWebサイトがまるごと崩壊することでしょう。
従って、バーチャルドメインを使ってサイトを構築することになります。
バーチャルドメインの設定は基本的にhttpd.confに書き足す事になるでしょう。
これで本番環境が大ダメージを食らう事はほぼありませんが、ステージング環境は別途用意しておいたほうが無難かと思います。
>・実装中Aさんが無限ループを起こしたり、DBの負荷テスト始めたらどうしますか？
そのとおりです。
上級者でもエンジニアでも再起なんかを使ってスマートに書こうとした結果
無限ループ起こすなんて事も考えられます。
いざと言う時はサーバー丸ごと壊して捨てるという選択肢があると良いです。
Vagrant: Ansible等と併用可能、プロビジョン機能でサーバーにインストールされているべきモジュールをあるべき姿で記載できる
Docker: Dockerfileやdocker-compose.ymlと併用して、サーバーにインストールされているべきモジュールをあるべき姿で記載できる
これにより、どちらも開発環境を1コマンド叩くだけで立ち上げられます。
新しくジョインしたメンバーにもこれらのファイルを見とけと伝えるだけで共有完了。
(2)の場合、必要に迫られて作成するプロビジョニングファイルがそのままプロジェクトの仕様書に化ける辺りが追い風ですね。
(3)で作った場合、手作業の手順書になりがちです。
結局まっさらなステージングマシンを使って手順書のテストが必要になります。
ありがとうございます。相当スッキリしました。
教えてもらったキーワードをもとに
色々調べてみます。
>>まず、同じDBに接続するのはありえません。
Aさんの業務で既存のテーブル構成を変更すると、BさんとCさんの環境がエラーで動作しなくなります。
何度もすみません、これってそれぞれの作業で
DBの構成を変更したりはするけれど、
最終的には一つのシステム及びDBになるので
そのときにDBの構成が合うように帳尻合わせする、
ということでしょうか？
>>まず、同じDBに接続するのはありえません。
これは前提が(3)です。
つまり、Apacheが入ってるインターネット上にぶら下がったマシン1個に開発者A・B・Cの3人がソースコードを入れて動作確認するという話です。
その開発者達が使うデータベースはなんですか？
そりゃあ、Webサーバが一緒ならデータベースも一緒のマシンか、
別にしたとしても1台のデータベース用のサーバマシンに3人が相乗りする形になりますよね？
例えばMySQLサーバは1マシン1個のアプリケーションで立ち上がりますが、
Excelで言うと、ファイル・シート・1シートの縦横で管理するに対応するように、
MySQLのデータベース・テーブル・カラムとレコードで世界が分割＆管理されています。
ExcelでAさん用のファイル・Bさん用のファイルという風に分ければ、Aさんがシートを全消しして作り直したとしても、BさんやCさんの作業が止まるケースは発生しません。
それに対応するのがMySQLのデータベース名という概念で、
これを分けて置くとAさんが既存のテーブル構成をガッツリ変えたとしても、BさんやCさんには一切影響が出ません。
…それを前提に、
Excelのファイルを人数分配布して使うならファイル名はどうやって管理するねん？問題が発生しますよね？
じゃあMySQLのデータベース名もどうやって管理するねん？問題が発生するでしょ？
…といった事を説明しています。
勘違いしていたかもしれません。「既存テーブルの構成を変える」
というのはテーブルのデータを消したり追加したりすることで、
カラムそのものを追加したりカラム名を変更したり、
カラムで扱う型（int等）を変えたり、という意味ではないということですか？
レコードの追加削除も相当問題で、Bさんが作業中にAさんが邪魔だからと削除して喧嘩になったりします
カラムの型が昨日までvarcharだったのがいつの間にかintに変更されていてもやばいです。
どっちも超問題なので、同じMySQLサーバに接続させる場合はデータベース名で区切るしかありません。
実際の開発経験に基づいた意見なので
相当ためになりました。ありがとうございます。
あなたの回答
tips
プレビュー
