【Web】 Retrospectiva 構築方法

自宅での諸々の作業(プログラミング関係だけでなく)を管理するのにwikiやらtracやら果てはRedmineまで手を出して色々やっていたのだけど、あんまりうまくいってなかった。

  • tracは複数プロジェクト対応できないし動作が重い
  • wikiは使うのが結構面倒
  • Redmineは立ち上げが大変な割に個人使用には向かない

というのが一応それぞれの理由。根気が無いという話もあるが。coldsweats01

そこで、今回リポジトリをGitに移行したのに合わせてフロントエンドも変更してみました。
色々調べてみた所、Redmineと同じくRoRで動作する retrospectiva というものを発見。この方、どうやらgithubで開発がされているらしく、こちらとしても好都合なんで試しに導入してみる事にしました。

Screenshot_from_20120501_121938 結論から言うと、

  • 立ち上げが容易
  • 設定などが少なくて分かりやすい
  • 複数プロジェクト管理が可能
  • 一応wikiやblog風のエクステンションがある
  • 動作的には結構軽め

という事で、個人的には受け入れられるレベルでした。
後は実際に使ってみて検討します。

以下は構築方法のメモ。

[サーバ環境]
OS: ubuntu 10.04 LTS
ruby: 1.8.7
DB: sqlite3
Webサーバ: apache2

[作業の流れ]

$ sudo apt-get install ruby1.8-dev

ruby1.8-devが無いとretrospectivaのインストールスクリプトでエラーになります。

$ sudo apt-get install curl
$ sudo -s
$ cd /

今回 /retrospectiva ディレクトリにインストールするつもりなので、rootユーザになった上でルートディレクトリで作業しました。

$ curl https://raw.github.com/dim/retrospectiva/master/script/remote/retrospectiva_installer.rb | ruby

直接github.com上のインストールスクリプトを動かしてしまうのが簡単でお薦めです。
以下のようなログが表示されるはず。

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  8914  100  8914    0     0   7625      0  0:00:01  0:00:01 --:--:-- 38925

  Retrospectiva Remote Installer
  ==============================

  Unpacking vendor libraries to '/retrospectiva/vendor'
  Building GEMs
  Writing database configuration
  Creating database

  Next Steps:

  * Add the following line to your crontab (crontab -e):
     * *  * * *  RAILS_ENV=production /usr/bin/ruby /retrospectiva/script/retro_tasks

  * Run Retrospectiva:
     cd retrospectiva; /usr/bin/ruby script/server -e production

  * Deploy as Apache2/NingX Virtual Host:
     Please visit http://www.modrails.com/ for more information

  * Add Subversion support:
     sudo apt-get install subversion libsvn-ruby

  * Add GIT support:
     sudo apt-get git-core

あとはこのコメント通りに、crontab -e でクーロンに追加しておいてからwebrickで一旦動作確認します。

$ cd retrospectiva
$ ruby script/server --binding=サーバIP -pポート番号 -e production

これでしばらくするとwebrickが起動し、クライアント環境からアクセスできるようになります。

http://サーバIP:ポート番号/

にアクセスして、動作を確かめてください。
初期アカウントは

Username:  admin
Password:   password

となっています。
ちょっと触ってみて、動作に問題がなければ後はapache2の設定を。

$ vi /etc/apache2/conf.d/retrospectiva

以下の設定を記入します。まぁ、ここはVirtualHostの設定なので、ご自由にやっちゃってください。キモはDocumentRootが /retrospectiva/public であるという事位ですね。

<VirtualHost *:80>
    ServerName retrospectiva
    DocumentRoot /retrospectiva/public
    ErrorLog /var/log/apache2/retrospectiva-error.log
    CustomLog /var/log/apache2/retrospectiva-access.log combined

    <Directory /retrospectiva/public>
        Options ExecCGI FollowSymLinks
        AllowOverride all
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

次にディレクトリのパーミッションを変更します。

$ chown -R www-data:www-data /retrospectiva

本当は必要なディレクトリとファイルだけで良いのだけど、面倒なんで全部変えちゃいました。coldsweats01
それからエクステンションをインストールしておきます。

$ cd /retrospectiva
$ RAILS_ENV=production script/rxm install agile_pm
$ RAILS_ENV=production script/rxm install retro_wiki
$ RAILS_ENV=production script/rxm install retro_blog

これで全てのエクステンションがインストールされます。
大体以上っすかね?

【Git】 Gitリポジトリ構築(その2)

手始めに環境の確認を。

