Archive for the ‘未分類’ Category

BitBucket(Mercurial)からGitHub(Git)への移行方法

BitBucketで管理していたリポジトリをやっぱりGitへ移行したいとき、git-hgを利用すると簡単に移行できます。
(MercurialのリポジトリからGitのリポジトリへ移行したいときも大体おなじです)。では、やり方をみていきましょう。

1. git-hgをインストール

$ git clone https://github.com/cosmin/git-hg
$ git submodule update --init

でgit-hgを取得し、/opt/git-hgディレクトリなどにコピーします。これでインストールは完了です。

2. BitBucketリポジトリのクローン

インストールしたgit-hgを利用すると、MercurialのリポジトリをGitのリポジトリとしてクローンできます。

$ /opt/git-hg/bin/git-hg clone https://bitbucket.org/okamototk/kanonconductor

3. GitHubのリポジトリを作成

GitHubのWeb画面から空のGitHubのリポジトリを作成します。ここでは、okamototkユーザでkanonconductorという同じ名前のリポジトリを作成したとします。
リポジトリのURLは、

* https://github.com/okamototk/kanonconductor

になります。

4. GitHubのリポジトリへプッシュ

2でクローンしたリポジトリ上で作成したGitHubのリポジトリをリモートリポジトリとして設定します。

$ git remote add origin https://okamototk@github.com/okamototk/kanonconductor.git

okamototk@はGitHubのユーザ名です。CentOS6.xなどGitのバージョンが古いLinuxディストリビューションを利用している場合、必要となります。設定したら、プッシュします。

$ git push -u origin master

この例ではmaster(default)ブランチのみプッシュしていますが、他のブランチをプッシュすることも可能です。

5. BitBucket(Mercurial)のリポジトリの変更のマージ

BitBucket(Mercurial)のリポジトリの変更内容をGitHub(Git)のリポジトリへマージすることもできます。やり方は、Mercurialから取り込みたいブランチへ移動し、

$ git-hg  fetch

とし、Mercurialの差分を取り込みます。Mercurialリポジトリ上の差分を取り込む場合は、git-hgを使うことに注意してください。取り込んだ差分をマージするには、

$ git merge FETCH_HEAD

とします。これは通常のgitのマージと同じです。

mercurialのブランチは、

$ git branch -r
  hg/master
  hg/rel1.x
  hg/rel2.x..

のような感じでプレフィックスがhg/でリモートブランチとして登録されています。ブランチを切り替えるには、

$ git checkout rel1.x

などとすればokです。上記と同様にfetch/mergeでブランチの変更を取り込むことができます。

なお、Gitの使い方については、Gitポケットリファレンスをご覧ください。

Kanonの実装にみるBazaarのサーバ設定

この記事は、Bazzar Advent Calendar 2011年12月13日分の記事として執筆しました。

Kanonでは、Subversion、Git、Mercurialに加え、Bazaarもサポートしています。
これが意味するところは、Bazaarの共有リポジトリを簡単に立てれるということです。
Kanonを利用すれば、Bazaarのサーバ設定を気にする必要はありませんが、ここではKanonの実装をみながら、
自分でBazaarの共有リポジトリを立てる方法について見て行きましょう。

Bazaarをきちんとした共有リポジトリとして利用したい場合、Apacheと組み合わせて使いたくなってくると思います。
ApacheでBazaarを利用する場合は、次のようにします。

bzrは、標準でWSGIプロトコルを利用してWebサーバと通信するためのAPIを持っています。そのAPIを利用して、bzr.wsgiファイルを作成します。

from bzrlib.transport.http import wsgi

def application(environ, start_response):
    app = wsgi.make_app(
        root="/var/opt/kanon/bzr",
        prefix="/bzr",
        readonly=False,
        load_plugins=True,
        enable_logging=False)
    return app(environ, start_response)

rootには、リポジトリのルートを設定します。上記の設定の場合、/var/opt/kanon/bzrの下にリポジトリを複数立てていきます。次にApacheの設定ファイル(httpd.confなど)に先ほど作成したbzr.wsgiの設定を行います。

WSGIScriptAliasMatch ^/bzr/.*/\.bzr/smart$ /opt/kanon/lib/cgi-bin/bzr.wsgi
<Directory "/var/opt/kanon/bzr">
  WSGIApplicationGroup %{GLOBAL}
  Options Indexes
  AuthType Digest
  AuthName kanon
  AuthUserFile /etc/opt/kanon/kanon_users.htdigest
  Require valid-user
</Directory>

これでApacheを再起動すれば、準備は完了です。プロジェクトの初期化は、次のようにします。この例は、homuリポジトリを作成した例です。

$ bzr init-repo /var/opt/kanon/bzr/homu
$ bzr init /var/opt/kanon/bzr/homu/trunk
$ bzr chown apache.apache -R /var/opt/kanon/bzr

