Migrations for OOTB components

Topics: Customizing Orchard, General
Jul 21, 2013 at 4:57 PM
Suppose I want to configure a number of content types (basic stuff like creatability, etc.) on a development environment and then easily deploy these changes to other environments using migrations. Is there a canonical way of achieving this? Is it simply a case of including the Orchard source in my implementation and modifying the existing modules, or is there a preferable method that doesn't affect the core framework itself?

I suppose a related question would be - is there a conventional way of referencing the core framework in its out-of-the-box state - without including the Orchard source projects in the solution - and developing additional modules on top of the framework, or is it convention to simply add bespoke modules to the framework itself?
Developer
Jul 21, 2013 at 5:12 PM
Edited Jul 21, 2013 at 5:13 PM
I'm assuming that when you say adding modules to the framework, you mean adding modules to the solution file, because you never add modules to the framework.
Modules are reusable and portable, meaning you can package a module and install it into any other Orchard instance without ever touching the core or even launching Visual Studio; all that is required is for the module to be dropped into the Modules folder.
Jul 21, 2013 at 6:33 PM
Edited Jul 21, 2013 at 6:36 PM
I should clarify - my question was more regarding the feasibility of setting up an independent web project and simply referencing the compiled Orchard source, rather than using Orchard.Web as the startup project. Or is it more typical to begin with the Orchard source and simply add modules to the existing solution?

However, my first question is my key one - is there a simple way to automate configuration without modifying existing modules? Or is the convention to simply alter existing modules to define migrations on a per-implementation basis? Or is this completely atypical and configuration generally done per-environment via the UI?
Developer
Jul 21, 2013 at 7:39 PM
Edited Jul 21, 2013 at 7:39 PM
I'm not sure I understand, but if it's just about replacing the project references with references to compiled assemblies, then you could totally do that.
Orchard.Web isn't much more than an empty web project, with of course the required global.asax, a web.config with required settings, and a couple of required references.

You most certainly can configure / define new content types without touching any module. Metadata is just data. What you could do for example is export the metadata and then import it into any installation you want. Obviously, if a content type uses a content part for which functionality is provided via a driver, the module hosting that driver must be installed and its feature enabled. Required features can be part of your recipe too. Recipes can be executed in an automated fashion as well via the Orchard.exe program.
Jul 21, 2013 at 7:41 PM
What you normally do is set up Orchard as the website, and add your own website / functionality as one or more Orchard modules. Setting your website as the parent application, and then referencing Orchard in some way, or putting Orchard as a virtual dir is not supported.

Even though it might seem weird to have Orchard be the "parent" app, it's not that bad. You can generally get by with doing this without making any modifications to the Orchard code. Your modifications would only be made to your modules. You can choose a theme or make your own to customize the look and feel of the site. Have you looked through the documentation? It sounds like you might need to take a more thorough look and then ask more questions if you still have them.

Generally this is how I set up my environment:
  1. Clone orchard repo
  2. Push the repo into a private mercurial repo (bitbucket, etc)
  3. Create a module for my site inside the orchard.web/modules folder.
  4. Create a theme (or drop in an existing one) into the orchard.web/themes folder
  5. Commit the module and theme, and push to my private repo.
  6. Set up a Migrations.cs class for my module, and any custom content types, etc go into that. This way you aren't doing anything to the orchard core or framework code itself.
To deploy changes to other environments, I just build the app from the command line (I seem to be in the minority when it comes to this, it seems like most others are using "Publish" or webdeploy, which is probably what I should do but I am already familiar with the command line method and haven't bothered learning the other way).

Then I copy the compiled package to the target environment and replace the existing code with the new package. I have that process scripted out so that all existing files/folders are backed up, then delete all except media folder and app-data folder, and then deploy the new version on top of the bare folder. The only thing left from the previously deployed version are the app_data and media folders. You want to keep those around because they have state information and contain upload media.

As for your other questions, I'm not sure what you mean by "automate configuration". Can you give examples of what you mean by configuration? Generally any settings you want to configure you can set up in your initial setup recipe. If i want to change settings I will change them occassionaly from the migrations.cs of my site's main module. I try to avoid changing anything in the Orchard core code if at all possible.
Jul 22, 2013 at 8:02 AM
Edited Jul 22, 2013 at 8:03 AM
Well, that pretty much covers it. I think something just wasn't sitting right regarding using Orchard as the "main web app," while my current CMS experience consists of publishing rendered content to a largely independent web application. I suppose I should be viewing any Orchard implementation as an extension of orchard, rather than an integration with it.