1 返信 最新の回答 日時: Dec 17, 2013 11:28 AM ユーザー:ねこ吉

    運用開始後の修正部分の更新(バージョンアップ)方法について

    株式会社アネビー

      タイトル

      運用開始後の修正部分の更新(バージョンアップ)方法について

      フォーラムに投稿

           FileMaker12 ProAdvecce/Server を使用しています。

           1月よりテスト稼働で運用開始を予定していますが、
           運用開始後に
           1.レイアウト関連の変更・追加・削除
           2.スクリプト変更(不具合、機能改善)
           3.DBレイアウトの変更
           等が発生した場合、

           今までの経験(FileMakerではありません)ですと、
           テスト環境で動作確認後その内容(該当するもの)を本番動作環境にアップしてきました。

           FileMkaerの場合、DB設定/スクリプト/レイアウト等が一つのプロジェクトに収まっているように思います。
           そのような場合の機能改善・不具合等によるバージョンアップはどうして運用しているのでしょうか?
           また、テスト環境は皆様どのようにしているのでしょうか?
           DBのレイアウトが変更になる場合の運用についても教えていただきたく。

           以上、お忙しいところ申し訳けございませんがよろしくお願い致します

        • 1. Re: 運用開始後の修正部分の更新(バージョンアップ)方法について
          ねこ吉

               自分は FileMaker はインハウスで開発しかしたことがないのですが、だいたい2パターンでやってました。

               (1)  オペレータが戸惑わないような微修正やバグフィックスは、メールやメッセンジャーで通達を出しておき、

                業務時間内に反映していました。オペレータがオンラインで作業している最中でも、あまり気にせずアップデート

                してました。(本当はよくないのでしょうが、その度に休出や深夜残業もしていられないので。なおクライアントが

                オンラインのまま機能やレイアウトを変更するのは、FileMakerの機能としては可能です。)

               (2) 操作が変わったり、複雑な機能で入念な検査が必要な場合は、コピーしたデータベースで開発とデバッグを行い、

                業務時間外にファイルを入れ替えます。入れ替えの手順は、

                (i) ローカルマシン上で新DBのデバッグを終わらせておく。

                (ii) FMServer を停止し、オペレータがそれ以上レコードを更新できないようにする。

                (iii) ホストマシンのファイル(旧DBとします)をローカルマシンにコピー。

                (iv) ローカルマシン上で新DBの全レコードを削除。

                (v) 新DBに、旧DBのデータをインポート。

                (vi)(必要に応じて、) 新DBの「次のシリアル値」などを設定。

                (vii) 新DBをホストマシンにコピー。

                (viii) FMServer を再開。

               という流れです。

               レコード全削除、インポート、次のシリアル値設定などはスクリプトを作っておくと手作業によるミスを防げます。