![運用を楽にするためのアプリケーションコードを書くということ : sonots:blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/da78a05937633f7a2b4b2219826151c370cd607b/height=288;version=1;width=512/https%3A%2F%2Fparts.blog.livedoor.jp%2Fimg%2Fusr%2Fcmn%2Fogp_image%2Flivedoor.png)
クラウドを活用した本番システムのデプロイ手法の1つに「Blue-Green Deployment」がある。Blue-Green Deploymentの目的とそのメリットを、マーチン・ファウラー氏の解説から紹介する。 1つ前の記事で紹介した、チャド・ファウラー氏によるImmutable Infrastructureの記事「Immutable Infrastructure(イミュータブルインフラストラクチャ)と捨ててしまえるコンポーネント」では、デプロイをより安心して行うために、サーバの内容を変更する際には既存のサーバに手を加えるのではなく、新規に作り直して切り替える、という方法を提案しています。これがサーバの不変性、すなわちImmutable Infrastructureにつながるわけです。 これから紹介するマーチン・ファウラー氏の記事「BlueGreenDeployment」は、Immut
こんにちは、chatiiです。ちょっとまじめに記事書きます。 FuelPHPでけっこう(chatiiとしては)規模の大きい案件がきたので、開発環境をキチっと決めたいと思いました。その中で、今まで手作業でやりつつ、「これ自動化できるだろ」っていうところがあり、今回うまくいったのでご紹介。ちなみに、今回はFuelPHPは関係ないです。 開発会社さんから見たら普通のことなんだろうなぁ。野良プログラマーPHPerだからせけんしらず。 環境・条件 ソースコード管理はGitHub ひとりなのに!ひとりなのに! LAMP構成 開発マシンにはXAMPP/MAMPを入れる。Linuxの場合はyum/aptで取得。 サーバーは 本番サーバー(www.hoge.com) テストサーバー (hoge.dev.example.com) テストサーバーは他人がアクセスできないようにね 他のプロジェクトもテストします
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化著者/訳者:David Farley、Jez Humble、和智 右桂、高木 正弘出版社:KADOKAWA/アスキー・メディアワークス発売日:2012-03-14大型本:544ページISBN-13:9784048707879ASIN:4048707876 レビューに参加させていただいた縁でアスキー・メディアワークス社様より献本いただきました。和智さん、高木さんの黄金コンビによる翻訳です。 デプロイ自動化に関する話を網羅的に扱った本はこれがはじめてでしょう。 上級技術者向けと書かれているように内容は結構ハイレベルで、構成管理、CI、テスト戦略についての前提知識が求められるように思いますが、アジャイルなプロジェクトの中で日々改善を繰り返している人たちにとっては理解しやすいのではないかと思います。 デプ
Eclipse, Jenkins, Apache Ivyを使ったプロジェクトにおける開発からデプロイまでの流れを図に描いてみました。 図では書き表せないことがありますね。テスト実行時のクラスパスは実行時ライブラリを含むとか、図で描くとカオスになります。GUIツールでビルド設計するのは意外と難しいのかもしれません。 ビルド設計する上で考えたことを書き出しておきます。何かアドバイスがあったら教えていただけると嬉しいです。 開発環境 WindowsでEclipseを使う。 Eclipseのプロジェクト構成で適切なビルドパスを設定する。 依存ライブラリはApache IvyDEプラグインで管理する。 依存ライブラリはMavenリポジトリから取得する。リポジトリ候補にはビルドサーバ上のキャッシュを含める*1。 他プロジェクトへの参照はEclipseのProject Referenceを設定する。 ク
みなさんこんにちは。@ryuzeeです。 Jez Humble氏のContinuous Delivery vs Continuous Deploymentが分かりやすいので抜粋・意訳にてご紹介します。 (翻訳部分はCC-BY−SAとします) ティモシー・フィッツの継続的デプロイに関するブログは、デイブと私が継続的デリバリーについての本を出版する1年以上も前に、すでに書かれていた。そんな中でなぜ私たちは異なる名前を選んだのだろうか。実際に違いはあるのだろうか?それとも単に我々が不親切なだけなのだろうか? 我々はいくつかの理由で本の名前を「継続的デリバリー」とすることにした。まず第一に、デプロイがリリースを意味しないというちょっと学者ぶった事実。我々が本の中で言っているように、継続的に顧客受け入れ環境にデプロイすることはできるだろう。それ自体はたいしたことはない。継続的デプロイを特別なものにす
12月20日に第1回ワンクリックデプロイ勉強会で、デプロイの自動化について好き勝手に喋ったりデモしたりする予定なのですが、当日話す内容の概略について以下に載せておきます。 以下にあげることをやっておけばデプロイ自動化、ワンクリックデプロイはそんなに遠くないところにあると思います。 ソースコードのバージョン管理いわずもがな。全ての起点はここにあるコードの共同所有の原則への理解このソースコードは本番環境または開発環境などで同じように動作しなければならないテストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣設定ファイルのバージョン管理環境によって異なる設定値(接続先データベース情報など)が書かれた設定ファイルもバージョン管理する開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする本番環境に配置する際に、アプリケーションの各所を書き換えなけれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く