2024/11/24

「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT

第27回redmine.tokyo勉強会で講演された「RedmineのUbuntu+Docker構築への移行」は内容が参考になったと思う。
ラフなメモ書き。

【参考】
第27回勉強会 - redmine.tokyo

発表 #1609: 第27回 講演: <RedmineのUbuntu+Docker構築への移行> - redmine.tokyo

【1】今回の講演の背景としては、問題意識として、RedmineをCentOSで利用している場合、どのOSへ移行したら安全なのか、容易に移行できるのか、がある。
おそらく、Redmineはフリーで現場で使っているので、OSやサーバも自前で構築する時にCentOSを利用しているケースは非常に多い。
そこで、CentOSはサポート切れになってしまった状況では、セキュリティリスクがあるために、どこかのOSに移行せざるを得ない。
OSSのLinuxOSは数多くあるが、どれが最適であるのか?

さらに、どのOSが最適なのか、そして移行作業としてどれだけの工数や難易度が発生するのか、という問題も発生する。
RedmineというWebアプリ程度なら簡単だろうと思っていると、RubyやOSのバージョン、プラグインとの相性など色んな点で地雷を踏んでしまうリスクがある。

そういう背景を踏まえて、本資料を読み直すと価値があると考える。
本資料では2つの観点で整理できると思う。

【2】1つ目は、本資料では、CentOSからの移行先OSとして、Ubuntsを選択している。
移行要件詳細①を読むと、Ubuntsを選択している理由は明確だ。
s
Ubuntsを選択した理由を品質特性の観点で整理すると下記になる。

リリースの歴史が長く突然停止の可能性が低いこと
 →OSとして成熟しており、信頼性が高いと想定。

LTSの定期的な提供、2年単位の最新版提供により最新の機能が使える
 →最新の機能が使えるので、機能適合性が高いと想定。

Webクライアントとしてのシェアが高くナレッジ豊富
 →障害が発生しても障害解決の知見が豊富なため、信頼性(耐障害性)が高いと想定。
 →Ubunts上では、他のソフトウェアと共存し使用できる知見が多数あるため、互換性が高いと想定。

x86やARM等アーキテクチャを問わず稼働し、汎用性に優れる
 →x86やARM等アーキテクチャなど幅広く移植できるため、移植性が高い。

CentOS互換系のOS特有の機能を使わないのでCLIでよい
 →CLIでメンテナンス用プログラムを作成できるため、保守性が高いと想定。

CLIに慣れる事でLinuxに対する耐性や知見を上げる
 →CLIに慣れれば、UbuntsOSはCLIで操作しやすいため、使用性が高いと想定。

すなわち、信頼性、機能適合性、信頼性、互換性、移植性、保守性、使用性などでUbuntsの品質は高いと分析されている。
品質特性のかなりの数の観点が網羅されており、実際にRedmine移行で成功されたことを考慮すれば、Ubuntsを選択した理由には妥当性があると考える。

もちろん、RockyLinuxなど他のOSも候補に入るだろうが、普及されているUbuntsは移行先の有力候補になるだろうと思う。

【3】2つ目は、本資料では、Redmineの移行を今後も考慮するためにDockerを採用されていることだ。

vSphereの期限切れという事情もあるだろうが、Hyper-VとDockerのような仮想基盤の上にアプリ層を乗せる方が、今後の移行作業もコピーするだけでよく、作業しやすくなる。
「Redmineの移行」ページにソフトウェア構成図が記載されていて、Redmineが乗る基盤が層別に整理されていてイメージしやすい。

また、Dockerイメージを複製することで、移行後の動作検証やプラグイン検証、性能検証なども並行作業で実施しやすくなる。
本資料で注目すべき点の一つは、Redmine本体のDockerイメージ(sameersbn / redmine)とプラグイン込みのRedmineのDockerイメージを区別して準備されている点だろう。

既に準備されているRedmine本体のDockerイメージを利用する理由は、Webサーバやバックアップなどの基本機能が既にあり、プラグイン無しの標準機能がそのまま使えることだろう。
つまり、プラグインを使わずRedmine本体の標準機能だけで使うならば、公開されているDockerイメージをそのまま流用するほうが品質も担保されているし、検証や移行などの作業工数も無駄に使わなくていい。

