This project is read-only.

Development Lifecycle using Orchard

Topics: Customizing Orchard
Aug 25, 2012 at 1:44 PM
Edited Aug 25, 2012 at 1:44 PM

Hi Folks,

I'm looking fora bit of advice from those who have worked with Orchard for a long time. I have a team of people about to embark on a development project, and orchard is the candidate for the platform. Having played with Orchard for a couple of weeks now, it appears great as a 1 developer 1 installation" style CMS, but I'm unsure how to take it forward within a team of developers, and multiple environments. I have a few questions, and any advise on does/do nots would be much appreciated.

1) Source Control

We are using TFS internally for source control, but what exactly to source control is a different question. We want the solution to be something quick to get and immediately run from source control, even as someone who has never had the solution out before. This plus F5 debugging seems to make the best option to get a copy of the latest Orchard source down and use that as the starting point for the solution, adding in our own projects/modules as required. 

This seems to work ok, but there are two issues with this:

a) If a new version of Orchard comes out, it is less trivial to swap in the new code base (even though we are not changing any Orchard source directly, it is all modules and extensions)

b) Because Orchard is a CMS, and holds much in its database and the app_data folder (which is not generally source controlled) it is not enough for someone to get latest from source control. In fact, a new developer needs to get a copy of the code, create from an orchard recipe, then overwrite their database with a backup from elsewhere in order to have the same setup as the person who checked in. 

Please note that we are not worried about content pages, but are interested in preserving enabled features and potentially layers/widget configuration

The other option appears to be to only create a solution with your custom modules and projects. Cleaner and easier to understand, but then requires further setup for each developer or environment.

In peoples experience of Orchard, which of these (or other alternatives) works better?

2) We are uncertain of the best method for deployment to staging and live is. If we deploy modules to staging, and a content editor makes use of them to prepare exactly what they want on live, what is the best way to deploy content and configuration elements between the staging and live database? Orchard still seems to be missing a content deployment process, which leaves us attempting to write down all the things we need to do to live. This would tend to make a live deployment an involved and risky process. As the solution we are developing has paying customers 24x7, this would be problematic.

How have people tackled this problem?

Any advice/shared experience welcomed.


Many thanks,



Aug 26, 2012 at 7:54 AM

I usually work with a private clone of the Orchard repo that devs on the project can in turn re-clone. It's distributed source control, which means it works well with such topologies and it gives independence to the project. The database is of course not checked in, and we work with local restores from the prod database backups. To deploy, you can use the Import/Export module, but I would say that's a story that needs to be improved.