4

I've a VM (#1) with installed SP 2010 and SQL Server 2008. It suites our needs in terms of load and capacity. In case of breaking down we can revert it to the snapshot.

The development process still goes on. The question is what is good approach for updating the production VM?

Variant 1:

  1. Have a copy of production VM (#2)
  2. When the iteration is finished (development->testing->fixing) and we ready to make update we swap the VMs (#1 <--> #2)
  3. Testing VM #2 becomes production and #1 becomes testing one.

" + " : We go live with fully tested solution.

" - " : Mechanism for sync up between VMs is required.

Variant 2:

  1. Develop, test and fix on the production VM

  2. Publish changes when we are ready.

" + " : We don't need mechanism for sync up between VMs

" - " : Crashes can happen more often.

Any suggestion will be appreciated.

TIA

SharePoint Adept
  • 41
  • 2

3 Answers3

3

Don't do development on your production server - it's just not worth the risk. You need to manage deployment to production using features and solution packages as Andy Burns says. This rules out Variant 2.

Variant 1 is similar to the live/preview production model. You deploy your code from your development environment to a "preview" site for testing. You can test deployed code, new content and configuration changes using this approach. If it looks okay you swap them over (e.g. by DNS). This works well in a read-only site (e.g. internet publishing). If there is a lot of r/w (e.g. collaboration site) you need to think about locking it down and synching content and so forth.

Even with the switching, you won't want to develop on either of these servers. So I would suggest Variant 1 but with a separate development environment. Content needs to be kept in synch. between live and preview; code needs to be deployed to both live and preview.

You may decide this is too much trouble and go for a single production environment and separate dev environment, with a third test environment which will be somewhat up-to-date with the live environment. You deploy your solution packages to test, and if it looks okay, deploy them in live.

Finally, I would try not to use snapshots for your production environment if you can help it (for performance reasons). You could take a copy of your production VM in case you need to roll back.

SPDoctor
  • 9,613
  • 2
  • 34
  • 60
2

Ideally you should have a production environment, a qa/staging environment and a dev. environment, as well as local machines to develop on.

If you have two servers available, I recommend that one of them is production and one staging. They should be as similiar as possible. When you develop new functionality, you should first try it out on the staging-env. (after you have tested as much as possible on your local dev. computer), and when the solution is stable you can install on the production.

I think this is the most used approach (as well as having a dev. env. in addition to this). In order for this to work, you need to synch. data from production to staging at some intervals, for instance each week.

tarjeieo
  • 2,538
  • 1
  • 27
  • 39
2

Are you talking about development, or configuration/customization with SharePoint Designer?

If you're doing development, your code should be packaged up into a Web Solution Package (.wsp). That WSP file can be deployed to whichever environments you want. It's the setup.exe of the SharePoint world!

If you're talking about configuration, or customisation with SharePoint Designer, well, moving things developed with these tools between environments is always a problem. I can't really help you; it's because of this we would normally normally use WSP developed solutions where multiple environments are involved.

Andy Burns
  • 4,949
  • 15
  • 20