ロリポップで運用できる BTS はあるのか＜Mantis NG編＞

ホーム > 技術・サービス > ロリポップで運用できる BTS はあるのか＜Mantis NG編＞

ロリポップで運用できる BTS はあるのか＜Mantis NG編＞

2009 年 10 月 07 日コメントをどうぞコメント

IPMsg 用に BTS を用意したいと考えましたが、難航しています。

「BTS」というのは Bug Tracking System の略で、ソフトウェアのバグや要望を報告して処置の経過を追うことが出来る不具合管理システムです。仕事では結構長く Bugzilla を使っていて、最近は Redmine に乗り換えています（社内 LAN の中の開発サーバで稼働させています）。世の中的には Trac というのが有名です。

このサイトは現在ロリポップというレンタルサーバを利用しています。理由は安いことと、実績がそれなりに確かなので。ロリポはダメという人もいますが（そして言っていることも分かりますが）、格安の値段でそれなりの稼働水準のサーバというのが、小さな個人サイトにはちょうどいいと思います。実際よくサーバエラー起きますし、バックアップも頻繁に取っていますけど（笑）。

ただ、ロリポップは安いだけあって制限も多いです。WordPress や MovableType のような有名 CMS は問題ありませんが、BTS はなかなか動かせそうにありません。
先週からいろいろ調べて試してみたのですが、まだ運用可能な BTS は見つかっていません。とりあえずこれまでの経緯をまとめて、さらに調査を続けてみます。

BTS 導入の動機。

IPMsg の既知のバグ管理はいままでどうなっていたかというと、開発再開以前は単なるテキストファイルにリストアップされて、自分で不具合と将来の数段階の機能拡張に分類していました。「自分の頭の中だけにある」という野心的かつ非現実的な方法を除けば、最も原始的な方法です。

BTS と構成管理ツール (SVN) は IPMsg の開発停滞期間中に仕事で使うようになり、それなしでは開発はできなくなっているので、今回 IPMsg開発を再開するにあたり導入は必須でした。SVN はローカル環境（+DropBox で複数マシンシームレス）で運用していますが、BTS に関しては、せっかくサーバも借りているし公開できる場所に用意したいと考えました。

ソース公開しているし SourceForge を使うというのも方法の一つなのですが、とりあえずそれは手詰まりになったらの手段にしようと思っています。

ロリポップの制限。

簡単にいうと ssh でログインすることはできず、いわゆる LAMP で動くレベルのものでなければ動かないということです。そして今一番ネックになっているのは、MySQL が 4.0.x だということです。ちなみに sqlite も使えません。

BTS の選定 → Mantis。

最初に考えたのは、 Bugzilla か Trac か Redmine か、でした。

Bugzilla は使い慣れているのですが、複数プロジェクトが管理できないし、新たな勉強にならないのでやめます。

Trac は Python が必要なのですが、ロリポでは Python が入っていないので使えません。

Redmine は Ruby on Rails が必要なのですが、ロリポでは Ruby はあるものの Rails は非対応です。ググるとロリポで Rails を動かす方法がヒットするのですが、動かすことが目的でやっているようなもので実用のパフォーマンスは出ないそうです。

….いきなり行き詰まりました。

が BTS について調べているうちに Mantis があったことに気がつきました。オリジナルの作者が日本人で日本語の情報が多い、機能も必要十分で LAMP で動くという理想的な BTS です。会社でも使われているのを見たことがあります。見た目はちょっと色が派手でごちゃごちゃしていてどうかなと思うのですけど、Mantis 以上の選択肢はなさそうなので Mantis を使うことにしました。

調査段階やインストールを始めるにあたっては主に以下のサイトが参考になりました。
http://www.alles.or.jp/~sogabe/mantis/
http://bacons.ddo.jp/wiki/mantis

インストール。

Mantis を公式サイトから落としました。1.2.0rc1 が最新でしたが、Stable なものがよかったので 1.1.8 をダウンロードしました。

手順ではサーバに tar.gz アップして展開となっていますが、ロリポップは ssh がつながらないので、ローカルで展開したものをアップロードし、config_inc.php にインストール時に最低必要なデータベース関連とその他少しの設定を記述します。

次に、/admin/check.php を動かしてエラーがないかかどうか確認してみると、MySQL は 4.1 が必要だがサーバでは 4.0 が動いている、というエラー（BAD 表示）が出ます。そうはいっても MySQL のバージョンは固定で変えられないので、インストールしてみることします。

インストールには /admin/install.php をブラウザから読み込みます。やはりバージョンチェックに引っかかって進みません。本当に MySQL 4.1 以上が必要なのか、実際は 4.0 でも動いてしまうのではないかと根拠のないことを考えて、無理矢理インストールを続行させることにします。insatall.php に含まれる、MySQL のバージョンチェックのコード（2箇所ある）をコメントアウトして通過できるようにします。

これによりインストールは完了しました。データベースにたくさんのテーブルもできています。

しかしエラーが表示されてログイン画面がでない….。

APPLICATION ERROR #401

データベースの検索に失敗しました。データベースからエラーを受け取りました。 #1193: Unknown system variable ‘NAMES’ (クエリー: SET NAMES UTF8)

ブラウザの戻るボタンを使用して前のページに戻ってください。そこで、エラーで判明したチケットを直すか他のアクションを選択してください。もしくは、メニューバーからオプションで選択して、新しいセクションに直に進んでください。

SET NAMES というのは DB の文字コードを指定するものなのですが、MySQL 4.0 以前は文字コードの指定はできなかったようです。WordPress も UTF8 ですが MySQL 4.0 で動いているので、 MySQL 4.0 には SET NAMES は必要ないとみてクエリを実行している行をコメントアウトしたところ、ログイン画面が表示されました。

新しい管理者ユーザアカウントを登録して、初期管理者アカウントと /admin/ ディレクトリを削除して、運用開始できる準備が整いました！

…..と思ったのですが。

Mantis 残念。

見た目インストールが無事に成功しているので、IPMsg のプロジェクトを追加して、バージョンを定義して、（テキスト管理中の）バグ一覧からいくつか不具合を登録しました。それなりにうまくいっているように見えました。

…が、トップページから登録したバグの情報を見に行くと、レイアウトが妙です。よく見ると、狭い幅のセルにエラー内容が出力されているためにレイアウトが崩れていたのでした。

APPLICATION ERROR #401

データベースの検索に失敗しました。データベースからエラーを受け取りました。 #1064: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near ‘SELECT tag_id FROM mantis_bug_tag_table WHERE bug_id=’3′ ) ORD (クエリー: SELECT id, name FROM mantis_tag_table WHERE id NOT IN (
SELECT tag_id FROM mantis_bug_tag_table WHERE bug_id=’3’ ) ORDER BY name ASC )

ブラウザの戻るボタンを使用して前のページに戻ってください。そこで、エラーで判明したチケットを直すか他のアクションを選択してください。もしくは、メニューバーからオプションで選択して、新しいセクションに直に進んでください。

さっきと似たような文言なのですが、エラーになっている SQL 文が違います。なぜなのか調べてみると、MySQL 4.0 以前はサブクエリが使えないのでした、なんと。MySQL 4.1 以上が必要とされていたのにはきちんとした理由があったのです。そりゃサブクエリなしはきつい。
仮にエラーが発生した部分だけ無理矢理サブクエリを使わないように変更したとしても、ここ１カ所だけの問題とは思えませんし、すべてを変更できるものではありません。

ということで、 Mantis で BTS を運用開始できるかと思ったのも束の間、MySQL ネックで無理でした。