FileBlogのバージョン管理機能について

FileBlogを販売してからの20年弱の期間、「ファイルのバージョン管理機能はないか？」という要望を繰り返しいただいて参りました。

ユーザーの言葉としては同じでも、その真意には様々なニーズがあることに気づき、バージョン管理という課題に対して私たちは次の三つの機能を提供します。

ごみ箱 機能

一般の業務で扱う多種・大量の文書の管理においては、それぞれのファイルは独立して編集されるものが比較的多く、ファイル単位で簡単にバックアップや復元を行いたいというニーズがあります。

いわゆる（リレーショナルデータベースを用いるような）「文書管理データベース」製品が備える「バージョン管理」機能のほとんどは、ファイル単位のバージョン管理機能であり、本機能（ごみ箱）がそれに相当します。

FileBlog Ver.2の時代からいただいていた要望であり、ようやくVer.5.4で実現しました。機能名は「ごみ箱」ですが、上書き更新されたファイルも自動バックアップ対象であり過去世代の復元が可能です。

従来の課題

従来よりWindowsのボリューム シャドウ コピー サービス（VSS）機能によって変更の履歴を残すことができました。ただし、VSSからの復元にはWindowsシステム管理者権限が必要なため、誤って削除したり上書きしてしまって内容が失われてしまった場合、システム管理者への復元作業の依頼が必要でした。

これは管理者の負担にもなり、また管理者不在の際にはあきらめて文書を作り直さなければいけない、といったこともしばしばあったと思われます。

FileBlogの自動バックアップ

FileBlogの「ごみ箱」機能は、PCデスクトップに存在するごみ箱機能をFileBlogでアクセスする共有フォルダに拡張し、Webアプリを通じて削除・上書きしたファイルについて、以前の内容をごみ箱用の別領域に自動的に退避してバックアップしたうえで、ユーザー自身のセルフサービスでバックアップファイルの復元を可能にするものです。

ごみ箱に退避されたファイルは、フォルダを指定して過去にそのフォルダにあったファイルを検索したり、ファイルを指定して過去バージョンを検索したりできます。このとき、ごみ箱領域内のファイルのアクセス権は、ごみ箱に入る前の元のファイルのアクセス権と同じに設定されます。

ごみ箱のセキュリティ

共有フォルダについて「ごみ箱」の運用が難しかった原因は、ごみ箱のセキュリティ問題にあります。

誰にでもアクセスできるごみ箱を設置し、ごみ箱内の削除ファイルを検索できるようにした場合、「ごみ箱をあさる」行為が情報漏洩をもたらす危険となります。

限られたユーザーのみにアクセス権が与えられたファイルは、ごみ箱内であっても他のユーザーには見えない状態であり続けることが必要です。

FileBlogでは、ごみ箱内のファイルを検索する際、全文検索エンジンの助けを借りてバックアップファイルをまとめて一覧できますが、ユーザーによるファイル操作の都度、新たに独立のごみ箱フォルダを作成し、削除時点でのアクセス権を引き継ぐことで、ごみ箱領域でのファイルアクセスを安全に保ちます。

自動バックアップの対象

• FileBlog（Webアプリ）から「削除」「上書き更新」したファイルが対象です。
• ドキュメントルートフォルダが共有フォルダの場合、FileBlogを介さずに直接Windowsエクスプローラや、Microsoft Officeアプリなどでファイルに直接アクセスが可能ですが、直接アクセスで加えた更新は対象外です。
• ドキュメントルートフォルダへの直接アクセスを禁止して運用するには、ドキュメントルートフォルダを非公開にしてます。（隠し共有フォルダやローカルドライブのフォルダを使用します）

ごみ箱の保管ポリシー

• 自動バックアップされたファイルの保存期間（日数）を定義し、ごみ箱の掃除タスクをスケジュール登録して定期的に実行することでディスク消費を抑制できます。
• すべての履歴を残すことも可能で、ごみ箱の掃除タスクを無効にし、ごみ箱内のファイルの手動削除を禁止します。

Gitバージョン管理 機能

Gitは、オープンソースのバージョン管理システムであり、オープンソースソフトウェアコミュニティにおけるデファクトスタンダードです。

大規模なマニュアルなど、複数のファイルが相互に参照・関連しあって、全体としてひとつの文書単位となるケースでは、
個別のファイルごとのバージョン管理では不十分です。

Gitを用いることで、フォルダ内の数百・数千のファイルを時点における断面の単位で、まとめて保存・復元できるようになります。

FileBlogでは、特定フォルダ以下をGit管理フォルダと定義することで、Webアプリケーション（FileBlog画面）を介してファイルを操作（アップロード・上書き・リネーム・削除・コピー・移動）した場合に、自動的にGitリポジトリによってバージョン管理を行うことができます。

変更履歴の参照・過去データの復元

Gitバージョン管理の対象フォルダでは、ファイル単位の変更履歴のみならず、フォルダ単位での変更履歴を参照できます。

過去のデータの復元についてもファイル単位のみならず、フォルダ単位で過去時点の断面（スナップショット）を取得可能です。

Gitリポジトリの運用

Gitは強力なバージョン管理システムですが、全フォルダの完全な履歴を維持するため性能面では不利となります。1つのリポジトリのサイズは数千ファイル程度を想定しており、数十万・数百万文書以上の大容量フォルダのバージョン管理には適しておりません。

「複数のファイルが相互に参照・関連しあって、全体としてひとつの文書単位であり、その単位での復元が必須か？」を基準に使い分けてください。

リポジトリのサイズを小さく抑えるのに、複数のリポジトリを作って運用する方法があります。文書種別や部課・チームでリポジトリを分けて文書のバージョン管理を行うことができます。

Gitリポジトリの制限

FileBlogでGitバージョン管理の対象としたリポジトリは、FileBlog内部で管理されます。

ファイル更新の競合を解決する手段はFileBlogにはありません。FileBlog外の別途Gitクライアントなどからのファイル操作はしないでください。

FileBlog内で操作したリポジトリは、FileBlog外にエクスポートすれば任意のGitクライアントで参照可能です。

外部Gitリポジトリの検索

すでにプログラムのソースコードなどの管理で、Gitクライアント/Gitサーバーで更新されるGitリポジトリを運用されている場合でも、既存のGitリポジトリをFileBlogの全文検索対象にすることが可能です。

通常は変更履歴にある最新ファイルを検索対象としますが、過去履歴のファイルも全文検索対象とすることも可能です。

• たとえば、外部Gitサーバーでメンテナンスされているリポジトリの場合、FileBlog管理下のフォルダに当該リポジトリをフェッチしてくることで、FileBlogでリポジトリ内のファイルを参照・検索できます。
• 定期的にフェッチ（強制上書きフェッチ）することで、外部Gitサーバーにプッシュされる変更に追従できます。