Best practice for working in team of developers and deploying to staging/production servers - Front- & Back-End Development - Front- & Back-End Development - Progress Community
 Front- & Back-End Development

Best practice for working in team of developers and deploying to staging/production servers

  • Best practice for working in team of developers and deploying to staging/production servers
  • Hi,

    Myself and my developer colleague are new to Sitefinity and we're starting our first SF project next week.

    My question is: what is best practice for working in a team of developers, sharing code using source control and SF Thunder, and then deploying to staging and live servers?

    Thanks, Michael
  • Hello Michael,

    I hope the following information is useful:

    How does Sitefinity support source control

    Sitefinity's structure fully allows you to maintain a full steam development environment and manage it through source control. 

     Let me elaborate a bit further on the source control story and development process with Sitefinity:

    Sitefinity is a native ASP .NET web application and as such it supports the source control story that any other Web Application would – with TFS or any other source control system that you are using. Internally we have a very agile infrastructure and structure our entire code base and automated tests in TFS, maintaining a nightly build infrastructure etc.

    But when it comes to the question of best practices, I would probably like to take a look at a few of the Sitefinity-specific elements and features that relate to source control, as well as give you an idea of the full toolset you have at hand for this:

    • Initial setup: A general rule here would be to put everything in source control. A common exception is the dlls in the bin folder, which do not need to be versioned. While this is reasonable enough for most cases, putting the dlls(and especially the Telerik dlls) in source control might come in handy in case a developer rebuilds or cleans the solution and loses all the local copies of the dlls. (a clean deletes the dlls from the bin folder). Once the entire project is in source control, each developer can get everything mapped to their local boxes, checkout the files they need and either run Sitefinity  through Visual Studio’s Cassini server or host it on IIS locally.
    • Source control of config files: Sitefinity makes very heavy use of xml based config files internally. The application itself writes to those config files on different occasions and the entire UI is dynamically build based on those configurations. The configuration files can be found in ~/App_Data/Sitefinity/Configuration. I am mentioning this because it’s important to know this as an infrastructural specific of the system. An example of the system writing to the config files can be creating modules using the module builder, adding custom fields, adding language translations etc. Those kind of actions not only write to the config files, but often make schema changes to the database as well. A few guidelines may come out of this. Firstly – never lock or check-out your configuration folder. Changes made to these files should be checked in and version controlled, but it’s important not to restrict Sitefinity’s access to those files. Another good point to mention here is that while we are fans of TFS internally, TFS does not handle changes made outside of Visual Studio. Which means that when working on a Sitefinity website as an implementation company, any changes to the config files outside of VS are not registered in source control. This does not entirely exclude TFS as an option, but in general, partially because of this specific, our partners would prefer SVN, Git or Mercurial as those handle source control those kind of changes quite well and having version control on the config files is an important part of the Sitefinity Development lifecycle.
    • Common Database – I would say the approach of everybody working on a common database is recommended, as having local copies of the database and merging them could result in unnecessary maintenance. What could be pointed out as a best practice is regularly create schema and data SQL scripts from the SQL management studio, preferably before every commit or major Sitefinity change (like adding a new language to the Front End website or before adding custom fields) and add those to the Visual Studio project as solution items (so they'll get tucked into source control). We have heard of different approaches to this as well, from making full backups to using a maintenance plan utility. General feedback indicates however that the first approach that I described is generally preferred. Another thing to mention here, that probably hasn’t been fully tested by our partners yet, is the use of SQL Server 2012 ‘Denali’. Sitefinity officially supports Denali as of 5.0 SP1. As includes quite a few improvements and maintenance utilities, I know of a few customers who have been using this database product with Sitefinity and have been very happy about the features it provides.
    • Revision History of content changes – when creating pages and content, Sitefinity internally keeps track of all content changes, by keeping a full revision history. You can rollback and compare different versions directly through the UI, as well as control this revision history programmatically.
    • Custom development – custom development generally consist of developing controls, templates, themes, dynamic modules(built with the module builder) or custom modules(that you code yourself). In general this kind of development could be decoupled from a centralized database that you are working on. There are specific tools that Sitefinity gives you here for easy development and deployment of such custom-developed functionality(Sitefinity Thunder, import and export of modules etc. ).
    • Decoupled development - Sitefinity is also very flexible when it comes to decoupled development. Feedback from our customers indicates that they appreciate the boosted productivity when developers can work on the controls and functionality, others can work on the control designers, and UI designers can focus on the .master pages, themes and acsx templates.  That’s generally the way we also do things internally and encourage as a best practice. A good example of this is the way we develop custom controls in separate dlls and have them be based on .acsx layout templates. This is a nice touch on the classic way of developing custom controls and allows better separation of concerns.
    • Sitefinity Thunder – With Sitefinity 5 we have also released Sitefinity Thunder -  a tool that is an addition to our developer and agile story. Sitefinity Thunder a free Visual Studio extension designed to help developers to extend and customize Sitefinity inside Visual Studio. You can set your customizations up in separate, well maintained and subversioned project and push your changes to any number of Sitefinity instances. Thunder is currently supports development and deployment of themes, widgets with designers and designers for existing widgets. We are having a biweekly release cycle on the tool and very soon it’s going to support a very complete development cycle. Here is an overview of how to install and use the tool, and here you can find more information on how to create separate projects that would house your custom functionality and designs and deploy this functionality directly to Sitefinity. Here you can also find a webinar on the topic of developing custom functionality with Sitefinity Thunder that you may find very interesting.
    •  Site Sync – the site synchronization add-on can help you sync any content changes from development to staging and from staging to production. It’s a tool that you can incorporate in your day-to-day practice as well. Here you can read more documentation on the topic

    Here is another useful blog post that discusses some of the practices that our major partners put in place. You can find useful tips and tricks there that could help you with choosing an approach of tackling your internal IT infrastructure. Here I’d like to note that this blog post is pre-Thunder and pre-Site Sync, so a lot of those processes have been improved since then, and continue to be improved with each release.

    Recently we held a webinar for our partners, where we discussed options and best practices for continuous delivery. Here's a link to that.

    Grisha 'Greg' Karanikolov
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Sitefinity CMS Ideas&Feedback Portal and vote to affect the priority of the items
  • Greg,

     Thanks so much for taking the time to write this - it's very useful and has set us up nicely.

     Best regards,


  • This is an excellent resource. 

    I'm curious if there have been any recent developments or changes to Sitefinity that would change the general concepts outlined here.