[TYPE THE COMPANY NAME]

Team Development with

Sitecore
 Team Development with Sitecore

Table of Contents
1. Introduction.......................................................................................................................................2
2. Team Development Setup.................................................................................................................2
2.1 Single Developer Case..................................................................................................................3
2.2 Multiple Developers Case............................................................................................................4
2.2.1 Installation............................................................................................................................4
2.2.2 Typical Work Cycle................................................................................................................5
2.3 General Recommendations.........................................................................................................6
2.4 QA, Testing and Release Stages...................................................................................................6
3. Appendix............................................................................................................................................7
3.1 Using Visual Studio .Net...............................................................................................................7
3.1.1 Creating a project.................................................................................................................7
3.1.2 Add code-behind to layouts or sublayouts.............................................................................10
3.1.3 Enable IntelliSense..............................................................................................................10
 Team Development with Sitecore

1. Introduction

A team of developers is more effective in creating complex solutions faster than a single
developer. The skills of multiple developers are blended in a team to create applications that
would be difficult or impossible for a single developer to create.

Successful team development depends on:

 Allowing several developers to work with the same projects and databases
simultaneously.
 
 Coordinating the changes that are made to the same programs, layouts, or other
application elements, so that one developer's changes don't overwrite those of another
developer.
 
 Allowing developers to enhance existing application elements (for example, programs
or class libraries) without affecting the work of other developers who are currently
using these elements. [1]

The articles listed in the References section cover general approaches to and specific
practices characteristic of Team Development. Most of them can successfully be applied to
Sitecore.

However, team development with Sitecore requires some extra effort. This is connected with
the fact that the content is stored in the database, but not in files.

This article describes how to set up the development environment for Team work with
Sitecore. Please keep in mind that this is just one of the possible approaches. The solution
which suits your site best depends on a particular task and demands.

2. Team Development Setup

Below is a scheme of a sample setup for a group of 2-5 developers working on a single
Sitecore Project.

 
 Team Development with Sitecore

Development Server includes:

 Sitecore installation.
 Database.
 Source Control System (repository).

Developer’s Workstation includes:

 Sitecore Installation.
 Visual Studio installation.
 Source Control System.

All the software of the Developer Server (SQL Server, Source Control System) may also be
installed on separate servers, which would increase the reliability of the whole system.

The SQL Server may be substituted with any databases supported by Sitecore, for instance,
Firebird or Oracle.

We will consider two cases below. The first one describes a simple single developer working
cycle. The second one describes a more complex working process with multiple developers
involved.

2.1 Single Developer Case

The scheme can be simplified if there is just one developer working.

The working cycle will be as below:

1. Developer sets up Source Control System and other working environment.

2. Developer creates or changes layouts, sublayouts, and implements business logic.
3. Developer performs the “check in” operation to commit his changes to the repository
on the main server at least on a daily basis.
4. Steps 2-3 are repeated until the product is ready for testing

Then the product is delivered to the QA team. After testing the product may be returned to
the developer for bug fixing, and then steps 2-4 may be repeated.

Visual Studio Setup

Please refer to the article below for instructions on how to setup Visual Studio for working
with Sitecore:

http://sdn5.sitecore.net/Articles/API/Using%20Visual%20Studio%20,-d-,Net.aspx  
 Team Development with Sitecore

2.2 Multiple Developers Case

Test1, … TestN and Edit1,… EditN, as well as User Workstations are computers which do
not require any special software. They are just accessing corresponding servers.

This section describes a working cycle of a team consisting of more than one developer.

2.2.1 Installation

The development server should have the following components installed:

 SQL Server.
 Sitecore Installation.
 Source Control System (repository).

The developer’s workstation should have the following components installed:

 Sitecore Installation.
 Visual Studio .NET.

Developers must have the Sitecore Installation on their workstations in order to be able to
debug applications simultaneously.

2.2.2.1 Common Practice

The following practice may be implemented on a developer’s server:

Two types of Sitecore databases are created: the Clean and the Dirty one.

The Clean databases contain final versions of the content. The Sitecore installation on the
Development Server works with Clean Databases. Developers edit the Items in the Clean
database directly in the Sitecore client. The Version Control of the content is managed by
Sitecore.

Dirty databases are used by developers as a ground for testing and experiments. Local
Sitecore Installations are connected to the Dirty database.
 Team Development with Sitecore

In general, it is safer to create Items directly in the Clean database, as long as some locked
Items may be overwritten if a developer uses a package.

The Dirty database is restored from the Clean instance when needed.

Important Note: use the Dirty database for testing purposes only! The setup executed when
multiple Sitecore installations are working with the same databases may result in data loss
due to the caching issue.

Such setup allows developers to develop and debug applications simultaneously. Two
separate database sets (Clean and Dirty) provide a good testing ground and a safety for the
final content site.

Developers may also use local databases if there is no need to work with the same content in
the Dirty database.

All the source code (.aspx layouts, code behind, etc.) version control is performed by the
Source Control System.

Note: To set up the 'Dirty' databases you will need a copy of ALL seven of the Sitecore
databases.

2.2.2 Typical Work Cycle

If you are a developer, your typical work cycle may look like this:

1. Check-out the source code you need for the project from the Source Control System. Create
and modify content Items in the Dirty database on the server.

The source code version control is performed in the common way  