一方、プラグイン込みのRedmineのDockerイメージはカスタムイメージで独自作成されている。
Lychee RedmineやFull Text Search等のプラグインを使われているそうなので、それらの動作検証を入念に行われたと記載されている。
確かに、プラグインの動作はRedmineのバージョンやプラグイン同士の相性、OSの相性にも依存するため、Dockerのカスタムイメージを作成した方が、プラグインを1つずつ入れて検証OKのDockerイメージを作りやすく、事前検証の先祖返りのリスクもないだろう。

本資料を読むと、View Customizeで改良した部分が動作しなかったり、Lychee Redmineのガントチャートの日本語表示はOSの日本語フォント配置で解決したり、応答速度低下のクレームにはインスタンスのスケールアップやMariageDBのチューニングで改善されたりしている。
やはり移行後には予期しないクレームも発生するので、色々対応せざるを得ない。
そんなケースでもHyper-VとDockerを使っているなら、インスタンスの性能チューニングも簡単だし、Dockerで移植し直すこともできる。

分かってしまえば簡単な内容かもしれないが、やはり実際に移行してみないと分からない時も多い。
そういう試行錯誤された事例として非常に価値ある内容と思う。

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

入門Redmine第6版 [ 石原佑季子 ]
価格:3,080円(税込、送料無料) (2024/11/24時点)


| | コメント (0)

2024/11/10

第27回redmine.tokyo勉強会の感想 #redmineT

本日、第27回redmine.tokyo勉強会にスタッフとして参加した。
非常に楽しかった。
ラフなメモ。

【参考】
第27回勉強会 - redmine.tokyo

redmine.tokyoで第二回プロジェクトマネジメントあるある! #redmineT | マドびっ! Madosan's View

【0】今回もプリザンター様の会場を利用させて頂いた。
とてもきれいな場所で、映像や音声もきれいで、そのまま懇親会の会場に使えるので、とても素晴らしい会場でした。
いつも本当にありがとうございます。

【1】今回の勉強会はオフラインで久しぶりに約45人も集まってくださり、雰囲気も良くて盛り上がったと思う。
大阪、京都、松江、山梨など遠方から参加してくれた人もいた。
一方、懇親会などで話してみて気づいたのは、初参加の人が多かったことだと思う。

10年以上続けているとどうしても常連さんが多くなり、居酒屋でローカルに盛り上がっている場みたいになって、雰囲気も停滞してしまう。
しかし、初参加の方や若い人が入ってくれると、フレッシュな気分になるし、入りやすいコミュニティの雰囲気も出てくるし、気付きもある。

年2回程度で開催するのが、飽きることもないし、スタッフも準備に苦労するほどでもなく、ちょうどいいのかもしれない。

【2】発表内容は今回も多様だったと思う。
Redmineというプロジェクト管理ツール、チケット管理ツールの機能面、技術面の話だけでなく、情報の追跡性や保持の観点、プロジェクトマネジメントの観点、ISMS運用などの運用の観点もあった。
参加者にはなにか1つは心に残るものがあったのではないかと思う。

第27回勉強会 - redmine.tokyo

講演も盛り上がってしまって、15分ほど延長するくらい濃い内容だったと思う。

【3】最後に告知タイムがあったが、川端さんより、ウクライナにいるRomanさん会社の開発者がアジャイルウェア社と一緒に仕事することになった、とご報告があった。
前回6月の勉強会では、ウクライナ人のRedmine開発者Romanさんのショート動画を紹介した。

第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT: プログラマの思索

ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン: プログラマの思索

川端さんのお話では、Romanさんはウクライナに住んでいて、戦争の影響を受けている。
Romanさんの会社は5人の社員がいたが、戦争のために2人になっていて、今も戦争によるインフラの影響を受けながらRedmineの開発をされている。
アジャイルウェア社の技術者とコンタクトを取れたので、今後Redmineに関する開発を一緒に行っていくことになったとのこと。

Redmineというオープンソースのツールの中でもそんなに大きくなく小さなコミュニティであっても、時代の影響、そして世界の状況を垣間見るような事例だったと思う。
少しでもコミュニティから役立ててもらえればと思う。

【4】@netazoneさんが、今年もRedmineアドベントカレンダーを作ってくれました。
興味のある方はぜひ、ご参加してみてください。
一緒に楽しめればいいなと思います。

Redmine Advent Calendar 2024 - Adventar

| | コメント (0)

2024/09/22

アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)

