If you're lucky, there's GP 2010, 2013, and 2015. Visual Studio 2010, 2013, and 2015. If you aren't lucky, you've still got GP 10, or earlier.
Plus there's Analytical Accounting, Project Accounting, Manufacturing, and other lesser used modules, which are hassles unto themselves.
Then there are those clients with rather involved environments or third party modules or web services that are dependencies for your development.
How do you manage the many environments required to be a Dynamics GP developer for many customers?
When I first started using Hyper-V, I believe had one general purpose GP 10 development VM. I would then build a separate dedicated VM for some customers. Building customer specific VMs gets old pretty quick. It takes up quite a bit of disk space, and if they aren't frequently used or dormant for a year or more at a time, they become an administrative hassle.
I've now streamlined my VMs a bit and have what seems like a more manageable VM setup, but it isn't perfect. I now have a total of 19 VMs setup on my server, but fortunately I only typically use 9 or 10 of them.
My primary VMs are:
GP2010 - Primarily VS 2010
GP2013 - Primarily VS 2013
GP2015 - Currently VS 2013, but hope to start using VS 2015 soon
GPPA - For Project Accounting, with GP 2010, 2013, and 2015 all installed in separate SQL instances
GPAA - For Analytical Accounting, with GP 2010, 2013, and 2015 all installed in separate SQL instances
I still have a few client-specific VMs. One client used Project Accounting, but I just transferred that code to my GPPA server. It's very difficult to test customizations and integrations without the client's database, but so far it has been managable.
The other client specific VM has a pretty elaborate HR + Payroll setup in GP. I could potentially migrate that one as well, but will probably wait until they upgrade to GP 2015.
While my "consolidated" VMs, one for each version of GP, generally work, there are some drawbacks.
1. It's often difficult to remember which server any given client project is on. Was it GP 2010? Or did they upgrade? Did they upgrade to 2013 or 2015? I often have to dig up my documentation on each project to see what version the customer is on.
2. Third party products are a hassle on a shared VM. For a GP 2013 customer, I have a third party product that has a dictionary, AddIns, and a web service. Sometimes I have to disable the third party products to work on other client projects, as they change or disable standard GP functionality.
3. Multiple projects on one GP instance can be a hassle. If I have 5 customizations using Modifier, but need to DAG just one, I have to make a backup of everything, strip out four of those Modifier customizations, and then DAG the single modified form. Then I eventually have to go back and reimport the other modifications. Or if I need to test something on an unmodified form, or make a new customization of the same form, I have to swap between them. It can get messy and is difficult to keep such an environment clean and organized.
4. I've been trying to dig into SBA, and given its setup requirements, I've put that on a dedicated VM so that I can have Active Directory, IIS, and all of the other pile of prerequisites that it requires present without having to mangle my other VMs or create any dependencies on other VMs.
5. Given the size of the consolidated VMs, the 16GB in my current server limits the number of VMs I can have running at once. So I regularly have to save one VM before launch another one. I'm planning on upgrading my server to 32GB, which should resolve this limitation.
There are other small annoyances, like managing different types of test data, but these are five that happened to come to mind at the moment.
I have never really looked into Diff Disks or whatever they are called now with Hyper-V. If I were a Hyper-V guru, I suppose there is some option to have a base VM and then work with the multiple diffs, but I don't know how much easier that would be to manage multiple Diffs, or if performance would be an issue.
Anyway, I'm curious if anyone has any tips or techniques that has made managing multiple Dynamics GP VMs for multiple customer projects more manageable or easier.
UPDATE: I was just reminded of another situation that my VMs don't currently handle: Deployment testing. A client tried to install a customization I developed, but the customization had a dependency on some SQL Server SDK DLLs. The GP workstation doesn't have SQL Server or the SDK DLLs installed, so naturally my customization doesn't work. So I now need to configure YET ANOTHER machine that has the full Dynamics GP 2015 client, but does NOT have SQL Server on it. Seems like the possibilities never end.
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics
GP Certified IT Professional in Los Angeles. He is the owner of Precipio
Services, which provides Dynamics GP integrations, customizations, and
automation solutions.
5 comments:
To handle multiple customizations for different clients, I have a separate GP folder for each (see example image). It requires managing the Set file for each one, but this way I have unique add-ins, chunks, and modifier/vba packages for each project. Just drop the Set file on the Dynamics.exe to launch.
Example : http://screencast.com/t/IVzs8znI8
Thanks Chad. Yes, good point, I could use multiple GP installs / folders. I have done that occasionally for testing, but in my recent situation, I forgot about the other client mods, used modifier to make some changes to another window, and only saw that I had multiple client mods exported by the DAG into the ModifiedForms.dll.
Now that I have active Modifier projects for two different customers, I should probably set that up.
Hi Steve,
Thanks for sharing your insights about the management of various GP versions.. I already find it a hassle when I'm doing a test upgrade on dedicated servers with 2 different versions of GP and multiple 3rd party, but at least I don't have to worry about mixing up products, as I know they are going to be used at the end by the users..
The Hyper-V VM diffs may help paritally, but only to minimize the amount of disk space used (which is already a benefit), but not the quantity of configuration you'll have to manage.. Chad's suggestion looks like a good starting point, but then again, does this means you'll to replace the entire GP program folder every time you want to work with a different customer's code ? what about managing different GP releases and their databases ?... can become quickly a nightmare.
Good luck.
Thanks Beat. Yes, I agree, the variations and permutations would seem to pose a challenge, or at least an administrative hassle, regardless of which approach is used.
I have worked with NetSuite, and even in that environment there are challenges managing customizations.
Maybe there is some system or process that could potentially better manage the mods and customizations, but I speculate it would require a fair amount of work to build some type of app to manage them. And then that app would need to be managed and maintained... Endless cycle.
Beat, I will try to answer your question about my suggestion. I do not replace the GP folder in the standard install location. I merely launch the different client copies by dragging the Set file onto the Dynamics.exe file. So every Set file is managed so it points to its own location. You also need to manage different databases so I backup and restore databases when switching between working on different client projects. I once had a colleague who kept the GP application folders separate as I suggest but then kept one set of databases per GP version. I think this can work fine if storage space or mere convenience of time is a concern, but it requires care to name things properly that might be very similar for different clients but not exactly the same.
Post a Comment