タグ

ブックマーク / aligach.net (5)

  • vagrant + chef-solo provisioningが初めて動くまで

    あるいは Kanazawa.rb meetup #9 は「意識高いもくもく会」です。 はい、まぁ最近じゃ今さらの話ですね。 VagrantChef | OpscodeChef って興味あったんですよというか正確には Puppet に興味があって、でも大げさだなと思ってたんですよね。あと当時は Puppet は外部DSLだったので、「Rubyの文法でもなんでもない設定って、どうやってエディタでハイライトするの?」というのが最大の心理的ハードルでした。 で、時は流れて Software Design の Chef 特集を読んでやる気になったけど、家のリファレンスと格闘しているうちに仕組みの大掛かり感が増長されて挫折。その後ビッグウェーブに乗って達人出版会で買った『入門Chef Solo』を読み、そこでようやく 「サーバの状態を管理し収束させるためのフレームワーク」 という表現がグサッと刺さっ

  • CI始めました

    Welcome to Jenkins CI! | Jenkins CI なんとなく Java はメンドイという思い込みで避けていたんだけど、先週末にちょっと思い立って Jenkins のインストールを試してみた。Debian で試したところものすごく簡単だったので職場にも起こしてみることにした。 DebianにJenkinsをインストールDebian 6 にJenkinsをインストール - cactusman日誌 を参考に。 まずインストールはとても簡単。各種パッケージシステム用にパッケージが用意されてるから。 自分は Debian を使ったんだけど、上のエントリと java のパッケージが違う以外は するだけ。ここら辺とてもよく Debianize されてる印象。 Debian + Jenkins の考え方jenkins ユーザーでプロセスが動いてjenkins ユーザーのホームディレク

  • Capistrano は思ったよりシンプルで思ったよりすごい - あーありがち (2008-12-18)

    システム管理者のみなさん、こんにちは。今日は Rails アプリの deploy ツールとして有名な(らしい)Capistrano についてです。紹介? いえいえ。紹介はすでに有名な人たちによってなされています。ワタシがしたいのは検討。こいつはどこにどのように使えそうか。 Capistrano: Home システム管理の話なのになんで Puppet じゃないの?と思うかもしれません。それは、以前 Puppet の OSX 対応があまりよくなかったことと、また自分の環境が PPC Mac だったため、仮想マシンを使って他の OS を動かすのも現実的でなく、面倒になってしまっていたからです。 で、巡り巡って Capistrano って実は deploy 以外にも結構使えそうじゃない?と思えましたよというお話。想定しているバージョンは Capistrano 2.5.3 です。 なお、例によって嘘

  • Trac に PeerReviewPlugin を入れてみた

    先日、ようやくアジャイルプラクティス読了 で コミットされる前のコードをどうやってレビューするの?という初歩的な話。だってコミットされていないコードは基的に開発者のローカルの環境にあるわけでしょ? と書いていたけど、そう言えば reviewboard なんてものがあったなぁと思い出して動かすことを試みた。しかし monospace blog オンラインソースコードレビューツールのReviewBoardをインストールしてみた にしたがって Debian etch で作業してみたがあえなく失敗。(Python Image Library が入らなかった。Django も経験ないし。) 気分を替えて Trac に PeerReviewPlugin - Trac Hacks - Plugins Macros etc. - Trac をインストール。こっちは Trac の plugin 特有のクセ

  • Retrospectivaを試してみた

    実際に試したのは 4月29日。 Trac に対する不満Trac からの移行を考えている。なんでかっていうと Trac は複数のプロジェクトを扱うことができない1Trac : 1ユーザーDB になるのでプロジェクトが増えるとユーザー管理が面倒くさいTrac は基的に認証用のユーザー DB と権限管理のユーザー DB が分離している。デフォルトでは認証は HTTP サーバの BASIC 認証を利用していて、権限を Trac の DB に保存する形。この形のままプロジェクトごとに Trac が増えていくとかなり管理しにくいこと請け合い。 もしかするとリポジトリは1つにすべしという考え方に基づいているのかもしれない。でも自分の経験では適切に分割してある方がやはり扱いやすい。これは皮肉なことに(?)特に Trac を使い始めてから強く感じている。例えば複数のプロジェクトの branch が増えてく

  • 1