以上で、Bazaarサーバの設定は終わりです。

$ bzr clone http://xxxx/bzr/homu/trunk

でリポジトリをクローンできることを確認してみてください。Bazaarのサーバの構築は、Mercurialと同じくらい簡単に構築することができます。是非Bazaarの共有サーバを使ってみてください。

TracLightning3.1.3リリース

TracのSaaSサービスの開発を行っているjun66j5さんから、TracLightning 3.1.3がリリースされました。是非ご利用ください。

3.1.1までは全てのリリースのリリースマネージャを私が担当してきましたが、3.1.2から輪番制にしました。3.1.2のkanuさんに続く輪番制にしてから2つ目のリリースです。

輪番制にしたのは、幾つか意味があります。

  • 色々な人にOSSの開発とリリースを経験してほしい
  • わたしは、現在TracLightningを利用しておらず、開発から何ら利益を得ていないけど、TracLightningの開発に参加することにより、利益を得られる可能性がある人に利用して欲しい
  • 段々自分自身の興味が薄れてきてリリースするのが辛くなってきた

私自身は、TracLightningに対するモチベーションが薄れてきていますが、TracLighntingの開発に参加することにより、勉強になったり利益を得る可能性がある日人が居ると思っています。そういう人に活用してもらえればと思っています。

今回は、Cikloneの開発者のjun66j5がリリースマネージャとしてリリースして頂いたということで、TracLightningを便利だと思ったけど、インストールや環境の運用がめんどくさい人は、是非Cikloneを利用して頂ければと思っています。

ちなみに、今回のリリースでは、jun66j5さんが一番コミットでも貢献しており、その次に私が2,3バグを直した気がします。

残念ながら前回リリースマネージャを担当したkanuさんのコミットは0でした。輪番リリースマネージャ制にしたのはいいけど、コミッタとして定着しないのは、プロジェクトの課題だと思っています。(まぁ、別にやる気がある人がやればいいという話はありますが)

ということで、今後ともTracLightningをよろしくおねがいいたします。

Kanon Project 0.9.0リリース

