This is a rather general question but I'm trying to assess what best approach to take when it comes to deploying SharePoint solutions onto load balanced environments.
Let's assume we have the following:
WebServer-01 and WebServer-02
Our SharePoint installation is balanced over these two environments, but as a developer, I only have access to WebServer-01 for deployment. The assumption here is that the infrastructure guys set up a replication from 01 to 02 but did not set up a replication for configuration files.
What would be the best, out of experience, approach to replicate the configuration file to the second server, without tweaking the replication script or logging into the box?
I was thinking of creating a deployment package, for example click-once that injects the required appSettings, but this in itself is risky?
Thanks,
Eric
If you deploy everything the 'SharePoint way', as in building WSP packages, then there is no need to manually replicate settings across multiple servers in the same Farm. SharePoint takes care of it.
You may want to consider posting SharePoint related questions on sharepoint.stackexchange.com
Some further helpful tips
SharePoint Development Guidelines.
Creating a Solution Package in Windows SharePoint Services 3.0
Creating a SharePoint Solution Package (.wsp) in 5 steps
WSPBuilder.
Related
I am working with a customer which have SharePoint 2013 dev, test and prod environments sitting in a datacentre. We are moving the datacentre which means their SharePoint 2013 needs to be moved as is. They have 1 heavly custom build application on top of SharePoint which needs to be moved. I need confirmation, process suggestion on the migration part.
I install SharePoint 2013 like for like in new environment.
Option 1
I take backup for their databases and restore them on new SQL Server. Use Mount-SPContentDatabase to mount database and test if everything is working as expected
Option 2
Recreate web application, site collections, activate custom features, timer job and migrate content.
I personally think that option 1 is more applicable but need input and suggestions. Any road blockers or gotcha are also encouraged.
Thanks for sharing your experience
As its a same version migration it wont be much of an issue but go with option 1.
Re Creating the whole farm is so hard specially if you decide to deploy each and every component.
I've migrations to same version and these are the steps that i follow.
Create a checklist of all solutions and features (WSP etc).
The check list should have the same services that are running in the farm as well.
Install SharePoint in the new farm and update to the same version as the existing farm , having same version will reduce a lot of
problems.
Create the service applications just like the existing farm.
Restore the service application databases (MetaData, UserProfile etc)
Create the web application and restore the content database
Deploy the custom solutions
Confirm that everything in your checklist is deployed and working fine
Fix errors if there are any
This is the flow that i follow and so far i've been successful.
Good Luck
Previously when provisioning list, libraries, site columns, content types, list definitions etc in SharePoint I typically used SharePoint features, deployed via a WSP - or used PowerShell scripts. This meant I had a package that could be deployed to DEV / TEST / PROD.
I'm working with SharePoint within Office 365 and unsure on the best way to provision lists / libraries / features within SharePoint.
Options:
No Code Sandboxed Solutions
Trying to avoid using these as the information from Microsoft on whether they are deprecated is flaky - however sandboxed solutions would allow me to deploy features with list definitions etc. I know sandboxed solutions with c# are definitely deprecated, but the info around no code solutions is poor.
Apps
I know apps can provision at both the app and host web level, but creating lists, libraries etc using the CSOM seems like a lot of effort and a step backwards.
PowerShell
The SP Online PowerShell is nowhere near as powerful as on-prem SP. I can provision site collections through this, but not lists or libraries...
I'm keen to know how other developers are deploying to Office 365, specifically around provisioning sites with specific list definitions, libraries, content types and so on...
Thanks
Microsoft did clarify the position on No Code Sandbox solutions - http://blogs.msdn.com/b/sharepointdev/archive/2014/01/14/deprecation-of-custom-code-in-sandboxed-solutions.aspx
Also if you are looking at using Powershell to deploy then you might want to go down the route of using CSOM from within PowerShell - SharePoint Client Browser for SharePoint 2013 is good for setting up a session also very good for viewing the content of a 365 tenant - http://spcb.codeplex.com/
I have been using code based provision for almost two years without any issues at all.
Server side model works just fine, CSOM has some limitation but stil cool one and JSOM could deliver the same feature set as both CSOM and SSOM, sorta 95% :)
PowerShell is not the best option as it hard to integrate into CI, put some unit testing and regressions.
As you mentioned, this is "step back", but if only you don't have any framework or foundation for that. My libraries are internal one, but there is SPGenesis at codeplex and SPMeta2.
As community don't really care, need or with such libraries for provisioning (yep, let's face it), there are much such libraries at all, but there are lots of "MVP" samples sorta "hello world" level.
Finally, what I would suggest is to invest your time and effort in code based provision.
This is a future, that's it ;)
UPD
Struggling with SharePoint's API inconsistency, bugs, "by-design" behaviour, unaffordable amount of time to write, support and upgrade WSP packages and XML, a team of passionate SharePoint professionals decided to come up with robust, testable and repeatable way to deploy such artifacts like fields, content types, libraries, pages and many more.
Enjoy and let us know how it goes.
SPMeta2 at GitHub
SPMeta2 at Nuget
SPMeta2 Documentation Wiki
SPMeta2 Bugtracker
I am new to SharePoint, I am using SP 2010. I am asp.net developer but I don't understand if I have web.config under 80, so what are those web.config files under 14 folder, can you briefly discuss it?
I found two so far, There is one under 14\Templates\Layouts and under 14\CONFIG
Thanks
SharePoint development is similar to ASP.NET development but there are some major differences you need to be aware of. One is the use of Web.config to store application settings.
I wrote a blog post with links to several resources to help new SharePoint developers get started: Getting Started with SharePoint 2010 Development–Links and Resources
I suggest you start by watching the SharePoint for ASP.NET Developers talk to get an idea of the SharePoint architecture and development/deployment model.
You will find a lot more in 14 hive :) They are there because they are web.config files for different parts of the entire sharepoint application pages. For example the one in "14\layouts\" is for general application pages, site settings, regional settings, ... for instance. the one in the 14\layouts\admin is for centeral administration pages.
We are deploying sharepoint MOSS 2007 at our work. I'm trying to come up with a sharepoint development and deployment methodology. We have Dev/QA/Prod environments and I need a way, preferably automated to deploy changes from Dev to QA and from there to prod.
We are creating site collections web parts etc. Some of it is done directly within sharepoint, some through Sharepoint designer or visual studio. I'm looking for a way to extract this and deploy it to other enviornments.
I tried stsadm backup/restore import/export etc but they all move the data along with it as well. I just need the structure deployed. Content deployment paths and jobs does the same thing as well.
We use MSBuild & Curisecontrol.net for other .net projects to automate build/deployment process. I'm looking for something similar with sharepoint if possible.
What are your best practices for this? Since my team is learning we don't have a defined process and we are open to change our development process if needed.
First off, it's a hard problem.
Probably the 'best' method is to put everything into solution packages - but its quite hard to do correctly.
There is a lot of opinions out there - the best I can do is give you further reading
SharePoint Solution Deployment Strategies
SO - How do you deploy your SharePoint solutions?
ROSS - A commercial toolset to help with deployment
DocAve Deployment Manager
SharePoint development / deployment isn't as finely tuned as it is with regular .NET. I haven't heard of anyone using CI solutions for this.
Your basic unit of deployment is a solution package (a WSP file). It's basically a CAB file with a different extension. WSPBuilder is helpful for creating them. (http://wspbuilder.codeplex.com)
SPSource (http://spsource.codeplex.com) is pretty good for reverse engineering some stuff that you build in a web browser, such as Content Types and Lists. It's my preferred way of doing this stuff - trying to cut them by hand is no fun. I've had SPSource reverse engineer simple lists into 2000 line XML files.
Powershell is important for SPT 2010. James Kovacs has built a build tool called psake which plugs into PSH. It looks pretty straightforward, though I need to figure out PSH properly first.
Spend some time on http://sharepointdevwiki.com as this an evolving resource.
Microsoft patterns and practices group have released some guidance as well at http://msdn.microsoft.com/en-us/library/dd203468.aspx
LearnDevNow.com is also selling online training videos that are pretty good and very affordable (about USD100). They will show you many of the good ways of doing things.
Cheers
Mike
One of our product will consist of multiple SharePoint solutions. Now we're wondering what would be the best way to provide an easy deployment to our customers? At the moment we deploy each solution by hand, which is OK during development process but not acceptable for our customers.
For your information, we're using VSeWSS 1.3 for development and solution packaging.
So how do you offer your solutions to your customers? Do you write installation scripts using STSADM commands? What other options do we have?
WSPBuilder
Personally I use WSPBuilder for packaging and find it much easier to work with than VSeWSS. However if VSeWSS is working for you then that's great.
One of many the benefits I found of using WSPBuilder is that it's easy to integrate into a build system. It's just a simple, but clever, commandline tool.
Batch File
For deploying multiple SharePoint solutions to our customers I usually provide a batch file that contains the necessary STSADM command and prompts them to enter any environment specific data i.e. site collection urls etc...
SharePoint Solution Installer
There is also a nice GUI installer,called SharePoint Solution Installer, that you can use in-conjunction with SharePoint solution files. Check it out it might suit your needs.
alt text http://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=sharepointinstaller&DownloadId=18625
SAF - SharePoint Action Framework
It's worth pointing out SAF; which is an extremely comprehensive framework that can automate installation and configuration tasks, using either MSBuild, Powershell, Stsadm or a custom SharePoint feature.
We just use plain old batch/cmd files. If you need to "productize" this, just wrap up all solutions in a selfextracting rar package and have it run the batch file after unpacking.
Stick to Microsoft products. Powerbuilder is being groomed to gradually take over from STSADM for this type of task. In a farm scenario (remember, yours may have to grow over time), this would be the tool to use to push out solutions to all front-end Web servers.
EDIT:
MS are preparing a final version of VSE 1.3 to ease the migration of 2007 solutions to the 2010 environment.
Have you looked at Microsoft SharePoint Designer?
not sure if it will do all you need, but it does allow you to package sites or individual objects that you can then run on another SharePoint install.