Redmine 運用について 1/3 - はじめに
以下の記事に触発され、私の実施している Redmine 運用についてまとめたくなった。
しかし書いているうちにものすごく長くなってしまったので、全 3 回へ分割することした。
初回は自身と Redmine の関わりについて。どのような立ち位置から書かれているのかを前置きすることで、読者は自身との距離感を意識しながら記事を読めるのではなかろうか。Redmine 導入を提案するのであれば先行事例として参考に。提案されている側なら相手がどのような背景や思想をもっているかを理解するのに役立つ、というのが本記事の狙い。
私の Redmine 運用経験
私は前職も含めると足掛け 6 年ほど Redmine を運用してきた。バージョン更新などの環境構築や運用ルール策定なども含む、システム管理者として活動している。
導入のきっかけについて。
親戚に Ruby on Rails でアプリ開発する企業を経営している方がいて、プロジェクト管理に Redmine を採用している話を聞く機会を得た。ちょうど業務で複数プロジェクトを TDD で回したいと考えていたのだが当時採用していた Trac では面倒そうだと感じていたところである。
語られた Redmine の機能では、特に複数プロジェクト管理に強く惹かれた。その企業では小さな実験的プロジェクトを数多く管理する必要がある。そのため気軽にプロジェクトを追加できる Redmine が重宝しているのだという。ある機能を共通モジュールに切り出すときも、そのプロジェクトに元となる機能のチケットを移動させるとか、モジュールのチケットを利用側のチケットに関連付けられるといった管理も便利とのこと。
この事例に強く興味を惹かれ、けれどもいきなり業務で採用するのは怖いので、まずは個人で試してみることにした。
さくらのVPS を使いはじめるはそのときの話。ちょうど Redmine v1.0 がリリースされるかも？というタイミングだったと思う。はじめは共用レンタルサーバーで動かそうとしたけど CGI モードは激重なので Passenger のために VPS へ移行した。これは現在このブログを稼働させているサーバーでもある。
実際に個人開発で試してみた結果、気軽に複数プロジェクトを作成できること、ガントチャートやカレンダーなどのよく使う機能が標準搭載されている点が気に入った。複数プロジェクト管理を前提としているためチケットや Wiki の参照を横断的に指定できるところもよい。
というわけで導入を提案。
前職で私が在籍していたのはソフトハウスの開発部署だったこと、既に Trac である程度 TDD に馴染んでいたことから提案はすんなり通った。私がシステム管理者になることを明言。本業に影響しなければいいよ、と許可を得た。
浸透もわりとスムーズだったと記憶している。基本ルール策定やインフラ面を管理していたぐらいで、割りとうまく分割統治できていた。
現職は移籍前から Redmine が運用されていたものの、あるレンタルサーバーの付属サービスを利用していた。残念ながら提供されるバージョンも数世代前であり更新予定もなさそうなので DB や添付ファイルを吸いだして VPS に立てなおした環境へ引き継いだ。
Redmine の運用期間は前職 4 年、現職 2 年ぐらい。前職はソフトウェア開発中心だったので Redmine によるチケット管理と相性がよく、基本的な運用の経験値を貯めるのに有用だった。
現職はソフトハウスではないのだが製造業の一種であるため、同様に Redmine 向きな業務が多いと認識している。現に一部の社員は積極的にチケットを利用しているのだが、熟年社員や IT リテラシーの高くない社員への浸透はイマイチである。
幸い管理職が積極的であるため、2 年を経て全社的にチケット管理で回そうという体制にはなりつつある。しかし社員個人が能動的に利用する状態になっていないと管理職の負担が増すだけなので、ここを改善するのが目下の課題であり、やりがいを感じる部分でもある。
業務におけるシステム管理の割合
Redmine のシステム管理を担当するとして、業務でどれぐらいの労力を掛けているのか？は気になるところだろう。私の場合は前職、現職ともに体感で 5 〜 10% ぐらいである。
Redmine 導入と更新、運用ルール改定にコストが掛かるものの、それ以外は分割統治がわりと上手く回っていて、メイン業務であるソフトウェア開発への影響は気にならないレベル。
Redmin 更新は基本的に Major、Minor レベルのバージョン単位で実施している。セキュリティに関する致命的な問題が解決されている場合は Revision レベルでも更新。おおむね数ヶ月に一度ぐらいで済んでおり、時間にして長くても 30 分ぐらいで済むから負担でもない。この辺、運用ルールあたりで詳しく書く予定。
v0.x 時代の Redmine は非常に不安定で、Ruby や Rails 絡みのトラブルに悩まされたものだけど、v1.0 あたりからは問題に遭遇することはほとんどなかった。また Ruby 環境を rbenv/rbenv で管理するようになったのも大きい。
Redmine の環境トラブルでよくあるのが、Gem にまつわるもの。あるプラグインを試そうとしたらグローバルな gem が必要になってインストールしたけど、依存関係の問題とかバージョンが古すぎて環境が壊れた、みたいな問題は何度か経験した。
rbenv の場合、Ruby 環境を複数同時に構築して切り替える方式となる。そのためある環境が壊れたら、安定していたものに戻すといった運用が可能。これで随分と管理が楽になった。また、Redmine 3.3.0 リリース - Enjoy*Study のように最新の Redmine 環境を Vagrant box として提供してくれる方がいるおかげで、新バージョンを検証しやすいのも助かる。
更に現職では私の他に 2 名のシステム管理者を任命、運用ルール Wiki に明記された管理業務であれば代行可能な体制にした。これも負担を下げるのに役立っている。
テーマ開発
私は akabekobeko/redmine-theme-minimalflat2 という Redmine テーマを開発している。元々、個人利用のために minimalflat を作り始めたのだが minimalflat2 は職場で採用することを前提に開発している。
普段の業務で触れるものだと開発意欲が持続できてよい感じ。
たまに第三者から issue や Pull Request が来ることがあるのも嬉しい。励みになる。問い合わせは日本語でも受け付けているので、この記事を読まれている方でテーマへの要望があれば遠慮せずにどうぞ。
まとめ
はじめは単一記事に運用ルールも含めた内容を書くつもりだった。しかし今回の前書きだけでもかなりの量になって目次を付けても読みにくいので分割することにした。
6 年も関わっているシステムだけあり、いざ書き始めると触れたい内容が次々と湧いてくる。今回の内容も独立した記事としたこどで当初の倍ぐらいになった。
個人的な体験談が多くて第三者からするとあまり興味のない回かもしれない。こうした回顧録は私的に楽しむものであり、当時の状況を懐かしみながら書けてよかった。私によし、という感じ。
次回は Redmine の運用ルールと諸設定についてまとめる予定。