Kanonの当初の構想は、M$のプロジェクト管理の製品群をOSSで実現するというものでした。しかし、別に本業でツール開発をやっている訳でもない自分が暇な時間を使って作るなど到底無理な話で、MS Projectのクローンを目指したKanon Projcetの開発は頓挫していました。まぁ、理由のひとつとしては、会社ではMS Projectを使っていて、問題ないということがありますが(汗

それでも、世の中貧乏人(失礼!!)が多いのか、Kanon Projectに期待しているという声もちらほら聞こえてきていました。

さて、先日、英語で国籍不明の外国人から、「SVGのエクスポートのパッチ作ったから取り込んでくれよ」というメールがいきなりきました。日本でさえ、致命度知名度が低くかつ、Googleabilityが低いKanon Projectを何処からみつけてきたのか、正直驚きました。その外人がたまたまアニメ/ゲームオタクで見つけたのかどうかは怖くて聞けませんでした(私は日本語でもそういう話題に疎い上に、さらに英語で書かれたらたまったものではないので)。

ということで、SVGパッチを取り込むついでに、風前の灯の勢いでバグを修正しKanon Project0.9.0をリリースしました(詳細はこちらから)。Java6以上が入っていれば、JavaWebスタートで簡単に試すことができますので、興味がある人は試してください。

ソースコードは、今回の事件を機に、無謀にも世界進出を狙ってGitHubに移し英語のREADMEも整備しました。ソースコードの取得はGitHubをご覧ください。バグ修正などはプルリクエストで受け付けます。

まぁ、アジャイルが最大限に盛り上がっているときに、「お前は今更何をやっているんだ」と思われなくもないですが、まぁ、使ってくれている人が居てそれに答えてりるだけなので、それでいいんです。はい(汗

第2回Linux女子部勉強会で話をしてきました

7/2に第2回Linux女子部勉強会(テーマ:「お仕事メリハリ術♪)で喋ってきました。ご参加頂いたみなさん、スタッフのみなさん、素晴らしい会場をご提供いただいたYahooさんありがとうございました。資料を公開しますので、興味がある方はご覧ください。例によって、画像などは削除しています:)

今回は、女子が多いということで、おそらくいつものネタが通用しないということと、チケットシステム・Tracさえ全く知らない人が聞きに来る可能性が高いので、悩みながら資料作成しました。途中、くだらない話をはさんだりしたのですが(くだらない話は資料中からは削除していますが)、みなさん、非常に熱心に話を聞いていたので、逆に焦りながら、話をしていました。プロジェクトマネージメント的な話は、女性の方がきちんとしていることが多いので、是非女性の方にも利用して頂ければと思います。

その他、プロセススケジューラ、Awk、LPIの話がありましたが、どちらも非常に興味深い話で、笑あり、突っ込みありと、若干ハラハラしながらも楽しめました。

最後に、Linux女子部への加入は、Linux女子部Google Groupから、Shibuya.tracの加入は、Shibuya.trac Google Groupから加入をお願いします。

KanonをEC2で動かす

torazukaさんにより、「KanonをAmazon EC2にインストールする」という記事が公開されています。KanonをEC2、もしくはクラウド上で利用するときは、ご参考にしてください。なお、Kanonのサンプルプロジェクトがここで公開されていますが、このデモ用のサーバは、KDDI WebコミュニケーションズさんのLinux VPSサービス上で動作しています(このサーバは、KDDI Webコミュニケーションズさんのご好意により無料でお貸し頂いています。ありがとうございます)。

社内にサーバが立てるのが面倒な方は、是非クラウドやVPSなどもご利用ください。

ちなみに、現在のKanonはCentOS5.xに対応していますが、KDDI Webコミュニケーションズ様からVPSサーバをお借りできる話があったときに、OSがCentOS5しか今のところ提供できないという話だったのと、他の多くのホスティングサービスやVPSサービスでもCentOSがメインだったので、CentOS5に対応しました。

クラウド/VPSに何を使えば良いか迷ったときは、KDDI Webコミュニケーションズさんサービスをお勧めしておきます。デバッグ環境があるので、ある程度のサポートできると思います。Linux VPSサービスの詳細はこちらをご覧ください。

OSSチャリティセミナーで発表しました

5/7(土)に開催されたOSSチャリティセミナーで発表しました。Shibuya.tracのコミュニティの紹介とDVCSを簡単に導入する方法を紹介しました。スタッフの皆様、参加者の皆様、ありがとうございました。

発表した資料をアップしておきます。著作権的にまずい部分は全て削除していますので、ご了承ください。資料の通り至って、真面目な紹介でした。DVCSの概要とBazaarの紹介については、公開され次第リンクを貼りたいと思います。

以下、上記の資料で省略されている本編です。

会場には、200名程度の方がいました。今までの勉強会とちがい、セミナーが選択性ではないので、「聴講者の中には興味がない人も居るのでは?」と思いましたが、みなさん熱心に聴いていらっしゃいました。逆にみんな熱心に聞いているのに、某アニメのネタが若干すべり気味であせったりしましたが、裏のtwitterでは盛り上がっていたみたいです(笑。

Shibuya.trac第11回勉強会で発表してきました

こんにちは、Oかもとです。

※ 当サイトのメンテナンスをしているのはOかもとだけではないので、明示的に誰が書いたか分かるようにする必要がある場合は、今後挨拶を入れることにします。

「チケットシステムによる初めてのアジャイル開発」というタイトルで、4/13に行われたShibuya.trac第11回勉強会「管理から可視化へ」というタイトルで発表してきました。(不肖ながら司会もさせて頂きました)


(編集可能なOpenOffice文書)
※上記資料は発表資料から公開NGの部分を削除し誰でも再利用できるマニュアル風に編集しています。

内容は、Kanon(TracLightning)を利用したアジャイル(スクラム)開発について、アジャイル開発のエッセンスを紹介しつつ、Kanonを利用してアジャイル開発におけるどの部分が効率的に運用できるかについて紹介しました。

Kanonをアジャイル開発で利用する際のポイントは、

  1. バックログ(ストーリー、タスク)の管理がチケットで行えるようになる
  2. バーンダウンと稼動時間の集計を簡単に行うことができる
  3. Excelで雛形を作ってインポートして使える

です。1のバックログの管理については、サブチケットが利用できる他のチケットシステムでも同等のことができますが、例えば、「ストーリー」のサブチケットを作成すると自動的に「タスク」と設定されるなど、スクラムで利用したときに簡単に使えるように最適化したり、バックログ閲覧用のビュー(レポート)や、担当者割り当て用のビューなど、用途別にビューを用意しています。

2.の管理面については、バーンダウンチャートはチーム単独の消化予想線(と呼ぶのでしょうか..)と実績を見れる他、複数のチームで開発する場合は、チーム毎の残時間を重ねて表示する機能も提供しています。チーム数が増えても対応できるようになっています。また、残時間の管理だけなく、稼動時間も管理できるように工夫しており、どのタスクに時間が掛かったか後で振り返ることができます。何よりも、自分のタスクの稼動時間・残時間を簡単に入力できるビューを用意しているので、めんどくさがり屋の人でも使い易くなっています。

3.のExcelからのインポートについては、個人的にExcelが好きであるというのと、最初のバックログの洗い出しの部分は色々な関係者(PO)との刷り合わせが必要であり、Excelベースでの管理の方がやり易いと思っているからです。もちろん直接チケットを入力していくことも可能です。

他のツールとの優位性

最近は、スクラム専用のツール・サービスが色々出てきていますが、正直言えば、商用のツールやサービスに比べると、TracLightning/Kanonは、タスク管理の部分に元々汎用的なチケットシステムであるTracにプラグインを追加したりカスタマイズして工夫して運用できるようにしているので、必ずしも優れている訳ではないと思います。ただ、

  1. Subversion、Mercruail、Gitなどのバージョン管理システムとの連携
  2. 継続的インテグレーションとの統合
  3. ウォータフォール的管理手法との統合(問題・課題管理、バグ管理など)
  4. アジャイル開発のインフラが無料でカスタマイズ可能なオープンソースとして利用できること

という点では、優れていると思っています。幾つかの点では、Redmineと被る部分はあると思います。あまりRedmineと比較するのは好きではありませんが、現在はTracの利点を主張する人が皆無になってきてたので(笑、敢えて紹介すれば、

  1. レポーティング機能によりSQLさえ書ければ様々なビューでチケットの分析を分りやすく行える
  2. 細かい使い勝手が良い。例えば、WYSIWYGプラグインにより初心者でも簡単に視覚的にWikiを利用できたり、OSのフォルダ(エクスプローラ)からファイルをドラッグ&ドロップするだけでファイルを添付できたりする。
  3. プロジェクト毎の切れが良いので、バラバラのサーバで運用しているプロジェクトを1つのサーバに集約したり、組織編制による引越しなどで特定のプロジェクトだけを別の場所(サーバ)に移動が簡単にできる
  4. (Trac/Subversionの話で)大手の会社で社内標準やソリューションとして利用され実績がある。TracLightning自身も小中企業で標準として採用されている

特に社内標準などのウォータフォール的な手法を一部利用せざるを得ないときは、SQLのレポートによるチケットの分析機能が役に立ちます。やはりRuby、Pythonと言った言語ができる人は一般的な現場には少ないです(私の主観ですが)。

SQLならJava、.NET、PHPなどの開発言語を問わず必要となるので、有識者も多いと思います。また、チケットをカスタマイズするために作成したSQLの知識は業務でも役に立つ可能性があるので、配属仕立ての新人に勉強でSQLをカスタマイズさせるのは良いかもしれません。

Tracは大企業でもそれなりに使われていますが、残念ながらあまり表に出ることはありません。TracLightningも幾つかの大手で使われていますが、会社名を出すことはNGだと先方に言われているので、大代的な利用方法や標準化が表に出てくることはないような気がします。Redmineは、社内のプロジェクト管理ツールを整備している方が発表していることが多いのは羨ましいところです。

さいごに

TracLightning、Kanonの紹介として書きましたが、ぶっちゃけて言えばツールは重要ではありません。どういうプロセスで開発をするか、したいか、また、開発における様々な制約条件(ウォータフォールにどっぷりな親父や社内標準的なプロセス管理手法、CMMI、ISOなど…)をどのようにクリアしていくかが重要だと思います。まずは、開発において何を管理しなければいけないかを考えてツールを選択するのが良いと思います。また、プロセスも固定ではなくプロジェクトを運用しながら改善されていくべきですが、プロセスの改善にあわせてツールもカスタマイズされ進化すればより一層効率的な運用ができることでしょう。ツールを選択する際に、プロセスを選択でき、また、プロセスに合わせてレポートを簡単にカスタマイズできるTracLightning/Kanonをご利用いただけると幸いです。

virtualenvへの以降に伴う変更

KanonをCentOS5へ対応するのを機にPythonライブラリのインストールディレクトリを識別する方法として、~/.pydistutil.cfgを利用する方法から、virtualenvを利用する方法へ変更になりました。これに伴い、以前Kanonをインストールしたマシンに最新版をインストールする場合、~/.pydistutil.cfgファイルを削除する必要があります。また、プラグインなどを自分で追加でインストールする際には、

# source /opt/kanon/bin/activate

を実行する必要があります。ご注意ください。

Kanon Naiagara/AllegroでCentOS5対応

ウォータフォール向けのKanon Naiaragaとアジャイル向けのAllegroでCentOS5対応を行いました。これで、CentOS5でも利用できるようになりました。CentOS5対応を行うに辺りtanacasinoさんのご協力を頂きました(というより、tanacasinoさんがメインで対応して頂いたのですが)。

ホスティングサービスなどで利用する場合、CentOS5しか利用できない場合があったり、CentOS6はまだリリースされていないし、リリースされてもメジャーバージョンアップしたばかりで不安だという方は、是非CentOS5でお試しください。

Naiagara/Allegroのインストール方法については、こちらをご覧ください。