0

I have created the following on my SharePoint 2013 development environment:-

  1. Created new managed path
  2. Create a new site collection of type publishing site.
  3. Create sub sites under the main site collection.
  4. Modify some page layout such EnterpriseWiki.aspx page using the SharePoint designer.
  5. Created a metadata term set.
  6. Assign the Wiki Category column to use the metadata term store.
  7. Created a Farm web part using visual studio and I have added this web part to each subsite.
  8. Assign unique permission levels to each sub site.
  9. Some other minor tasks…..

Now I has tested the SharePoint web application and I did the UAT on the development environment. and now it is the time to move the SP application from development to production server. The only differences will be the usernames and group names since on the development I used local users names for testing, while on production serve i should assign the permission levels to real username and groups.

So my question what is the best way to move the web application to production without the need to re-create or re-configure the modules again.

BR

Improve this question

2 Answers 2

Reset to default
1

Well for a start the "recommended" approach is not to perform testing on your development server. You should have a separate dedicated test environment (and preferably more than one for different types of testing).

If you truly want to go the "recommended" approach then you should make sure your entire solution is packaged up as a WSP. This should then be packaged up on your development box (or ideally from an automated build environment such as TFS) and deployed to Test / Production.

All of the activities you have described above can easily be deployed through features as custom assets through a WSP package. This will be much easier to deploy, as well as providing much more robust maintenance for future changes, bug-fixes and support.

  • Custom Site Collection template (with pre-provisioned sub-sites each with unique permissions?)
  • Custom Page Layouts
  • Custom site columns of type Taxonomy Field (Managed Metadata)
  • Web Parts
  • etc

Creating the Term Set and Managed Paths should ideally be done via PowerShell.

If you combine all of this together with some decent Build / Release / Deployment guides then you can hand all of this over to the Admin / Infrastructure teams and get them to deploy it all for you.

Improve this answer
3
  • thanks for the reply,, but none of my work was done using Powell. for example i created the term store using the central administration , and i have modified the page layout using share-point designer. my second question, can the WSP package contain all the changes at once ?
    – John Peter
    Commented Jun 10, 2013 at 9:56
  • thanks for the reply. so do u mean that i should have created the term store, custom page layout using features and power shell to be able to move them to the production server, rather than using the central administrator to do almost all the tasks? thanks..
    – John Peter
    Commented Jun 11, 2013 at 8:17
  • Basically yes. It is much more easy to repeat and test and means you can easily handover all of the deployment scripts. It also makes deployments (even to new dev environments) vastly quicker and more robust.
    – Martin Hatch
    Commented Jun 11, 2013 at 11:01
0

The Managed Metadata Service database is not tied up to the SharePoint farm it was originally created whatsoever and can be easily copied across to a different farm simply taking a SQL backup and restoring the db on the destination. A few more steps are required to make it available to the second farm which can be found on this great post from Andrew Connell

Improve this answer
1

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.