サーバ環境
OS:  ubuntu 10.04LTS Server
Git:  git vertion 1.7.0.4

クライアント環境
OS:  ubuntu 12.04LTS Desktop
Git:  git version 1.7.9.5

その他、Mac(OS X Lion)とWindowsからも使用予定。


  1. クライアント環境の準備
  2. ローカルリポジトリの作成
  3. ローカルリポジトリへのファイル登録・コミット
  4. ローカルリポジトリのファイル更新
  5. ローカルリポジトリのその他の操作
  6. サーバ環境の準備
  7. リモートリポジトリ(公開リポジトリ)の作成
  8. リモートリポジトリのアクセス方法
  9. ローカルリポジトリからリモートリポジトリへの変更公開
  10. リモートリポジトリからローカルリポジトリへの変更取り込み
  11. gitwebの立ち上げ

大体こんな順番ですかね。
その他の複雑な操作は追々...というか書籍とかWebとかマニュアルとかご参照ください。coldsweats01


1. クライアント環境の準備

$ sudo apt-get install git-core
$ git config --global user.name "名前"
$ git config --global user.email "メールアドレス"
$ git config --global color.ui "auto"

クライアント環境はこれ位で十分。
最後の一行はターミナルのカラー表示に関する設定です。
Gitのコマンドオプションはフルの場合が多いので(commitとかcheckoutとか)svnみたいに短縮形が使いたければ、それも設定してください。任意の名前が使えます。

$ git config --global alias.ci "commit"
$ git config --global alias.co "checkout"
$ git config --global alias.st "status"

これらの設定は~/.gitconfigに格納されるので、直接テキストエディタで変更してもOK。


2. ローカルリポジトリの作成

$ mkdir ~/git
$ cd ~/git
$ mkdir project
$ cd project
$ git init

Gitを使って複数のプロジェクトを管理するつもりなので、ワーク用のディレクトリを作成しその中に個別のプロジェクトディレクトリ(ローカルリポジトリ)を作ることにしました。最後の git init コマンドで、projectディレクトリがローカルリポジトリになります。


3. ローカルリポジトリへのファイル登録・コミット

$ touch README
$ git add README
$ git commit -m "コミットログ"

手始めに空っぽのREADMEファイルを作って、コミットしてみました。
Subversionと流れは同じです。addしてからcommitって感じですね。コミット時に-mオプションを省略すると適当なエディタを起動してコミットログを記入できるようになります。


4. ローカルリポジトリのファイル更新

$ vi README
(何か適当にテキストを記入してvi終了)
$ git add README
$ git commit -m "コミットログ"

ここでsvnとの違いが出てきます。
READMEは先程既にaddコマンドで登録したのに、なんでまた?と思いました。
実はGitでは作業領域とローカルリポジトリの間にステージという段階が入っているんですね。変更したファイルは一旦このステージにaddしてからリポジトリにcommitという手順になっているようです。これを一度にやるオプションもあります。

$ git commit -a -m "コミットログ"

このステージの使い方ですが、複数の理由から一気に沢山のファイルを変更した後、それぞれの理由に応じてコミットしたい時などに使えそうです。Subversionの場合はcommit対象のファイルを選択してcomitする必要がありましたが、ステージを使えば整理とコミットを明確に分けることができます。


5. ローカルリポジトリのその他の操作
$ git status (作業領域の状態表示)
$ git diff (ローカルリポジトリと作業領域の差分表示)
$ git log (ローカルリポジトリのコミットログ確認)
$ git log --graph --date-order -C -M (ローカルリポジトリのコミットログのツリー表示)
$ git branch "ブランチ名" (ブランチ切り替え、新規作成)
$ git branch (ローカルリポジトリのブランチ一覧表示)
$ git tag "タグ名" (ローカルリポジトリのタグ設定)
$ git tag (ローカルリポジトリのタグ一覧表示)
$ git checkout (ブランチ・タグの切り替え。svn switchと同等。)
$ git clone "リポジトリ名" (リポジトリのクローン化)
$ git push (ローカルリポジトリの変更をリモートリポジトリにアップロード)
$ git pull (リモートリポジトリの変更をローカルリポジトリにマージ)
$ git help (とりあえず困ったらこれ)

Gitではブランチの使い方が随分ダイナミックになっているようです。頻繁なマージを前提とした分散型の開発が主体になりますね。


6. サーバ環境の準備
ここからサーバ側での作業になります。

$ sudo apt-get install git-core
$ sudo apt-get install git-daemon-run
$ sudo apt-get install gitweb

