Randine

I have describe our approach below to building a new development SharePoint 2007 Infrastructure, can anyone give me some feed back/advice to this approach please make for good reading........

1 Development Environment Topology

We are using a small farm topology for our MOSS development environment. This will be configured as two separate (physical) dedicated servers; (1) web front end server (MOSS2007) and (2) SQL Server (SQL2005). This topology will run in a dedicated domain (e.g. ¡®OffDev¡¯), with trusts to our main company domain (i.e. to allow designated users to access the domain as required).

Each physical host server will be configured to run a VM using Virtual Server. For example the web front end will host a single MOSS 2007 VM; the database server will host a SQL 2005 VM and a domain controller VM. In this way it gives us the ability to move virtualized machines (if required to do so).

VM¡¯s will be backed up on a regular basis, with weekly copies being kept in a fire proof safe.

2 Development Model

It is our intention to use the web front end to create and manage ¡°development projects¡±. Each development project will comprise a dedicated SSP and corresponding web application and mysite collection (as appropriate)

In an environment which comprises multiple developers (e.g. web designer, software developer(s) etc) we need to have a way of ensuring that we can maintain a central development project that reflects all of the current development activities.

The objective is not to develop against a central development project directly on the server. We intend to make developers take a copy of the central development project and work on it locally. This will be done by taking a copy of the appropriate database(es) using SQL Server¡¯s detach/attach. The copied database(es) will then be associated with their local development project. Developers will also be required to complete any further configuration (such as installation of Webparts) to prepare their environment for development.

After a developer has completed their software changes, the ¡°change¡± will then be deployed back to the central development project. This deployment will be done by MOSS2007 administrators who will take the developers components and deploy them against the appropriate development project. These components will include documentation which will be required to describe the detailed steps required to install and configure the components.

Before updating any central development project the VM will be backed up to provide a restore point in the event that the deployment fails. In the event of a failed deployment the ¡°change¡± will be rejected until the issue(s) associated with its installation have been resolved.

There are scenarios where this approach may fall down ¨C and these may need to be dealt with by exception. For example if a development project requires a developer to make a large number of changes to a web application we may chose to merely replace the content database.

We also intend to prepare a number of development VM¡¯s that are preconfigured to allow individual to establish a development environment more quickly. This will result in several VM¡¯s prepared to different states of readiness.

3 Configuration Management

It is out intention to use a collaboration site for all developers. The idea is that each project will be made up of a number of tasks, and all changes are associated with tasks. When a task is completed, a developer will be required to complete a deployment record for each (and every) releases back into the central development project. Therefore ALL changes to a central development project must be fully documented and include all components that are required to complete the change. In this way we are able to maintain a full audit trail of what is required to build a site ¨C making it more realistic to successfully deploy a production solution.

Bespoke software development will use an appropriate configuration management tool (e.g. source safe or TFS) to ensure that source code (such as Webparts) can be maintained independently of this model.

Software development for components that are not done using Visual Studio .NET will be maintained in the central development project.

4 Production Deployment

An initial production deployment will be use a content database, and all the additional steps that are required to complete the deployment/configuration (e.g. Webparts). These steps will have been captured as software updates have been applied to a central ¡°development project¡± ¨C in theory making it easier to ensure that ALL of the steps required to deploy and configure the site exist.

Once a site has gone into production we will need to maintain a model that allows us to incremental releases. Incremental deployments will be done using the built in SharePoint features for export/import.




Re: SharePoint - Setup, Upgrade, Administration and Operation Development Approach

DJ Lordee

Hi,

Interesting since I'm also looking at the same thing. Some questions toward your approach. You mention having one SSP per development project. What is the rationale behind it Isn't it too much since the idea of SSP is shareability

If I'm understanding correctly, it also seems that a development project is almost a site collection by itself since it has its own database and the developer(s) will work at this level. I'm just wondering how you'll be able to manage the deployment of these elements back into a stable environment. I'm also wondering how big this can be over time.

In our case, VM usage will be limited to developers for initial unit development/testing and for lab environments. When a solution is ready for functional testing, it will be migrate to a physical development farm and up to the prod farm at the end of the cycle. We are still working to finalize the model and I'll share our findings once done.

Thanks for the ideas,

DJ Lordee





Re: SharePoint - Setup, Upgrade, Administration and Operation Development Approach

Matt78

Very interesting reading. We too, are taking a similar approach in that we want to separate out the development from the testing and production environments.

The structure we have in place is:
Development (mainly VM's which are a replica of the production environment. Developers use this to build the solution and conduct their own tests)
Testing (replica of the production environment which is separate site collection on same physical machine as production. Used for UAT and integration testing)
Production (live environment)

The issue we are having is how to deploy the particular solution(s) between environments, e.g. dev -> test -> live. We've tried various methods: site templates, stsadm import/export and Features. All with their own problems.

The method we would like to use is the Features method: packaging the entire developed creation in a solution file (.wsp) which can be deployed to a MOSS 2007 environment and activated/deactivated. How do you get a 'no-code' solution into Visual Studio in order to create the .wsp file We've tried the SharePoint Solution Generator but it is still in beta (very unstable) and is documented not to work with publishing sites yet.

How do you propose to move the solution created by developers to other environments





Re: SharePoint - Setup, Upgrade, Administration and Operation Development Approach

Randine

I have introduced the policy within our department for all developers to provide deployment instructions to the deployment team (Myself). We then test the deployment documentation in the test environment, then to live etc after aproval within our collaboration team site. Can be very time consuming and we are still looking into using Features method, but we are about a month away before we acheive any serious results.