ソフトウェアシステムアーキテクチャ構築の原理 第2版」をアジャイルアーキテクトさんや他の方と輪読していたときの感想をメモ。

【1】「ソフトウェアシステムアーキテクチャ構築の原理 第2版」は既に絶版なのだが、内容は良い本だ。
アーキテクチャ設計のプロセスを現代風にうまく表現してくれている。
今のマイクロサービス設計にも当てはめることもできるだろう。

ソフトウェアシステムアーキテクチャ構築の原理 第2版」に出てくる用語は、図4-3.コンテクストにおけるパースペクティブを見ればいい。

43_20240922212201

その時のビューは、図15-1.ビュー間の関係 の観点で整理される。

151_20240922212201

【2】「ソフトウェアシステムアーキテクチャ構築の原理 第2版」をアジャイルアーキテクトさんや他の方と輪読していたときに一つの疑問があった。

ソフトウェアシステムアーキテクチャ構築の原理 第2版」では、アーキテクチャを定義し、設計し、実装し、評価する一連のプロセスが、図7-3.アーキテクチャ定義の詳細で定義されている。
そのプロセスの中に、「適切なアーキテクチャスタイルを識別する」プロセスでは、過去のアーキテクチャパターンを参照するという記述があり、腑に落ちていなかった。
アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか。
アーキテクチャ設計はもっと高尚なプロセスではないのか、という認識が強すぎた。

73_20240922211101

実際のシステム開発では、ユーザの要求を元に、業務やシステムの要件を定義し、スケジュールやコスト、品質の観点からアーキテクチャの候補を複数から選定して基盤を決定する。
そこから具体的な設計、実装に入っていく。
今なら、業務要件や機能要件を定義する中で、非機能要件を満たせるようなインフラ基盤やネットワーク基盤、開発フレームワークを選定するだろう。
サーバはクラウド、クライアントはPCやスマホなどを基盤に選定するだろう。

そういう設計を具体的に行うときに、過去のアーキテクチャパターンを参照するときもあるが、新しい技術を導入する時は過去の事例がないので、苦労するし、失敗しやすい。
その疑問を解決できていない気がしていた。

【3】この疑問について、先輩と議論して気づいたことがある。

アーキテクチャ設計について、アーキテクトの経験や会社の過去事例に既に実績があるならば、いきなりアーキテクチャ設計を実装するのではなく、要件を基に、過去に成功して実現性の高いアーキテクチャパターンを採用することで実装する方針を決めるのは自然な流れと理解した。
その時に、プロセスの実行(プロセスクラスをインスタンス化して実行)においても、同様に過去のプロジェクトで成功して実績のあるプロセス事例を参照して、プロセスを設計するのは自然な考え方ではないか、と気づいた。

一方、新しい技術を取り入れてアーキテクチャ設計する時、社外の専門家である外部ベンダーに参画してもらい、その知見を活かしてもらうわけだが、そのやり方も実現性の高いアーキテクチャパターンを知っている専門家を利用しているわけだ。

この辺りをモデル化してみた。

Photo_20240922211201


「当初の案」では、プロセスパターンクラスをアーキテクチャごとのタイプみたいなパターンクラスとみなし、プロセスクラスとしてプロセスのテンプレートを生成し、各プロジェクトではプロセスクラスのテンプレートををカスタマイズして実行するイメージだった。

しかし、要求とパターンの整合性を取る必要がある時に、要求そのものにパターンを抽出する基準が暗黙的に既に埋め込まれている。
実際、要求に沿ってシステムとして実現できるアーキテクチャはこれだ、と選定するときに、要求を制約事項とみなすアーキテクチャを過去のベストプラクティスを元に選定しているからだ。
つまり、アーキテクチャ設計としてアーキテクチャを選定するときに何らかの選定基準は暗黙的に埋め込まれている。

その暗黙的な基準こそが、パターンでありイディオムであるわけだ。
アーキテクトは、自身の脳みその中に、多数のパターンカタログ、イディオムカタログを暗黙的に保持していて、それを基準に当てはめている。

そこで、「田中さん案を元に再構成した案」で書き直してみると、プロセスパターンクラスをインスタンス化したものがプロセス記述書になる。
これはアナリシスパターンの抽象・具象パターンに相当するだろう。
そのプロセス記述書は、アーキテクチャ設計プロセスのテンプレートであり、どのプロジェクトでも使えるテンプレートになっている。
このプロセス、手順に従えば、アーキテクチャ設計ができますよ、という手順書になっている。
そのプロセス記述書は単なる手順書ではなく、過去のベストプラクティスが盛り込まれて、ソフトウェア開発が成功するような知見が盛り込まれているわけだ。

