composer install をどこで実行するか
最近の PHPer が集まれば、一度は話題に上がるのが、この composer install をどこで実行するのか問題。 これまで聞いた話をまとめると、大きく分けて、以下の２パターンになります。どちらの方法を取っているか教えて下さい 😀 0. 前提 前提ですが、以下のような方法で、Composer 関連のファイルは管理しているとします。おそらく多くはこのような形になっていると思います。 PHP コードは、Git などの VCS で管理する。 composer.json, composer.lock は、VCS で管理する。 composer.phar, vendor/ は、VCS で管理しない。 また、今回対象としているのはアプリケーションで、Packagist に登録して、配布するようなフレームワークやライブラリは対象外です。 1. 本番サーバで実行 本番PHPサーバ上で compo
PhpStormでVagrant仮想マシンのPHPUnitを実行する
Vagrant を使って PHP 開発する場合、synced_folder でフォルダを共有して、ソースコードの編集はホスト PC 、実行は仮想サーバで行っている方が多いと思います。 このスタイルで開発する場合、PHPUnit によるテストの実行は、ターミナルで仮想サーバにログインしてコマンドラインから行うことになります。開発中は頻繁にテストを実行するので、できればエディタからテストを実行したいですよね。 PhpStorm によい機能がないか調べたところ、PHPUnit on Server というズバリの機能がありました。この機能を使うと、ホスト PC の PhpStorm からリモートサーバの PHPUnit を実行できます。 Symfony2 のテストをリモート実行する例を紹介していますが、他のフレームワークにも応用可能かと思います。 2014年9月26日追記 PhpStorm8 から
「Blue-Green Deployment」とは何か、マーチン・ファウラー氏の解説
クラウドを活用した本番システムのデプロイ手法の1つに「Blue-Green Deployment」がある。Blue-Green Deploymentの目的とそのメリットを、マーチン・ファウラー氏の解説から紹介する。 1つ前の記事で紹介した、チャド・ファウラー氏によるImmutable Infrastructureの記事「Immutable Infrastructure（イミュータブルインフラストラクチャ）と捨ててしまえるコンポーネント」では、デプロイをより安心して行うために、サーバの内容を変更する際には既存のサーバに手を加えるのではなく、新規に作り直して切り替える、という方法を提案しています。これがサーバの不変性、すなわちImmutable Infrastructureにつながるわけです。 これから紹介するマーチン・ファウラー氏の記事「BlueGreenDeployment」は、Immut
Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ
開発合宿でDevOps界隈やモニタリング界隈で流行りのツールを組み合わせてBlue Green Deploymentできる何かを作りました。 同じチームで開発したid:shiba_yu36 先生やid:wtatsuru 先生が既にブログを書いてますが、自分の視点で書いてみます。（13/12/24追記: より詳細な内容が新規に書かれたのでリンク先を入れ替えました） Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog; Docker コンテナにアプリケーションを立てて Graphite でいい感じに可視化するまで - wtatsuru's blog 僕は主に、各ツールから得られる情報をまとめて管理し、デプロイを実行するデプロイ管理ツールを作成していましたので、それについて書きます。 普段は運用の修行をして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
