Options
  • State Suggested Answer
  • Locked Locked
  • Replies 2 replies
  • Answers 2 answers
  • Subscribers 8 subscribers
  • Views 730 views
  • Users 0 members are here
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Using a development vault

cjtrevor

Hi All,

We have always had the difficulty of doing new development directly in the production vault as we have not been able to find an easy way to migrate changes from a "development" vault to a live one.

Has anyone found an efficient way to manage this or is structure export/import the only way to use this development strategy?

Chris

Parents
  • 0

    Hi there,

    I have a quite a few vaults I maintain. 4 on cloud and 3 on-premise. They are all in sync. I do a lot of export/import but I am only focused on deltas (only parts changed) as new features arise. I never export/import the whole vault as it can bring side effects and problems are hard to find. I also generally develop on our development platform, move it to stable dev environment, then test and afterwards prod. So there is much testing and verifications between it comes on prod. It takes some time and discipline but it helps a lot to keep everything in sync and stable.

    I would never recommend developing on prod (even changing some significant configuration there). The only thing I've sometimes did, is creating additional views first on prod and bringing them back on other environments.

    You can however automate export/import through scheduled jobs but I personally don't tend to do this as manual imports are part of "deployment" and could be nicely reviewed with M-Files report.

    Best,

    Dejan

Reply
  • 0

    Hi there,

    I have a quite a few vaults I maintain. 4 on cloud and 3 on-premise. They are all in sync. I do a lot of export/import but I am only focused on deltas (only parts changed) as new features arise. I never export/import the whole vault as it can bring side effects and problems are hard to find. I also generally develop on our development platform, move it to stable dev environment, then test and afterwards prod. So there is much testing and verifications between it comes on prod. It takes some time and discipline but it helps a lot to keep everything in sync and stable.

    I would never recommend developing on prod (even changing some significant configuration there). The only thing I've sometimes did, is creating additional views first on prod and bringing them back on other environments.

    You can however automate export/import through scheduled jobs but I personally don't tend to do this as manual imports are part of "deployment" and could be nicely reviewed with M-Files report.

    Best,

    Dejan

Children
No Data




              

© M-Files Corporation 2024 | Privacy Policy