悩ましいテスト環境の構築.
どの言語でも悩ましいと思いますが、FileMakerでのテスト環境も「どういうふうにテスト環境を作ろうかな」と毎回悩みます。
今までの経験上、「こんなテスト環境があったな」というのを挙げてみます。
また、それを踏まえて「本当はこうなっていると安心して修正・テストができるのよ」も締めとして結びたいと思います。
Claris FileMakerの本流ではない（かもしれない）テスト環境も含まれます。
あくまでも、自身が経験したテスト環境になります。
こんなテスト環境で作業しました
1.本番環境で直接直す
あります、あります。
「本番環境しかありません」
というところ、あります。
現場に到着したら、「そのまま本番環境で作業してください」
と言われて、運用している隣で修正・テストをしたこともあります。
「これしかない」ので、仕方なく、本番環境で直します。
ヒヤヒヤです。
ただ、文言の変更など、軽微な修正の場合は、本番環境で直接直すことは、よくあります。
2.運用中ファイルを別の環境にコピーして修正
FileMaker ServerやFileMaker Cloudを利用せず、単体で運用しているクライアントもいらっしゃいます。
その場合は、本番ファイルをこちらに送ってもらい、それを修正・テストして送り返します。
送り返したファイルを本番の運用ファイルとして使ってもらいます。
これは、意外と安全な方法で、運用中のファイルとは別に作業ができるので、安心して作業ができます。
ただ、長期間かかる修正には不向きで、すでに修正箇所がわかっていて、夕方受け取ったら次の日の営業開始までに修正・テストが終わるような場合に、この方法を適用しています。
3.本番サーバにテスト環境を構築
本番サーバに、バックアップからテスト用ファイルを持ってきて修正・テストをし、問題なければ今まで使っていたファイルのデータをテスト用ファイルにマージします。
もしくは、本番ファイルに修正内容をパッチします。
テストサーバの用意がなかったり、サーバにあるファイルをPCにダウンロードして作業できない環境では、これもよくあります。
ファイル名の接頭辞や接尾辞に「_test」や日付をつけたりして、運用中のスタッフが触らないように注意喚起して作業をします。
テストファイルがあるだけ、ホッとします。
4.テスト環境にダウンロードして修正・テスト
本番サーバからテストサーバや、場合によっては開発者のPCにダウンロードして修正・テストをして、問題がなければ、FileMaker Data Migration Toolを使ってマイグレーションをして本番サーバに新ファイルをアップします。
この環境であれば、とても安心して修正・テストが行えます。
しかし、マイグレーションツールはコマンドラインで行うので、技術者でなくても開発できてしまうFileMakerユーザには少し敷居が高いかも知れません。
本当はこうなっていると安心して修正・テストができるのよ
クライアントの環境によっては、ベストな修正・テスト環境ができるわけではないのは重々承知ですが、やはり開発する側としては、本番環境に依存せず、影響せず、な環境でテストをしたいわけです。
また、テストのバージョン管理もしたいですが、FileMaker専用のバージョン管理は今までなかったように思います。
最近、その風穴をあけるDevinというバージョン管理、デプロイ自動化、回帰テストができるツールが登場しました。
引用：https://kotovuki.co.jp/service/devin
こちらは、とても期待しています。
テストサーバを立てる必要はありますが、先の4の環境をさらに強化した、FileMakerのテスト環境のオールインワン（とまでいけるかはまだわかりませんが）ができる気がします。
どんなテスト環境でもいいのですが、できれば安心してFileMakerのファイルを修正・テストをしていきたいのは、FileMakerに携わっているすべての人が思っていることではないでしょうか？
ローコード開発が可能なFileMakerでもこうしたツールを使って安心安全なテスト環境で作業をしていきませんか？