2

I am a .Net coder new to SP.

I've set up a new SP2010 in our test environment but wonder what the best practice is for the cycle I am familiar with "dev->test->live" with SP? e.g. How can I make test changes to a site (add new lists, forms etc) and then "promote" them up to test and then live...without destroying any of the data in the live environment?

A predecessor set up SP2007 but with only the Live site and worked directly on that...is that the way to go? Sounds risky!

There is no serious coding here, just standard SP2010 features such as new sites, lists, workflows etc.

Improve this question
1
  • I up-voted your question because I'm glad you're asking it. It needs to be asked. I am, however, concerned that it does not really fit the criteria for a question ("there is no actual problem to be solved"). Could a moderator evaluate this for a community wiki?sharepoint.stackexchange.com/faq#dontask
    – Robert Kaucher
    Commented Mar 26, 2012 at 12:31

3 Answers 3

Reset to default
1

If you are working with standard features, there is very little risk to your live site.

That said, you should have a development farm (or at least a subsite on your main farm visible only to the developer if you are heavily restricted on available machines) for creating workflow heavy processes so that you can ensure each step preforms the way you need it to, and there is no odd behavior to deal with.

None of the above applies to coded solutions. If you are using code I HIGHLY recommend you have an entirely separate development server that you can crash and burn if you need to. Even the simplest functions run the risk causing errors, and substantial repeated errors could even cause an IIS application pool to stop to prevent system damage. To top things off, Global assembly cache deployments require an IIS reset, and that will take your site down while it loads back up. Definitely not something you want to do repeatedly to your live site.

Improve this answer
4
  • If you are working with standard features, there is very little risk to your live site. - Can I make changes to live and "preview" them to certain users before updating the existing page/site/list permanently?
    – BlueChippy
    Commented Mar 27, 2012 at 4:24
  • I don't remember the exact process offhand (I am the admin that does everything anyway), but the publishing infrastructure by default require approval for items, and those items will be only visible to those set with the appropriate permissions until it is approved. I am fairly sure you can configure it this way for everything, but i would test things out on your own to get a feel for exactly how it works and appears. Its always better to see things for yourself to know if its appropriate for you.
    – Zork
    Commented Mar 27, 2012 at 12:38
  • I am completely stumped now...what it seems is that there is no way to easily e.g. add a new List to a test sharepoint site and then "copy" it to a Live site? Is the basic intention that SP sites only exist in Live? All I want to do is add new pages/workflows/lists to a test site and then get the same into Live...is that too much to ask ;)
    – BlueChippy
    Commented Jun 5, 2012 at 11:09
  • are you talking about sites within the same site collection? (meaning you navigate to one address ex: http://mysharepoint and then click on the tabs to go to the specific site) or different? Most objects can be exported and include settings (but not permissions) either by copying a file or using a template.
    – Zork
    Commented Jun 6, 2012 at 15:55
0

Great question. As you develop in SharePoint, your builds roll out a nice little WSP file which can be easily deployed to Test, then to Live. (BTW each environment will need to be its own farm). Your solutions won't destroy data unless your code does it. In most cases, if you're creating workflows, lists, etc. you're updating a DLL and the XML which defines the lists.

If you deploy a list or content type in your solution, then make some significant changes to the definition file, that may break that list/content type. But this is something you should pick up in dev, and if not definitely in test. Worst case, you can roll back to a previous version of the definition file and redeploy it, and everything should work.

Make sure your test is up to date with live, I like to take a backup of live and restore into test every once in a while to ensure the data is similar, and my updates do in fact work with what's on live.

HTH

Improve this answer
6
  • Thanks...I am now a little more informed and more confused! (A little knowledge...)! Does the WSP file when deployed also make changes to the DB where necessary?
    – BlueChippy
    Commented May 10, 2012 at 6:16
  • The WSP may make changes to the content database if it's designed to do so. The admin database gets updated with the solution for management purposes. SharePoint scans the features folder in 14\templates to search for features that should be applied to the site
    – David Lozzi
    Commented May 10, 2012 at 12:33
  • 1
    Just to point out in case it was not clear, David is referring to the way coded solutions are deployed to a SharePoint environment. A WSP file is basically a few files zipped together that can be deployed (and removed) easily with central administration or Powershell depending on your preference. Code development in Visual Studio 2010 has been made very convenient to use and manage. Also as a quick side note you can develop in SharePoint Designer and create WSP files through that, though i have no experience in that regard.
    – Zork
    Commented May 10, 2012 at 13:54
  • Thanks @Zork, wrote that before my 2nd cup this morning ;)
    – David Lozzi
    Commented May 10, 2012 at 14:01
  • As you develop in SharePoint, your builds roll out a nice little WSP file...do you mean develop code in VS2010, or do you mean "add a new list" etc?
    – BlueChippy
    Commented Jun 5, 2012 at 11:11
0

There is a fairly comprehensive approach recommended by Microsoft regarding Application Lifecycle Management in SharePoint 2010. It covers the various environments and managing the artifacts (e.g. solution packages, features, etc) in the development/deployment cycle.

Improve this answer

Your Answer

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

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