失敗する前提でデプロイする - hitode909の日記
うちのチームでは，デプロイするたびに自動的にgitのtagを切るようにしてる．たとえば，いまデプロイしたら，deploy/2014-02-01-14-48とか． たまに，リリースした直後になんかミスってたことに気付いて，慌ててロールバックすることがある． tagを切ってるので，ひとつ前に戻せばいいのだけど，えっと，どれだっけとかいって探すので慌てるし，普段はタグ指定してデプロイしてないので，どうやって戻すか忘れる． デプロイ終わったときに，今回のデプロイを戻すには，これをしましょう，とか表示するようにした． デプロイ終わったらこんなのが出る．前回のデプロイが昨日だったら昨日くらいのタグが出る． ヒント：戻すときは以下のコマンドを実行しましょう cap -S revision=deploy/2014-01-31-15-17 deploy 実装方法としては，こんな感じに，デプロイ前に最新のタグ
複数プロジェクトを抱えるチームでのデプロイ自動化
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
HudsonでASP.NETアプリをデプロイする設定、.NET Framework 4版(・∀・) - 山奥通信 増刊号
Hudsonを使って、CIでビルドの実行やテストを流す他にも、ビルドしたWebアプリをIISにデプロイして、最新版の動作が確認できるような設定をしています(・∀・) っで、先週、開発プロジェクトをVisual Studio 2010/.NET Framework 4対応にして、Hudsonのデプロイ設定もそれに併せて変更したのでその時のメモです。 なお、デプロイ先の環境はWindows Server 2008 R2のIIS 7.5になります。 また、デプロイにはmsdeployを使用しますが、Visual Studio 2010がインストールされていない環境については、別途msdeployをインストールしておく必要があります。 っで、その辺のインストールやHudsonの環境構築の話は省略して、Hudsonの必要な設定の所だけを記述します(´д｀;) あと、以下の内容はHudsonとIISが
第5回 配備を自動化する
自動ビルドでパッケージをデプロイ／作成する TFSの自動ビルドで生成されたプロジェクトを自動でデプロイする方法は以下の2つのいずれかになる。 TFSの自動ビルドでWeb Deploy用パッケージ・ファイル（zipファイル）を作成する。作成したパッケージ・ファイルは運用ツールやタスク・スケジューラなどの外部ツールを使用してデプロイする TFSの自動ビルドで直接デプロイを行う どちらの方法を使用してもよいが、デプロイをするサーバの台数が多くなったりプロジェクトのサイズが大きくなったりしてデプロイに時間がかかるようになった場合や、検証環境で確認してから本番環境にデプロイするといった場合は前者の方法でパッケージを作ってから別の仕組みを利用してデプロイする方がよいだろう。 TFSのビルド・サービスを使用する場合、使用するアカウントによっては異なるサーバに出力することはできないので注意してほしい。本連
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側（前編）。JAWS DAYS 2014
