エンジニアが一番最初にやる仕事
仮想環境って言葉を知っていますか？
世の中のサービス（アプリケーション）を保存（ホスティング）しているサーバではほぼ100%LinuxというOSが使われているんですが、このOSをWindowsOSやMacOSでも作ることができる技術が仮想化技術です。
VMWareとか、Virtual Boxとか、Bootcampとかありましたね。
これらの仮想化ツールでローカルPC（のOS上）にさらにOSを仮想的に作るというイメージです。
バーチャルマシンとも言われます。
仮想的にっていうのは難しい概念ですが、物理的の逆の意味として捉えてもらうといいと思います。
つまり一つのPC上に一般的な運用では2つは入れる必要のないOSを入れることです。
この新たに追加したOSが仮想環境と呼ばれます。
一般的な運用というのは、OSに依存する作業をやることがないことを想定していて、オフィスワークの大半の仕事のことを指してます。
以前MacOSはUNIXベースのOSだということを話したんですが（前のエントリーみてください）、Linuxのコマンドとほぼ同じコマンドを使えるのはLinuxもUNIXベースのOSだった（今はお互い独自路線を走っているようです）からです。
なのでMacの場合は直接自分のローカル環境に開発環境を作ることもできます。
Windowsはこれが使えないのでMS系（VB、C++など）の開発以外では仮想化ツールを使って仮想的に開発環境を作成することが大半です。
（MS系の場合も実際は仮想環境ですが、、、MS専用の環境です）
よく頭文字を取ってLAMP環境とも言いますが、Linux + Apache + MySQL + PHP (or) Python (or) Perl のような構成でサービスを作るときのことですね。
サーバOS、Webサーバ（APサーバも含められることが多い）、データベース、開発言語の順ですね。
WebサーバはAPサーバ（アプリケーションサーバ）も含められることが多いです。
これら全てオープンソース（実質無料みたいなやつ）でできているので、環境を作りやすいという意味で実質、デファクトスタンダード的な構成です。
PのところはRubyなり、Javaなりいろいろありますが、、、。
こうやってローカルPC上に実際のサーバ環境を作成して開発や動作確認を行なっていきます。
物理的には同じPCとは言え、ローカルのOSとこの環境は論理的には全く別のサーバ（専門用語的にはノード）です。
なのでサーバ同士がお互いに通信するためにsshで接続しないといけなかったり、接続ポートを被らせないようにしたりとけっこう手間です。
でもその設定をすれば、仮想環境でのアプリケーションを実際にローカルPCのブラウザ上から確認できるようになるということですね。
実はその辺もうまくやってくれるのがVMWareとかの仮想化ツールなんですが、システムが複雑になればなるほどミドルウェアなどの設定値をカスタマイズしないといけません。
それらの難しい設定を事前に設定ファイルとして用意してあげてそれらをサーバに置いてコマンドを実行するだけで全ての準備をしてくれるのがプロビジョニングツール（のなかでのBootstrappingという分野）と言います。
最近だとコンテナ技術とも言われている、Dockerが一番有名ですね。
http://tapira.hatenablog.com/entry/2015/05/26/124710
デプロイを行う
前述の技術でまずは仮想環境にRuby、Pythonなどのプログラムが動作する環境が揃いましたね。
ここでようやく開発に取り掛かるわけですが、開発に関しては今回はほかのエントリーに譲ります。
なんて言ってもここが一番のミソですから！
プログラミングは専門書などを買って体系的に学ぶことをおすすめします。
あとできなくても悲観せず諦めないこと！
さてでは、開発してソースコードを新規作成したり、更新していくわけですが、これにはgitという技術が必要不可欠です。
gitというのはソースコードを管理してくれるツールで、これによって複数のメンバーがソースコードを共有しながら別々に開発することができます。
今ではなくてはならない開発ツールになっていて、つい先日gitで管理したソースコードをホスティングするサービスであるGitHubが買収されたのは記憶に新しいです（エンジニアには）。
ちなみに私も最初理解できなかったのですが、GitHub上にあるソースコードはあくまでソースコードを管理しているだけで、これは生のソースコードしか入っておらずすぐ使える状態になっていません。
つまりGitHubにアクセスしても開発したサービスが利用できるわけではないです。
そこで本番サーバを用意するわけですが、その前に生のソースコードをビルドする作業があります。
ビルドというのはソースコードをすぐ使える状態にしてあげることを指していて、それらを本番サーバにデプロイ（実際にサービス化すること）してあげることでそのサーバにアクセスするとサービスを利用できるようになります。
実はこの作業は今では自動化されていて、GitHubにソースコードをpushしたらそれをビルドしてstaging環境にデプロイするなどの設定ができます。
最近だとCapistranoというデプロイ自動化ツールが人気です。
Javascriptの場合だと専用でタスクランナーという言葉があるみたいです。（たぶん構文解析したり圧縮したりしてるんじゃないかと予想。この辺はよくわからないw）
ここでproduction環境（=本番環境）にデプロイしないのは危険だからです。
本番は手動で、みんなの前で指差し確認をしながらデプロイします。
なぜなら絶対にコケちゃいけない環境だからです。
ちなみに「GitHubにpushされたらデプロイが走る」など、何かイベントが発火すると実行される、契機となるものを「トリガー」と言います。
先の話で言うと、Jenkinsというビルドツールの仲間（CIツールとかっていう）がこの契機を拾って、勝手に単体テストしてビルドして、capコマンド（デプロイするためのコマンド）を叩いてくれる、みたいなことをやってくれます。
データベースのデータの扱い
ではデータベースに入っている実際のデータはどうでしょうか？
本来は本番環境はもともと動いているので本番環境に運用データを入れる必要はないです。
ただ、staging環境にproduction環境の本番データを入れるなどは実際の運用としてはあります。
このときは僕が参画したプロジェクトでは本番データのダンプ（=バックアップ）を取得して、ステージングにリストア（=バックアップデータを流し込む）していました。
これで本番環境と同様の環境がstagingで用意できましたね。
その他
ほかにも性能測定するためのツールや、テストを自動化させるツールなど覚えることはたくさんありますが、大まかにはこんな感じでエンジニアは日々開発をしてます。