このプロセス記述書を各プロジェクトに当てはめて、必要であればカスタマイズして実装して、プロジェクトを実行していくことになる。

【4】そんなことを考えると、まだうまく表現できていないかもしれないが、ソフトウェア設計、ソフトウェア開発そのものも一つのソフトウェアのような気がしてくる。

そんな論文「Software Processes are Software, Too」は1980年代に既に提唱されているよ、と先輩から教えてもらった。

Software Processes are Software, Too

主張は「ソフトウェア開発プロセスは、プロセス記述書というクラスをインスタンス化したものである」と理解したがもう一つ重要な観点があると思う。
それは「ソフトウェアを再利用して効率化するやり方と同様に、ソフトウェア開発プロセスも再利用できるはずだし、それがパターンやイディオムになるはず」だという考え方だと思う。
つまり、「ソフトウェアシステムアーキテクチャ構築の原理 第2版」本で「適切なアーキテクチャスタイルを識別する」ときにパターンを参照することと同義だと理解している。

この辺りはもう少し整理してみたい。

| | コメント (0)

2024/08/31

「システム開発・刷新のためのデータモデル大全」を読み直した感想~親子頻出アンチパターンは初心者モデラーに多い

システム開発・刷新のためのデータモデル大全」を読み直した。
今までの経験を思い出しながら読み直すと気づきが多かった。
気づきをラフなメモ。

【参考】
業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

【1】テーブルをリソース系とイベント系の2種類に分けてみた

データモデリングが重要と分かっていても、ER図を書いてみても実際の業務フローや画面UIがイメージしにくい。
データ構造から業務フローがイメージできないと、単にデータがそうなっているだけとしか分からない。

そこで、マスタであるリソース系はR、トランザクションであるイベント系にはEをテーブルに付けて区別して見るようにしてみた。
業務フローをイメージするために、イベント系のテーブルは、TA字型ER手法を使って、外部キーがある関係は、先行後続を付けて見るようにした。
この考え方は「システム開発・刷新のためのデータモデル大全」にないがあえてやってみた。

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

(前略)
* resourceとresourceをつなぐ場合:対照表を生成する。対照表はeventである。
 (例)従業員と営業所
     従業員-営業所の対照表を作成し、リレーションシップを保全する。
* resourceとeventをつなぐ場合:event側に参照キーを持たせる。
 (例)顧客と注文
     注文entityに顧客コードを持たせる。
* eventとeventをつなぐ場合
** 「1:1」「1:m」:時系列の遅い方に持たせる。
 (例)受注と請求(一つの受注に対し請求は一つ)
     請求に受注番号を持たせる。
** 「m:1」「m:m」:対応表を生成する。
 (例)受注と請求(複数の受注に対し請求は一つ)
     受注-請求の対応表を生成し、リレーションシップを保全する。
(後略)

その結果、イベントに先行後続が順序付けられて、業務フローが見えてきて、付随するリソース系のイメージも湧いてきた。
そこから色々感じたこと、気になったことをメモしておく。

【2】リソース系テーブルのフィーチャオプションモデル

システム開発・刷新のためのデータモデル大全」では、製造業のモデルだけでなく、サービスやその他のモデルでもリソース系テーブルのフィーチャオプションモデルがよく出てくる。
なぜ頻出されるのか?

たとえば、製品や商品の属性をテーブルで保持しようとすると、横持ちでカラムが多くなる。
サイズ、色、重量などいろんな属性があるし、新製品によってさらに属性も新規追加されやすい。
横持ちのテーブルでは品種が多くなると破綻する。
そこで、品種という属性群を別テーブルで保持し、縦持ちでデータを持たせて、新規追加できるようにする。
つまり、製品や商品の属性データを横持ちから縦持ちにもたせて、汎用化している。
その分、マスタテーブル設計は複雑になるが、理解さえできれば応用が効きやすい。

フィーチャオプションはマスタ管理を整理するためのテクニックと思う。

【3】強属性のキーはサロゲートキーの代わり

