This project is read-only.

Best strategy to setup dev environment for Orchard CMS development

Topics: Customizing Orchard
Feb 19, 2015 at 2:47 PM
For one of our requirements , we have decided to use Orchard CMS. Since I am fairly new to Orchard CMS development i have this questions. This has been asked before as well but i am not able to finalize on the right approach.

First step for developing a module in Orchard is setting up your dev environment. We are a team of 8-10 developers working in parallel to develop custom modules/themes in Orchard. For this what is the best strategy to setup the dev environment for a team. Things we are looking at :

1) Isolate the actual source code of Orchard and code for modules/themes we will be developing. 2) Easily upgrade Orchard to a newer version 3) Easier for a new developer in the team to get started with

Please note we are using TFS as source control.

Based on materials found online, people suggest using post build events or establishing symlinks to link your modules folders to modules folder inside the orchard source. Is this the right way to achieve isolation?
Feb 21, 2015 at 10:21 AM
Edited Feb 21, 2015 at 10:23 AM
When working with TFS, I found it easiest to simply store the full source code + custom modules in a single solution (as part of Orchard.sln) and commit that to a single repository with two branches: one branch holds the vanilla Orchard solution (untouched) and the other branch would be a branch off of the Orchard branch and include the custom work.
When you want to upgrade to the next Orchard version, simply checkout the Orchard branch, update the files (remove any orphans) and then merge into the other branch.

Alternatively you could host your custom modules each in their own repository (although I don't know if that actually works with TFS - it would with Git where you can have nested repositories), but you still need a place to store your solution file that references these module projects. I think there's currently no way to store multiple custom modules in a single repository separate from the Orchard repository, but that might change in the future.

I'm not a fan of post build steps and symlinks solution, but people have successfully used it. I just feel blind not having the full Orchard source at my fingertips when working on larger projects (assuming you would have your own solution that references Orchard binaries instead of project files). Keeping things simple is key IMO.

If it's an option, I'd recommend a Git source control system. It makes it easier to branch, add multiple remotes (e.g. a remote to CodePlex) and pull in changes.
Feb 23, 2015 at 3:36 AM
I'm new to Orchard as well and I was thinking to set it up the same way as the first suggestion.

The default .gitignore in Orchard excludes the App_Data directory. When working on a team we should include App_Data/Sites, right?