Am working to develop a release management process for our custom configuration of SCRM. We have a dev/test and prod instance, and we would like to promote from dev/test into prod in a straightforward manner Once we have 2 consistent baselines, what is the best process to promote a given configuration (which can include work in the studio, workflows, reports and custom modules) into the production environment, without compromising the data in the process? This would be akin to a SCRM upgrade, but less substantial I would think. I know you can export/import modules (good), export/import studio configurations (also good) but what about other aspects, such as custom workflows and reports? Also, what about bringing data back prod to dev, for testing purposes? Is there a similar route? I would think mysqldump/restore is NOT the way to go, as that will destroy dev changes that have not yet been promoted, which is not good.
I would advise staying away from Module loader and Studio stuff, if you can get all the work done from files (with git and git hooks that do some extra work on the database when pushing and pulling). Some installations have Studio disabled so that your users and admins don’t surprise you with changes and break your workflow.
For some things, like moving Workflows between instances, might be done with scripts or even direct SQL INSERTs.
You probably will always need to run a QR & R after deploying.
Thanks for the comments, and the links!! I really appreciate it. Why do you suggest we stay away from the Studio export and Module loader? We aren’t doing any custom coding (if at all possible) but we are heavily configuring via the Studio interface. It appears all of those are exported and imported into a new instance in a version upgradable manner, which is what I’m after. What are the downfalls?
Maybe I said it too quick, it needs to be said with greater nuance. Studio and Module Builder are fine, if you are using them for the exact purpose they were built (and it seems you are), and it suffices for your needs.
The problem starts when you go beyond what they can do, and start adding more code customizations manually, and then need to manage the whole thing. Then things can get tricky.
Since you can do everything that these tools do just by moving files around in the file system, and since moving files around is what “git” does well, my approach is normally to (try to) reduce the entire set of alterations to a system to just a set of files that can be committed to git. Note that this is not always possible, and that you need to pay attention to what’s happening in the database.
As long as you test things and understand what’s happening, I think it0s ok to do things your own way. If you come up with a practical scheme, please share it here, we can all learn from it. Thanks