はじめに

私の所属するチームでは、プロジェクト管理ツールのRedmineを社内サービスとして提供しています。
この度、使用しているRedmineのバージョンが古くなってきたため、4系から5系へバージョンアップを行うことになりました。
しかし、このRedmineのバージョンアップにより、アジャイル開発向けのプラグインである、Redmine Backlogs（以下、Backlogsと表記）が動作しなくなったため、5系に対応しているScrumプラグインへ移行しました。この記事では、BacklogsからScrumへの移行で得たノウハウを紹介します。

Scrumとは

Scrum ⧉は、Backlogsと同様に、アジャイル開発のための機能を提供しています。
Backlogsとは使用感が異なりますが、概ね同じような使い方ができます。
以下はScrumとBacklogsの使用感を比較したものです。

かんばんの表示

• Scrumでは、「スプリント」タブ（Sprint board）でかんばんを表示します。

• Backlogsでは、「バックログ」タブから「かんばん」画面に遷移して表示します。

スプリントの一覧表示

• Scrumでは、表示したいスプリントをメニューから選択して切り替える必要があります。

• Backlogsでは、スプリントの一覧表示が可能です。

バックログとスプリント間のチケットの移動

• Scrumでは、バックログとスプリントの画面が分かれているため、ドラッグ＆ドロップによるチケットの移動はできません。チケットを移動するには、チケットのステータスを変更する必要があります。
  なお、同じスプリント内やバックログ内であれば、ドラッグ＆ドロップによるチケットの移動が可能です。

• Backlogsでは、ドラッグ＆ドロップによるバックログとスプリント間のチケットの移動が可能です。

  • 移動前

  

  • 移動後

  

バックログの数

• Scrumでは、バックログを複数作成することができます。

• Backlogsでは、バックログをデフォルトの1つのみ使用できます。

移行の前提条件

BacklogsからScrumへの移行は、以下の流れで実施します。

1. 移行元（Redmine4系環境）とは別のマシンに移行先（Redmine5系環境）を用意し、Scrumをインストールします。移行先環境のRedmineは/redmine_root配下にインストールされているものとします。
2. 移行元環境から取得したDBのdumpファイル、添付ファイルを移行先環境にインポートします。
3. 移行先の環境にBacklogsプラグインファイルをコピーしてアンインストールします。

移行方法

それでは、移行の手順について説明します。
以下、コマンドはすべてrootユーザーで実行します。

① Scrumのインストール

Scrumのインストール方法を説明します。

1. 以下のサイトからScrumの最新版のtar.gzファイルをダウンロードします。
   

   https://redmine.ociotec.com/projects/redmine-plugin-scrum/files ⧉
   本記事の記載内容はv0.23.1で動作確認を行っています。
   

2. プラグイン用のフォルダに解凍します。

1
# tar -zxvf scrum-0.23.1.tar.gz -C /redmine_root/plugins/

3. bundleコマンドによりマイグレーションを行います。この作業はRedmineがインストールされているディレクトリで実行してください。

1
# cd /redmine_root
2
# bundle exec rake redmine:plugins:migrate NAME=scrum RAILS_ENV=production RAILS_ENV=production

4. apache2サービスを再起動します。

1
# systemctl restart apache2

5. RedmineのWeb画面にログインし、「管理」>「プラグイン」画面に「Scrum Redmine plugin」が表示されていることを確認します。

   

② データ移行

1. 移行先環境でapache2サービスを停止します。

1
# systemctl stop apache2

2. 移行元環境から取得したDBのdumpファイルを移行先環境の任意の場所に配置します。

3. DBのdumpファイルをインポートします。

1
# sudo -u postgres psql --file=/tmp/backup/data.sql

4. 移行元環境から取得した添付ファイルを移行先環境の/redmine_root/filesに配置します。

③ Backlogsのアンインストール

移行先環境のBacklogsをアンインストールします。

1. Backlogsとの連携に必要なgem（holidays）をインストールします。

1
# bundle install --without development test --no-deployment

2. PostgreSQLのスキーマの権限を変更します。

1
# sudo -u postgres psql -d redmine
2
# GRANT CREATE ON SCHEMA public TO redmine;
3
# \q

