views:

776

answers:

4

My company have used external companies for all software development and infrastructure but now we want to move it inhouse. The company uses Microsoft products where applicable to standardize the enviroment. Sharepoint will be used as a portal to all tools needed by management, sales personal etc. Sharepoint runs on one server and our databases on another. They are both located abroud. Now to the question:

How can I setup a good environment for developing and testing our software. i.e. customized Web Parts, integration of externally located web sevices etc?

How would a good development / test server be equipped (hardware and software)?

Is it better to buy a powerful server or better equipped workstations running virtual copies of our servers?

How have your companies solved it, and what would you change in your setup?

With regards Marcus

+11  A: 

I personally use and recommend a virtual machine with everything on it including SQL Server, MOSS 2007 and Visual Studio. Every developer in a team should have their own copy of it. A good laptop computer with enough memory can indeed host such a virtual machine - but I prefer having a high-end server in a server room hosting it as this simply rocks. For development, you just remote desktop to the virtual server.

Eli Robillard has a good blog post on configuring a development server.

Lars Fastrup
The link was very useful. Thank you.
Marcus Lindholm
+1 we have the same setup. It works pretty well.
Rex M
I've read a lot of negative comments about lag when developing remotely. Do you have any input about similar experiences?
Marcus Lindholm
My hosting provider is in the same building as my office and in the same city as my hometown in Denmark. From both places I experience no noticeable lag whatsoever - developing feels like it's local. But if the server is far away in another country there will of course be some lag. Another thing: Having a co-hosted server does of course also come at an added cost per month. Prof. hosting of my 1U rack server is an expense of about $125/month for my company.
Lars Fastrup
+5  A: 

In addition to what Lars says I also recommend that you setup the following environments

  1. Build - Use Continous Integration to compile your applications on a set schedule. I also recommend that you run Unit Tests and Smoke Tests as part of your build process to keep your build at a known state
  2. Integration Test - Use this as a sandbox for the development teams to make sure all of the components behave correctly. Think of this as a mini production. I recommend pushing builds to this enviornment at least once a day or if you a really up to it with every good build from the Build enviornment.
  3. QA - This is a dedicated sandbox for your QA people. Here builds should only be pushed as features are ready for QA.
  4. Pre Production / UAT - This is a dedicated sandbox for SharePoint Admins and Customers. Here the SharePoint Admins test out the deployments and customers test new features and provide final acceptance before production. This environment should be virtualized to look exactly like production.
JD
+6  A: 

I do MOSS development at the moment, and the setup I use currently consists of a single Windows Server 2008 Standard system (used to be a VM, now its a physical machine but I have no personal preference one way or the other) with:

  • Visual Studio 2008 Standard
  • WSS 3 Visual Studio Extensions for 2008 (link)
  • SmartPart templates (link)
  • Active Directory configured and setup with its own domain
  • Exchange configured and setup (very good for getting access to the customAttributes in AD profiles, which you can use to manage user data and import into SharePoint)
  • WSPBuilder (link)
  • SQL Server 2005 Standard

Hardware wise, I am fine running all of the above on a dual core 2.5Ghz system with 4GB ram - but the most important thing is that it has to be a 32bit system, that has to be stressed significantly. Your development environment must be 32bit, there is so much in SharePoint which will run fine under 64bit, but you cannot develop against it in 64bit.

I will stress that again - you must use a 32bit environment for developing.

Lastly, never assume in code a set GUID for a document library, list or other SharePoint feature - if you need something setup in a certain way, make it part of your deployment script. This way, your admin overhead for maintaining the development, UAT and production environments is reduced drastically.

The only thing I would change about my current setup is moving the SQL Server off to its own hardware, as that reduces overhead and also allows you to investigate the NTLM/Kerberos double hop issue with regard to separate services such as SQL Server Reporting Services and the Business Data Catalog.

Moo
Do you have any references/details regarding why 32-bit is required? I know there were problems with some tools but thought these were fixed?
Alex Angas
Web Part development seems to be fine, but a lot of the Microsoft supplied addons for Visual Studio will not install in a 64bit environment, and if you reference the SharePoint dlls in an ASP.Net project (for adding your own complete web pages to SharePoint for example) you will get compile time architecture mis-match errors for the SharePoint dlls, regardless of what architecture you tell VS to target for. This is solvable, but its a pain in the arse workaround.You don't lose anything by developing on a 32bit machine, its just a hell of a lot easier to do with SharePoint.
Moo
What kind of source control do you use?
Marcus Lindholm
I use GIT with the GITExtensions for Visual Studio - http://sourceforge.net/projects/gitextensions/I have in the passed used Visual Studio Team Edition however.
Moo
We recently worked on a project where our individual developer environments were Windows Server 2008 x64, with MOSS x64. We weren't using any Visual Studio add-ons, but didn't come across any of the issues that Moo mentioned, e.g. with referencing SharePoint dlls
George Durzi
@GeorgeThe issues I had involved adding additional asp.net pages to the SharePoint system, so I could add applications without having to write them as web parts (and the limitations that web parts bring).When adding a reference to Microsoft.SharePoint.dll, and building a website deployment project, you get the following error:'Could not load file or assembly 'Microsoft.SharePoint.Search, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. An attempt was made to load a program with an incorrect format.'There is a workaround...
Moo
...which involves adding the 32bit version of the dll to both your SharePoint and website projects /bin folder, but this is ugly and nasty.Also, SharePoint workflows do not work when created in 64bit VS2008. MS is aware of this, and is currently not doing anything to fix it, instead they recommend you use a 32bit system to develop on, and deploy to a 64bit server.http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=325668This is apparently fixed in VS2010.
Moo
+2  A: 

You should check out the 'Building a SharePoint Development environment' on the SharePointDevWiki.com page. Can't put link in because I'm a "new user".

Jeremy Thake
I looked at the site but I couldn't find any information relating to my question. But thanks for your tip.
Marcus Lindholm
Try http://www.sharepointdevwiki.com/display/public/Building+a+SharePoint+Development+Environment
Leah