Continue working with the Dirty database until you’ve finished your debugging and testing
procedures. Version control cannot be implemented on the Dirty database to the full, as
long as all developers may create/modify Items programmatically at the same time.

2. Prepare the content which needs to be transferred to the Clean database. It may be
required to ask other developers not to edit the content in the Dirty database while you
prepare and test the package.

3. Check in the code (The changes should appear in the source code repository first and then
may be released to the main server).

4. Backup the Clean database.

5. Update the Clean database on the Development server using the Sitecore installation on the
server.

6. Send a broadcast note to other members of the team saying that some items were
added/modified. Point to the package you’ve created (optional).

7. Another developer may now perform actions 1 and 2 and start working locally.
 Team Development with Sitecore

2.2.2.1 Caching Issue

Sitecore V5 implements cache for reading. When several Sitecore installations point to the
same databases (Dirty databases in our case), the developers may see invalid content. This is
caused by the fact that caches (as well as sessions) are handled separately for each
installation.

Every code recompilation causes site restart, which clears the cache. Code is recompiled
quite often during the development process, that’s why the problem described above may not
show up very often. But it may be really severe when several developers install packages
simultaneously or create items programmatically.

That’s why the Clean database should only be modified with the Development server
Sitecore installation. For instance, when several packages are installed by different users
simultaneously within one Sitecore installation, package installations are queued and no
database breach occurs.

2.3 General Recommendations

The following rules are really simple; nevertheless, you should always keep them in mind.

 Regular back-up rule – create backups of databases regularly. It is also

recommended to perform a backup before any significant changes are made.
 Regular build rule – create a working build of the site.
 Always try to assign tasks so that different developers work in different areas of
Sitecore content.

When the third stage milestone is reached, integration testing should be performed. The QA
Environment server is updated with the Sitecore installation and the “clean version” of
databases from the Developers’ server.

2.4 QA, Testing and Release Stages

After the development stage is complete, all the content and the source code are transferred to
the QA server, where the code review and testing are performed. The QA server contains the
Sitecore installation and the SQL server. If needed, data may be transferred among the
Development and the QA servers using the packages.

In some cases, it may be required that Sitecore client is installed on the tester’s workstation.
For example, when frequent web.config changes are required. In such cases all other
members of the team should stop modifying the site.

After the testing process is completed, the site is transferred to the Primary CMS server.
Authors, content editors, reviewers and other members of the team may start filling the site
with content.

Later the Site can be deployed from Primary CMC to the Production Server. The staging
module can be used for the purpose.
 Team Development with Sitecore

3. Appendix

3.1 Using Visual Studio .Net

3.1.1 Creating a project

Create a Visual Studio project (this should generally be done only once for each instance of
Sitecore). 

To create the project:

1. Open Visual Studio .NET.

2. From the File menu select New Project.
3. Select the language you would like to use (Sitecore internally uses C# exclusively).
4. Select New Project in Existing Folder.

5. Enter a name for your project.  Names should not begin with numbers or contain special
characters. 
6. Enter the address of the website hosting the project, typically http://localhost in
development.
 Team Development with Sitecore

7. In Solution Explorer, press the Show All Files button.

8. Right-click on References and choose Add Reference.

9. Browse to the /bin/ folder of the project and select Sitecore.Kernel.

10. Right-click on /web.config and select Include In Project.

 Team Development with Sitecore

11. Right-click on the /xsl/ directory and select Include in Project.

12. Open the /layouts/ directory, right-click on each Layout or Sublayout and choose Include in
Project. 

Layouts typically do not contain code-behind; Sublayouts commonly contain code-behind. 

To be prompted to create a code behind, exclude a file from the project temporarily, then
add it again.
13. Optionally, open the /sitecore modules/ directory in Windows Explorer and create one or
more folders as needed.  Return to Visual Studio, refresh Solution Explorer and include these
directories in the project.
14. Right-click on the name of the project in Solution Explorer and choose Properties. 

Set Assembly Name and Default Namespace.

 Team Development with Sitecore

3.1.2 Add code-behind to layouts or sublayouts.

To add code-behind to a Layout:

1. Open the project in Microsoft® Visual Studio .NET.

2. Open Solution Explorer and navigate to the folder containing the Layout (usually /layouts).
3. If the Layout is already included in the project, right-click on it and exclude the Layout.
4. Right-click on the Layout and add it to the Project; Visual Studio will suggest that a code-
behind be created.

3.1.3 Enable IntelliSense

NOTE: The following information does not apply to Visual Studio 2005.  Microsoft
changed the file format for IntelliSense in VS 2005.  We do not currently have an
IntelliSense source for Xml Controls and Layouts for Visual Studio 2005.

Perform the following steps to enable IntelliSense in Visual Studio when editing Xml
Controls and Xml Layouts.

 Copy the following file:

/sitecore/shell/Schemas/Sitecore.xsd

from the Sitecore web root to the Visual Studio schema directory. The Visual Studio schema
directory is usually:

c:\program files\Microsoft Visual Studio .NET 2003/Common7/Packages/Schemas/xml/ 

 
 In the Xml Control or Xml Layout file, make sure the following Namespace is included:
 Team Development with Sitecore

xmlns="http://schemas.sitecore.net/Visual-Studio-Intellisense"

For example:

<?xml version="1.0" encoding="utf-8" ?>

<control xmlns="http://schemas.sitecore.net/Visual-Studio-Intellisense">
  <MyControl>
    ...