3. Backlogsをアンインストールします。

1
# bundle exec rake redmine:plugins:migrate NAME=redmine_backlogs VERSION=0 RAILS_ENV=production

4. Redmine本体のDBをマイグレーションします。

1
# bundle exec rake db:migrate RAILS_ENV=production

5. キャッシュをクリアします。

1
# bundle exec rake tmp:cache:clear RAILS_ENV=production

6. apache2サービスを起動します。

1
# systemctl start apache2

移行後の初期設定

移行後は、実際に使用する準備としてScrumの初期設定が必要です。

Scrumの設定は、「管理」>「プラグイン」画面の「Scrum Redmine plugin」の右側にある「設定」から行います。

ここでは、Scrumの初期設定の中で重要な以下の項目について説明します。

1. Render Scrum plugin tips

tips（Scrumの活用を促す助言メッセージ）の表示/非表示を指定します。チェックすると画面の右端にtipsが表示されます。デフォルトではチェックが入っていますが、不要な場合はチェックを外して非表示にすることもできます。

【設定例】

【表示例】

2. Blocked custom field

ブロックを表すカスタムフィールドを1つ選択します。ここで選択するカスタムフィールドは事前に作成しておく必要があります。

【設定例】

【表示例】

• チケットにブロックを設定する

• チケットがブロック状態になる

3. Product backlog items

ストーリーチケット用のトラッカーをすべて選択します。ここで選択したトラッカーを使用したチケットはストーリーとして扱われます。

【設定例】

【表示例】

• チケットのトラッカーにストーリーを設定する

• 設定したチケットが、かんばんの「Product backlog items」列に表示される

4. Task statuses for Sprint board

「スプリント」タブに表示するタスクチケットのステータスをすべて選択します。

【設定例】

【表示例】

5. Tasks

タスクチケット用のトラッカーをすべて選択します。ここで選択したトラッカーを使用したチケットはタスクとして扱われます。

【設定例】

【表示例】

• チケットにタスク用のトラッカーを設定する

• 設定したチケットが、かんばんのタスク用に設定した列に表示される

6. PBI statuses for PB & Sprint

Scrumで「バックログ」タブおよび「スプリント」タブに表示するストーリーのステータスをすべて選択します。

【設定例1】

「新規」、「進行中」ステータスを選択する

【表示例1】

• チケットのステータスを「新規」、「進行中」に設定する

• ステータスが「新規」、「進行中」のチケットが「スプリント」タブでかんばんとして表示される

【設定例2】

「進行中」ステータスの選択を外す

【表示例2】

ステータスが「進行中」のチケットがかんばんとして表示されなくなる

チケットの移行

ここでは、BacklogsからScrumへチケットを移行するために必要な作業について説明します。
3つの方法で検証を行いましたが、ここで説明する1つめの方法はうまくいきませんでした。そのため、実際にチケットを移行する際には2つめと3つめの方法の内、どちらかを実施してください。

チケットのエクスポート・インポート機能で書き換える方法

Redmineには、チケット情報のエクスポート・インポートを行う機能が用意されています。この機能では、チケット情報をCSVファイルにエクスポートし、出力したCSVファイルをインポートすることができます。
Scrumでは、ストーリー・タスクチケットに「Sprint」というカラムを追加し、このカラムによってストーリー・タスクチケットがどのスプリントに所属するか管理しています。そのため、エクスポートしたCSVファイルに手作業で「Sprint」カラムを追加してインポートすることより、BacklogsのデータをScrumへ移行できると考えていました。
しかし、検証した結果、この方法では追加した「Sprint」カラムがScrum側で認識されませんでした。そのため、BacklogsからScrumへデータを移行するには、次項で説明する移行手順を実施する必要があります。

チケットごとにフィールドを書き換える方法

Backlogsでは、チケットの「対象バージョン」フィールドの値により、どのチケットがどのスプリント・バックログに所属するか管理しています。この方法ではこの値を修正します。

1. 移行元の環境で「Sprint1」という名前のスプリントに所属していたチケットを移行するために、移行先の環境で同名のスプリントを事前に作成します。

2. チケットの編集画面で「対象バージョン」フィールドに入っている値を確認します。

