技術を活かし、新しい価値を創造する DeNAのエンジニアは、想像を超えるDelightを届けるために何ができるかを考え、技術力と発想力で新しい価値を生み出しています。 多様な専門性を持ったエンジニアが切磋琢磨し、互いに刺激し合える環境や制度がさらなる成長へとつなげます。
追記 Capistrano 3.1からは何もしなくてもprevious_revisionとcurrent_revisionが set されるようです。 capistrano/capistrano#32920c1 Capistrano2の頃はデプロイするとそのときのリビジョンがREVISIONという名前のファイルに書きだされていた（ような気がする）のですが、Capistrano3ではデフォルトでそういうことをやらなくなったみたいです。 下記のタスクを追加するとファイルに保存されるようになります。 set :revision_file, 'REVISION' namespace :deploy do task :save_current_revision do on role(:app) do within repo_path do set :revision, capture(:git, :
GitHub / Bitbucket のプライベートリポジトリも無料で CI し放題の wercker というサービスがあります。(2013/11/30 現在) サイトもきれいで素敵です。ビルド成功後、Capistrano でデプロイが自動実行される方法を書いておきます。 まず、アプリの設定で SSH 公開鍵を作成します。 生成された公開鍵は、デプロイ先サーバの ~/.ssh/authorized_keys や Bitbucket のデプロイ鍵などに追加しておきます。 次に、アプリの設定から Deploy targets の設定をします。Custom deploy を選択して、 master ブランチのビルドに成功したら、自動デプロイするようにします。 入力したら、Deploy pipeline の Add new variable をクリック。 SSH Key pair を選択し、先ほど
なんか久しぶりに話した気がします。 半ば強引でしたが、話す機会を下さったFukuoka.php運営陣のみなさんありがとうございます。 結構いろいろすっ飛ばして解説したので、多少間違いもあるかもしれませんが、導入として「いいかも」と思ってくれれば役目は果たせたと思っています。 質問もあったので個人的には満足です。 あと、公開を約束していた、CakePHP系プロジェクトのdeploy.rbのサンプル、というかリアルに使っているのを張り付けておきます。 ちなみに、勉強会中のDEMOも実サービスで行いました(まだ、正式公開前なので)。 基本的には、@ryuzeeさんのエントリーを参考に作っていて、概要もすべてこちらを参考にするとよいと思います。 というか、JenkinsもMigrationsもCapistranoも全て@ryuzeeさんの記事ドリブンです。この場を借りて御礼を述べたいと思います。
Kyoto.rbがあったので、Rubyのことはよくわからないながら、capistranoの話をして来ました。設定の共通化についてと、思いついたTips集を発表して来ました。サンプルはhttps://github.com/shibayu36/capistrano-deploy-sampleにおいてあります。 130207 kyotorb from Yuki Shibazaki capistranoとは デプロイ用ツール コマンド一つでアプリケーションのデプロイが出来たりする 特にRailsに特化してる capistrano設定を社内などで共通化したい 共通化しないとprojectごとでdeploy方法が違って死ねる とはいえ一つのファイルで管理していると破綻する 最近の共通化の方針 やりたいことごとにファイルを作って共通化する default設定, deploy用, cron, perlbr
「ニフティクラウドユーザーブログ」は、移転しました。 自動でページを移動しない場合は、下記のリンクをクリックし、 新しい「ニフティクラウドユーザーブログ」をご覧ください。 今後とも「ニフティクラウドユーザーブログ」をよろしくお願いいたします。 ＞ ニフティクラウドユーザーブログ
Capistrano deployment tips collection document summarized in 3 sentences: The document shares tips for using the Capistrano automation tool, including recommendations for colorizing Capistrano commands with the capistrano_colors plugin. It also describes using the capistrano-ext plugin to better organize different deployment configurations and set environment-specific options. The document provide
システム管理者のみなさん、こんにちは。今日は Rails アプリの deploy ツールとして有名な（らしい）Capistrano についてです。紹介？ いえいえ。紹介はすでに有名な人たちによってなされています。ワタシがしたいのは検討。こいつはどこにどのように使えそうか。 Capistrano: Home システム管理の話なのになんで Puppet じゃないの？と思うかもしれません。それは、以前 Puppet の OSX 対応があまりよくなかったことと、また自分の環境が PPC Mac だったため、仮想マシンを使って他の OS を動かすのも現実的でなく、面倒になってしまっていたからです。 で、巡り巡って Capistrano って実は deploy 以外にも結構使えそうじゃない？と思えましたよというお話。想定しているバージョンは Capistrano 2.5.3 です。 なお、例によって嘘
Capistrano によるファイル転送手段で標準で用意されてる方法は upload や put でファイルをアップロードする（scp / sftp 経由） Git や Subversion などの SCM からファイルをチェックアウトする であり，rsync はない（と思う）。 なので，Capistrano で rsync しようと思った（あ，でも rails とか用の標準 deploy レシピで使う方法とかじゃないです; 単に task に rsync を書くだけ）。 Capfile は実際 ruby のコードなのでなんとでもやりようはある。 task :rsync_task do source_path = "/source/path/" target_path = "target_host:/target/path/" `rsync -avz #{source_path} #{ta
こんにちは、亀本です。 １週間ぶりです。というのも、今までご無沙汰過ぎて、ブログ当番に２週連続であたってしまいました。 やっぱり普段からコツコツやっとかないとだめですね。反省反省。 さて、今回はデプロイのお話です。 アプリケーションのデプロイといえばリリースの締めの一番ミスできないところです。 みなさん、これをどうやって作業していますか？ 最近はバージョン管理システムが導入されるのが当たり前になっている場合が多く、リポジトリからのチェックアウトで済ませてしまうとか、rsyncするだけという方も多いんじゃないでしょうか。 もちろん、Webサーバ２～３台ぐらいだったらそれで事足りますし、適切なポリシーを持って臨めば、セキュリティ的に問題が発生するような事態にも陥らないでしょう。 しかし、バージョン管理システム自体やrsyncを使ったデプロイは手軽であるというメリットの裏で、以下のような不安材料
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