ついでなんでgitwebパッケージもインストールしておきました。apache2とかの設定は完了している事が前提なので、その辺りご了承ください。あ、あとsshの公開鍵を登録して、パスワード認証をスキップしておくと色々と便利です。


7. リモートリポジトリ(公開リポジトリ)の作成
公開用のリモートリポジトリの作成方法は以下の2つがあります。

  • 既存のローカルリポジトリの公開
  • サーバ側で新規に公開リポジトリを作成

今回はローカルリポジトリを既に作っているので、これを公開するようにしましたが、一応両方のやりかたを載せておきます。

[ローカルリポジトリの公開](クライアント環境にsshログインできる必要があります)

$ sudo mkdir /git
$ sudo git clone --bare ユーザ名@クライアントIP:~/git/project /git/project.git
$ sudo chown -R gitdaemon:root /git

まず公開リポジトリの本体を格納するディレクトリを作成しました。
その後、--bareオプション付きのcloneコマンドで、クライアント環境にあるローカルリポジトリを公開リポジトリとして複製しています。この時、クライアント側にアクセスするのにsshを使っています。

[サーバ側で新規に公開リポジトリを作成]

$ sudo mkdir /git
$ sudo git init --bare /git/project.git
$ sudo chown -R gitdaemon:root /git

違いはクライアントのリポジトリをクローンしていたのをinitに変更しただけです。公開リポジトリの場合は --bare オプションが必要です。最後のアクセス権変更はgitプロトコルでアクセスした時にリポジトリに書き込めるようにするためです。ubuntuのgit-daemonはディフォルトではgitdaemonユーザ権限で起動するようなので。

最後にdaemonの設定をします。

$ sudo vi /etc/sv/git-daemon/run

最終行を以下のようにしてください。

/usr/lib/git-core/git-daemon --verbose --base-path=/git --export-all --enable=receive-pack

--base-pathは上記公開リポジトリを格納したディレクトリ名です。この設定では/git以下にある公開リポジトリ全てがこのデーモンでアクセスできます。--enable=receive-packというのはgitプロトコルで匿名アクセスでのアップロードを受け付けるための設定です。これが無いとgitプロトコルでのpushができません。

gitwebの設定は/etc/gitweb.confで行います。

$ sudo vi /etc/gitweb.conf

$projectroot = "/git"に変更するのを忘れないように。


7. リモートリポジトリのアクセス方法
クライアント環境からのリモートリポジトリ(公開リポジトリ)へのアクセスには以下の3種類があります。

  • gitプロトコル
  • ssh経由
  • webdav経由

一番手軽で高速なのがgitプロトコルでのアクセスです。ただし匿名アクセスになるので、セキュリティ面でもssh経由を推奨したいですね。今回は両方立ち上げましたけど。webdav経由は不要でしょう。クライアント環境でのそれぞれのアクセス方法は以下の通り。

[Gitプロトコル]

$ git clone git://サーバIP/project.git

[ssh経由]

$ git clone ユーザ名@サーバIP:/git/project.git

それぞれの指定したパスが異なる事に注意してください。


8. ローカルリポジトリからリモートリポジトリへの変更公開

$ git remote add origin git://サーバIP/project.git
$ git push --all

ま、大抵これで何とかなります。ローカルリポジトリの変更内容が全てリモートリポジトリに送信されます。remote addってのはリモートリポジトリのアクセス先(アクセス方法)をエイリアス化したような物です。originってのは特別なリモートリポジトリ名称で、git pushとかのコマンドでリモートリポジトリ名を指定しないとoriginが使われるようです。


9. リモートリポジトリからローカルリポジトリへの変更取り込み

$ git pull master

こっちもこれで大抵なんとかなるかな?originが既に設定されている事を前提としてます。masterというのはsvnで言う所のtrunkという解釈です。masterの代わりにブランチ名を指定すれば、任意のブランチにpullする事ができます。


10. gitwebの立ち上げ
もう設定はしちゃったんで、apache2のrestartさえしていれば、ブラウザで以下にアクセスできるはず。

http://サーバIP/gitweb/

これで/git以下の全公開リポジトリの参照がブラウザから行えます。
アクセス権の設定などはapache2の問題なので、それを参照してください。gawk
設定するファイルは /etc/apache2/conf.d/gitweb です。


競合時のマージの話とか、肝心のブランチの話とかタグの事とか、もっと重要なバックアップを含めた運用方法の提案とか全く書いてないけど、まずは使ってみる事が肝心なので手順だけまとめておきました。後はやってみて、気が向いたら補足していくことにしますかな。happy02