3. 「Sprint」の一覧から、「対象バージョン」フィールドに入っている値と同名のスプリントを選択します。

4. 「スプリント」タブを確認し、編集したチケットが指定したスプリントに所属していることを確認します。

DBを書き換える方法

チケットごとにフィールドを書き換える方法は、チケットの数が多い場合、時間が掛かり過ぎて現実的ではありません。
そこで、RedmineのDBのScrumに関係するデータを直接書き換える方法を紹介します。
ここではスプリントに所属するチケットのみ扱い、プロダクトバックログに所属するチケットは扱いませんが、作業の流れは同様です。

1. Backlogsでスプリントの管理に使用していた「versions」テーブルからスプリントの一覧を取得します。

   1. psqlを起動してPostgreSQLに接続します。

   1
   # sudo -u postgres psql -d redmine

   2. 以下のSQLを実行します。

   1
   SELECT id,name,created_on,effective_date,project_id,status FROM versions;

   【出力例】

   1
    id |     name       |         created_on         | effective_date | project_id | status
   2
   ----+----------------+----------------------------+----------------+------------+--------
   3
     1 | テスト用Sprint1 | 2024-01-01 17:46:18.766912 | 2024-03-31     |          1 | open
   4
     2 | テスト用Sprint2 | 2024-04-01 17:20:34.730498 | 2024-06-30     |          5 | open

   「versions」テーブルで使用するカラムは以下の通りです。

   カラム名	説明
   id	スプリントのid
   name	スプリント名
   created_on	スプリントの作成日時
   effective_date	スプリントの期日
   project_id	スプリントの所属するプロジェクトのid
   status	スプリントがオープン状態であるか

2. Scrumでスプリントの管理に使用する「sprints」テーブルにスプリントを登録します。

   手順1で取得した「versions」テーブルの値を指定します。

   1
   INSERT INTO sprints (name,sprint_start_date,sprint_end_date,user_id,project_id,status) VALUES ('テスト用Sprint1','2024-01-01','2024-03-31',1,1,'open');

   「versions」テーブルと「sprints」テーブルのカラムの対応関係は以下の通りです。
   

   「versions」 テーブルのカラム	「sprints」 テーブルのカラム	備考
   id	id	自動採番されるため指定しない
   name	name	-
   created_on	sprint_start_date	日付のみ指定する
   effective_date	sprint_end_date	-
   -	user_id	任意のユーザーのidを指定する
   project_id	project_id	-
   status	status	-

3. 手順1,2で取得した値で、チケットの情報を管理する「issues」テーブルを更新します。

   1
   UPDATE issues AS i SET sprint_id = subquery.sprint_id FROM (SELECT i.id AS issue_id, s.id AS sprint_id FROM issues AS i INNER JOIN versions AS v ON i.fixed_version_id = v.id INNER JOIN sprints AS s ON v.name = s.name AND v.project_id=s.project_id WHERE i.tracker_id IN (1,2,3) AND i.fixed_version_id IS NOT NULL) AS subquery WHERE i.id = subquery.issue_id;

   「issues」テーブルで使用するカラムは以下の通りです。

   「issues」 テーブルのカラム	説明
   id	チケットのid
   fixed_version_id	チケットの対象バージョンのid
   tracker_id	チケットに紐づくトラッカーのid
   sprint_id	チケットの所属するスプリントのid

   このSQLでは、以下の処理を行っています。
   

   1. 以下の条件でテーブルを結合する

      • 「issues」テーブルのfixed_version_idと「versions」テーブルのidが一致する
      • 上記の結果と「sprints」テーブルに対して、nameとproject_idが両方一致する

   2. 結合したテーブルから、以下のAND条件でレコードを検索し、チケットのidとスプリントのidを取得する

      • tracker_idが初期設定の「Product backlog items」と「Tasks」で選択したトラッカーのidと等しい¹
      • fixed_version_idがNULLではない

   3. 取得したチケットのidで「issues」テーブルを検索する

   4. 該当したレコードのsprint_idに、取得したスプリントのidを設定する

おわりに

今回はScrumについて、インストール方法やBacklogsからの移行方法を解説しました。この記事がScrumの導入を検討されている方や、Backlogsからの移行を考えている方のお役に立てば幸いです。