複合主キーのマスタは、サロゲートキーにすると扱いやすくなる。
しかし、関数従属性がサロゲートキーのために分かりにくくなる。
そこで、サロゲートキーに置き換えられた複合主キーに当たるカラムを一度追加更新されたら更新できない制約をかける。
システム開発・刷新のためのデータモデル大全」では、この制約を強属性と呼んでいた。
複雑な商品マスタをサロゲートキーで主キーにした時、品種区分とFO項番が主キーのようになるが、「システム開発・刷新のためのデータモデル大全」の例では、品種区分を強属性としている。

強属性を使うことでマスタテーブルの関数従属性を表し、データの不整合が出ない仕組みにしている。


【4】親子頻出アンチパターン

データモデリング初心者はテーブル同士を関連付けようとする時、主キーの親子関係だけで表現しようとする。
特にトランザクション系のテーブルで多い。
注文と注文明細みたいに。
たぶんそういう関係付けの方がイメージしやすいからだろう。
そういうアンチパターンは、親子頻出アンチパターンと言われている。

しかし、本来は外部キーを使って、トランザクション系のテーブルに先行後続を関連付けるべきだ。
その場合、先行後続では多重度が異なる。

先行後続が1対多ならば、先行イベントテーブルの主キーが後続イベントテーブルの外部キーとして設定される。
一方、先行後続が多対1や多対多ならば、先行イベントテーブルと後続イベントテーブルの間に、連関テーブルが入り込んで2つのテーブルを1対多で関連付ける。
たとえば、出荷したデータをまとめて一括請求する場合などがあげられるだろう。

データモデルではイベント系テーブルを抽出した後、多重度から先行後続を読み取り、そこから業務フローを組み立てると一連の流れが見えてくると思う。

【5】時限NULL、永続NULLデータの考え方

イベント系テーブルでは、カラムの初期値はNULLだが、後続の業務が実行されてデータが更新されるタイミングで、NULLから値がセットされる。
システム開発・刷新のためのデータモデル大全」では、このようなデータを時限NULLデータと呼んでいる。
たとえば、後続イベントテーブルにある先行イベントテーブルの主キーを外部キーとして張っている場合がそうだろう。

データモデルではNULL値はできるだけ避けるべきだが、一時的にNULLの状態であって、データ更新のタイミングで値が更新されるならそれで良しという考え方になる。
システム開発・刷新のためのデータモデル大全」では、発注と入荷のデータモデルで入荷コードが時限NULLとして使われる例があって分かりやすい。

一方、マスタテーブルでは一つのマスタに属性を増やしていくと、カラムの初期値がNULLのまま永遠にセットされる場合がある。
このような例が永続NULLデータになる。
システム開発・刷新のためのデータモデル大全」では、永続NULLデータが存在する場合、サブタイプに分割すると良い。
つまり、テーブルの継承関係を使って、親テーブルのマスタに共通するカラムをまとめ、子テーブルのマスタにそれぞれの属性を集めたデータをまとめる。
顧客や取引先、仕入先などをまとめたテーブルを作りたい場合が相当するだろう。

【6】2次キー(2次識別子)の使い道

システム開発・刷新のためのデータモデル大全」では、2次キーが有効に使われるデータモデリングの例が多い。

たとえば、在庫推移監視モデルでは、受払テーブルが受払予定テーブルと受払履歴テーブルをサブタイプに持たせるが、それぞれの主キーは異なるので、そのままでは継承関係をデータモデルで表現できない。
そこで、受払・受払予定、受払履歴テーブルに2次キーを持たせて、継承関係を表現する。
2次キーはいわゆるAlternative Keyであり、一意なキーだから、検索時にも使える。

他にも、売上履歴に出荷明細、回収明細、一般取引明細の各テーブルを関連付けて、売上の履歴を一元的に管理していつでも検索できるようにするには、それぞれの主キーは異なるので、2次キーを持たせる。

一般に2次キーは、JANコードやマイナンバーのようにマスタテーブルでよく出るが、トランザクションテーブルに使うと効果的に扱える場合が割とあるように思える。

【7】負荷計画のモデルは2種類ある

システム開発・刷新のためのデータモデル大全」では、業務知識を埋め込んだデータモデルがふんだんに盛り込まれているので、データモデルを読み解いていくと、この関数従属性にはこういう業務ルールを埋め込んでいたのか、と気づく時が多い。
宝物探しの感覚に似ている。

