Windows 10 Enterprise Edition: Installation and Development Environment Essentials: Thoughts & Assistance Req:

Question

Hello,
I am in the architecture planning stage of my project and seeking personal and general good advice from Mircosoft engineers.  I am laying the foundation stones of a new development product using at least three more new technologies that are
as new as Windows 10. Their are also around four or five technology partners with the latest version of their software that I wish to take onboard. Due to the sensitive nature of the project it is not wise for me to state each piece of technology used,
so I will be as accurate as possible using the limited means I have.
I wish to make a "closed" development environment, with the latest build (currently 9860), install the new software. Some of which installs fine, some of which is not compatabile with Windows 10. Regarding the latter I am in discussions with the
technology providers to make a work-around and hammer and chisel through every issue. Very soon I hope to have a fully stable working development environment which paves the road to a first prototype. So i need to make a decision soon to "lock
down" everything. I will miss Windows 10 updates but the advantage is when the project vertical slice is complete, the feedback and benefit will be larger for Windows 10 final product.
This is probably my fifth or sixth early evaluation of the Windows platform and I am aware of the highs and lows of working with various versions using new builds, from the stability of win98 (becoming 2000 - minus millennium 1999 edition), to the quick uninstall
of vista (it broke our internal projects). The solid bedrock of Windows NT (becoming XP) and so on. The good news is Windows 10 seems very good indeed.
My questions are two:
1) Would the windows team recommend a closed environment development in my situation, and are they aware of other developers doing it (is it wise from your end)? Is their a pool, can we communicate directly?
or
2) Would you recommend an open environment instead? Every install is updated, everything is all on-line and networked, this may lead to more breakages and sacrifice the finished product.
The problem with approach number 2 is that a particular technology  may work with this build, but not the next one and vice versa. I will constantly be playing "bunny hop" trying to make it work.
The problem with using number 1 is that you can have a "false dawn" view of the project, meaning you have managed to get it stable and develop code that fits that environment and build, but as soon as you do update six months later, it breaks due
to feature change, it means massive re-work, ultimately breaking the product again.
I have seen these approaches drown larger projects and wash away whole development teams.
Its a tough one and a part of my R&D but very soon I need to make a decision.
To explain more, some of the technology used will be:
Windows 10 Enterprise - Perforce - Office 365 with Exchange Activ Synch - Any associated Intel CPU and GPU monitors.
In other words very stable and solid technology. Their is about an equal number of other techs that are not so stable but I am slowly getting to work under Windows 10.All feedback would be given to Microsoft, regardless of environment 1 or 2.
Any advice and help from the Microsoft Team is greatly appreciated.
Yours Kindly,
Asad

Answer 1

I recently went to an Enterprise Mobility Summit Microsoft was holding at one of their facilities, and they spoke a bit about the future of Windows 10 - and here's what I left with: Microsoft isn't really sure themselves what kind of updating scheme they're
going to be doing with Windows 10.  They had some ideas, but they're looking for feedback from enterprises and engineers about their plan. 
I don't think it was under an NDA, so I should have no problem discussing it:  their idea was to have different tracks (based on the user) with different upgrade schedules based on what the administrator deems appropriate for that user.  For instance,
a consumer would have their OS automatically updated as soon as the update was available. while enterprises could stagger their users to a more manageable 3-month or 6-month schedule.  Microsoft wasn't sure how long to make this stagger schedule - talk
of a 1 year stagger were floated, but nothing concrete.  Critical devices, like POS or ATMs, could be setup so they would never be upgraded, or only upgraded when the administrator specifically allows them to be upgraded. 
For you personally, it sounds like a closed development environment is better, since you're testing critical business applications.  Again, one never knows exactly what direction Microsoft will take, but with the amount of conversations and...
warnings that dropped by various people at this meeting, it's pretty safe to say that they'll be some sort of timed release schedule for enterprises that you can prepare for. 
Hope that helps!