I am learning Designer and Sharepoint. What is the recommended way to use source control when making a Sharepoint internet site. I am used to having a sandbox locally, then making and editing files, then pushing out to a server, but this does not seem to be the case for Sharepoint?
+1
A:
Designer is very dangerous and most sysadmins will just block access on the SharePoint farm. Since Designer is accessing the live farm, and one could, in theory, blow a site out of the water, it's usually denied access. (In other words, there really isn't 'source control' with this model. It's akin to editing a live web site on the server via FrontPage.)
On a more advanced level, it's recommended that you use Visual Studio to create Solutions that are then migrated from your local SharePoint (for dev) to a staging farm (for testing) and then production. The trick there is keeping all 3 environments in relative sync.
DA
2010-03-01 16:18:15
i agree, what then is the recommended way to develop in Sharpeoint?
bmw0128
2010-03-01 16:22:44
is it a good idea to develop locally on a local Sharepoint install then somehow transfer the pages to production, if so, how would source control be used?
bmw0128
2010-03-01 16:24:08
Sorry @bmw0128 I think I was editing my answer when you posted. I added a few more details. (I've decided SharePoint is useful out of the box but not so useful once advanced customization is required. It's just too much overhead, IMHO)
DA
2010-03-01 16:24:09
thanks...can you get me started on the best way to migrate to the various Sharepoint installations, for instance, say I make an edit on a page, and i need to get it to production, what is the best practice to do so?
bmw0128
2010-03-01 16:40:14
what kind of change are we talking about? If it's functionality, then you want to use Solutions and Features. If it's content, then you want to use MOSS's CMS features along with workflow.
DA
2010-03-01 17:15:06
say i make an internet site, and it has a few static pages. I make them in VSS, how do I upload them to Sahrepoint? Similarly, when the pages are in production, and make an edit to one page, how to I get the edit (the new page) to production, is that clearer?
bmw0128
2010-03-01 17:34:30
@bmw0128 SharePoint is a whole group of technologies and server applications. You don't upload static pages to SharePoint. You can build pages using SharePoint's web interface (be it a team site in WSS or something like a CMS site in MOSS). If you're building static pages, then there's no real need for SharePoint. If you're building content-rich sites and want to use SharePoint, then you should use MOSS's CMS features in which case you do everything via the web interface on the MOSS site (and utilize versioning and workflow functionality).
DA
2010-03-01 19:18:18
@bmw0128 on the other hand, if you are trying to leverage SharePoint's document management and content management and expose that content in your own custom interfaces, then you are basically doing custom SharePoint Development, in which case you use the multi-server model and Features and Solutions (note that 'Features' and 'Solutions' are not generic terms, but rather very specific types of code development, packaging and deployment in the context of SharePoint.)
DA
2010-03-01 19:19:52
(as you can see SharePoint is a gigantic Costco sized can of worms. The key to succesful SharePoint deployment is: 1) Governance 2) training 3) Governance 4) training and then 5) more training and governance. ;o)
DA
2010-03-01 19:20:57
thanks again...if i may see if i get it...one builds pages and functions directly on the Sharepoint server, so there is no concept of local development then migrating to a production server?
bmw0128
2010-03-01 21:24:50
@bmw0128 it's much more complex than that. You may be building pages on the server (via MOSS's CMS, for instance, if that is the version of SharePoint you have). However, if you are developing SharePoint Features and Solutions in visual studio, then you need to use the Local/Staging/Production migration along with manifest documents and rollback safeguards. It all really depends on what, specifically, you mean by 'page' as that can mean many things in the world of SharePoint.
DA
2010-03-01 23:29:01
If you could, give us an example scenario of the type of page you want to build...what is on it, what it does, etc. That can help narrow down the type of tools and publishing model you'll need.
DA
2010-03-01 23:29:56
how about this...I have a local Sharepoint install, Enterprise Edition. I make a site, using the Publishing Portal template. I make a bunch of changes, to get my brand looking good. Now I want to get the work into production on that server's Sharepoint installation. What is the standard way to do this?
bmw0128
2010-03-02 00:23:18
If you've built the site via the web interface, then one option might be to back up the site to file, then import that site onto the production server. Another option would be to build it on the production server, keeping access locked until you are ready to release it. If you are building custom sharepoint components via asp.net and visual studio, then that's when you need to dive into Features and Solutions which is more complicated. I don't THINK that's what you are doing, though, so probably don't need to worry about that.
DA
2010-03-02 16:12:03
actually, i am currently reading up on Features, and i think i'm getting what that means. Hopefully I learn how I get a Feature that I develop into production from my local dev.
bmw0128
2010-03-02 18:08:35
Yea, MS deciding to use the terms 'Features' and 'Solutions' as very specific technical implementations for SharePoint is one of my big pet peeves. ;)
DA
2010-03-03 22:50:14
But what if there are people using Sharepoint Designer? They are working on a testing server creating workflows. The sites can be exported to WSP templates, but an opaque binary hunk is poor for version control. Is there a WSP decompiler to unpack their work so that it can be diff-ed against other versions?
JSacksteder
2010-03-24 17:47:16