10

We have a weird requirement today to have the Same Environment for SharePoint Development and Production.

What could be the potential disadvantages to having such an environment?

Improve this question

5 Answers 5

Reset to default
12

I think you should turn the question around. What would be the advantages?

Sure, less licenses, less hardware, only the requirement to patch a single farm etc.

But the real problem will be patching - What if the patch actually breaks something? Patches causes downtime as well as all the services in SharePoint are paused while the patch is being applied/installed. (If you don't have a clustered environment running SharePoint 2016).

That's lucky that we applied the patches for testing to our test/dev environment first so it did not break our production env.. wait a second!

And I can hardly see something beneficial when it come's to server side development.

Each time you are debugging a SharePoint Solution, Visual Studio deploys the solution to the farm and causes an IIS-reset. Wan't happy users? Try to have minimal downtime in your production environment and don't deploy solutions/patches during business hours.

Even testing out a custom solution or evaluate any kind of third party products in a shared production environment is a really bad idea. Anything can happen, and when the damage is done it could be massive and expensive.

Can you afford downtime for an hour? A day? A week? Do you have regular backups that are tested out?

The list goes on, but i think that this should give you an idea. The reasons for having multiple farms is to minimal the risks that could have an impact your business.

Improve this answer
10

It depends on what you mean by "Dev". If Dev = environment to support testing code based, full trust solutions, then this is a disaster. If dev = environment to support admins in testing patches, restores, server level features, etc., then this is a disaster.

But, if dev = an environment for users to test out creating libraries and workflows, then this is fine. Users need sites to try out new things, aside from their production sites, and there are few benefits for having an entirely separate farm for this. For this scenario, all that might be needed is a separate site collection.

Improve this answer
8

I think it's not a good choice. Problems I see:

  • If you develop components that are installed in the folder LAYOUTS how to test new versions?
  • How to test a services pack or hotfix before installing it in production?
  • If you had to test a restore before in production how would you do it?
  • IISReset, Timer service, jobs, etc ...

It seems to me that sooner or later, you will face a difficult problem solving or a dead end. I do not see it as recommendable.

Improve this answer
4

Christopher perfect explaination and let me add, you can break the entire farm down by messing up a deployment of any package. However you can deploy custom code through SharePoint apps. What about continuous integration? How are you going get end users testing?

Improve this answer
4

This seems to be a forced requirement, and others have stated as well you have real hard time maintaining this environment specifically while applying patches and CU's. Also does not make any sense to have both on same farm, application life cycle will have no meaning at all. Not recommended

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.