システム開発・刷新のためのデータモデル大全」にあるデータモデルで興味深かった例は、負荷計画のモデルだ。
製造業では、工場の機械がリソース制約になり、工場の稼働率を決めて最終的には原価につながる。
そこで、設備の制約に関するスケジューリング決定について、TOCのアイデアを入れて、工程の日程を決める。

負荷計画を立てるときに、リソースの制約がスケジューリングに最も関わるので、制約になるリソースは何があるか、という問いに置き換えられる。
制約になるリソースは、製造業の工場なら設備だが、病院の看護スケジュールなら、専門技術を持つ人員になる。
ソフトウェア開発のスケジュールでも、インフラ環境の設備もあるだろうが、専門技術を持つ開発者が最も大きな制約になるだろう。
つまり、要員シフト管理では、専門技術を持つ人員が制約になる。
制約となるリソースが業態やビジネスによって大きく異なる点が面白い。

また、負荷計画では受注生産の工場、病院の看護師なら、受注済みの製品または予約済みの患者という需要に対し、「需要を設備の稼働を確保する」考え方になる。
一方、航空機運輸業の予約搭乗管理では、飛行機を既に持っており、その飛行機の座席をいかに予約で埋めていくか、になる。
つまり、「設備の稼働ありきで需要を確保する」ことになる。
他にも、新幹線や特急の予約もこの考え方になるだろう。

では、データモデルにはどのような違いが出てくるのか。
受注生産の工場、病院の看護師の負荷計画では、予定→製造指示のようにイベントテーブルは1対多の関係になる。
「需要を設備の稼働を確保する」データモデルでは、需要という予定をいかに設備で捌くか、という考え方になるので、予定→負荷を割り当てた計画スケジュールのように、先行後続のイベントテーブルが1対多になる場合が多い。

一方、飛行機のフライト管理では、フライト日程→フライト日程明細--予約搭乗明細→予約搭乗というイベント系テーブルで関連付けたデータモデルになっている。
つまり、先行後続のイベントテーブルが多対多の関係になっている
「フライト日程明細--予約搭乗明細」の関係は、それぞれの主キーが異なるのでそのままでは関連付けられないが、フライト日程明細テーブルの主キーを2次キーとして予約搭乗明細テーブルに持たせて、関連付けるモデルにしている。
これにより、フライト日程を決めたら、フライト日程の飛行機の座席に予約を割り当てて管理するという業務フローが成り立つことになる。

さらに、フライト日程明細テーブルの主キーを予約搭乗明細テーブルの2次キーに設定しているので、2次キーはNULLも設定できる。
NULLが設定される例として、座席指定できていないデータ、キャンセル待ちや搭乗者にカウントされない乳幼児があげられていて、そこまで業務ルールとして埋め込んでいるのか、と気付いて面白かった。

他のデータモデルでも、関数従属性に業務ルールが巧妙に埋め込まれているので、この辺りを読み解くと面白いと思う。

| | コメント (0)

2024/06/23

Redmineのバージョン設定でプロジェクトの設定方法が違う

Redmineのバージョン設定では、プロジェクトの設定方法が、サブプロジェクト単位、プロジェクト階層単位、プロジェクトツリー単位、全プロジェクトで4つある。
設定内容の違いにいつも迷ってしまうが、redmine.jpで詳細な解説があった。

プロジェクトの設定>バージョン - Redmineガイド

(引用開始)
共有: バージョンをほかのプロジェクトと共有します。共有すると、ほかのプロジェクトのチケットも割り当てることができるようになります。設定可能な共有範囲は次の通りです:

サブプロジェクト単位: 子孫プロジェクト

プロジェクト階層単位: 直系の先祖・子孫プロジェクト (最上位の親プロジェクトにおいて「バージョンの管理」権限が必要)

プロジェクトツリー単位: 最上位の親プロジェクトとすべての子孫プロジェクト (最上位の親プロジェクトにおいて「バージョンの管理」権限が必要)

全プロジェクト (システム管理者のみが設定可能)
(引用終了)

あるプロジェクトで設定したバージョンを、他のプロジェクトのどこまでの範囲まで設定できるか、を細かく設定できる。
プロジェクトはツリー構造に設定できるので、子孫だけなのか、親や先祖も含むのか、先祖が同じプロジェクトまで含むのか、を考慮する必要がある。

バージョン設定範囲を細かく設定したいケースは、バージョンを複数プロジェクトで使い回したいケースになるだろう。

| | コメント (0)

«ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン