A lot has changed for Dynamics developers over the years. I was looking at this old post (well, 6 years old) by Gonzalo Ruiz, and I am still wondering what to make of it now:
http://gonzaloruizcrm.blogspot.com/2012/01/setting-up-your-development-environment.html
I think traditionally we had these 4 options when setting up the environments for the project (well, other than doing development directly in production, of course, which is always an option, too):
- Option 1: We can use that option described in the blog post above. Which is where there is a master configuration environment, all configuration changes are done there, and all customizations are done in the local development environments. How many environment do we need, though? Well, it’s roughly as many environments as many developers we have on the team plus a few more for QA/UAT/Production
- Option 2: Instead of that, we might use a shared development environment and use a separate environment for integration. That comes with a lot of funny problems, but, mostly, it’s all about us, Dynamics developers, having to carefully avoid each other. “Don’t touch that since I’m working on it..” – that’s what it usually sounds like
- Option 3: We can certainly do custom development in the shared development environment and drop the integration environment altogether. What we had for Option 2 is becoming even a bit more messy this time around since, yes, we now have to also figure out how to export our changes from this shared environment and bring them to the upper environment (say, QA.. or, possibly, directly to Prod?)
I guess there are some other options, too, but.. As Dynamics projects are moving to the cloud, more and more teams are facing a choice where they have to deal with a limited number of environments. Of course that’s more a problem for bigger teams than it is for the relatively small teams where it’s easier to coordinate, so, possibly, not every project is affected. But still..
Well, there is always one more option. We could be using a mix of on-premise/online environments through the dual rights licensing. That sort of defeats the purpose of going online since, out of a sudden, we need to start supporting on-premise environments for development. That creates another challenge since online version is, normally, ahead of the on-premise. Besides, not everything can be developed on-premise these days (thinking of PowerApps, Microsoft Flow, etc)
So, what is your preference? What works for you?