【Git】 Gitリポジトリ構築(その1)

もう10年近くになるかな?
ソフトウェアのバージョン管理にSubversionを使ってきました。その前は言わずもがなCVSで、さらにその前はRCS、会社ではSoftbenchCMやClearCaseなんかもありましたけど。

Subversionはディレクトリ管理も含んでいるので、ファイルの追加・削除・リネームなども追跡できて、かなり重宝してました。また基本的に低レベルのリポジトリ操作が不可能なので、ユーザが誤ってファイルやブランチを削除する事がない(削除されても逆マージで戻せる)という安全性もあって、作業に慣れない人を含む業務ベースで使う際にメリットがありました。

ただ不満が無いわけではありません。
Subversionの主な問題点を挙げると大体以下の通りかと。

  1. 集中型リポジトリなのでコミット時にサーバ接続が必要。
  2. DB型なので色んな意味でちょと重い。(初期のBerkleyDB使っていた時の話ですけど)
  3. ブランチ・タグがディレクトリと同義のため・・・(好みによる)
  4. リポジトリが肥大化する。(業務で使うとこれが深刻)
  5. バックアップに時間がかかる。(リポジトリが肥大化する事が根本原因です)
  6. 誤って行ったコミットを取り消せない。(パスワードとか暗号鍵とか入れちゃうと大変)

この辺りでしょうか。
はっきり言って、これらの問題点はSubversionの利点の裏返しでもあります。
とはいえ、サーバ接続していないとコミットできないという1番の問題だけは、集中型リポジトリの問題そのものなので解決しようがない。しかも昨今のクラウド環境やら、SOHOスタイルでは馴染まないのも事実ですね。

という事で、遅まきながらLinusさんがLinux Kernelのために開発したバージョン管理システム「Git」に移行する事としました。Git自体は2005年の発表された分散型バージョン管理システムで、個人でもグループでも使い勝手が良いかな?と思ったので、その検証もかねて自宅サーバに構築する事としたわけです。

Gitは上位リポジトリ(リモートリポジトリとも言う)にSubversionを使う事もできますが、今回は完全にGitに移行しています。Subversionで管理していたリポジトリも一部を移行してみました。

さて、手順については次の記事で。

【ubuntu】 ubuntu 12.04 アップデート完了

ひとまず ubuntu 12.04 にアップデート完了しました。
kernelは3.2.0になっていました。

今の所、特に大きな問題はないけどアップデート後に行った事をいくつか。

  1. アップデート後にnVidiaのプロプライエタリドライバを再インストール
  2. デュアルディスプレイ時にUnityのランチャーが右画面にも表示されてしまっていたので設定変更
  3. 左右画面をマウスが通過する時に一旦止まるので設定変更。

nVidiaのプロプライエタリドライバはいつもの事ですね。
バイナリドライバなので、当然アップデートが必要。
ただ、今回ちょっとおかしいのは、アクセラレータサポートのドライバがインストールできませんでした。結局通常版(高機能ドライバと表示されています)のcurrentバージョンをインストール。まぁ、CUDAは自前で使うから良しとするか。

ランチャーの件は、Compizの設定ですね。
CompizConfig設定マネージャを開いて、"Ubuntu Unity Plugin"の"Experimental"タブに"Launcher Monitors"という項目があるので、これを"Primary Desktop"にすればメイン画面(我が家の場合は左側)のみに表示されるようになります。

Screenshot_from_20120427_152536
あとデュアルディスプレイ間の行き来する時に、ちょうどディスプレイを跨ぐ時にマウスが一瞬止まるような動作をしてました。11.10ではこういう事なかったと思うんだけどなぁ。ランチャー表示デスクトップ設定の下に"Launcher Capture Mouse"という設定を発見。このチェックを外すとスムーズに行き来するようになりました。

FirefoxでALTを押すとコマンドを入力できるようになっていたり、各アプリは大分変わっているみたいですねぇ。さて、色々触って自分のソフトの動作も確認しなくては。

【ubuntu】 ubuntu 12.04 キタ〜

4/26 予定通りにubuntu 12.04がリリースされました。
我が家でもアップデートマネージャで通知が来ましたよ。
12.04は10.04以来、2年ぶりのLTS版ですね。

さて、今回も早速アップデートしていきます。
10.04以来はOSの再インストールをせずアップデートだけでやってきました。
とりあえず矛盾は起きていない様子。

今回はどうなるかな?
Screenshot20120426_215219

«【VirtualBox】 WindowsXP on VirtualBox 4.1.10 on Mac OS X Lion