How should I create a good environment for .Net de

Question

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

Answer 1

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".

Answer 2

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.

Answer 3

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.

Answer 4

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.