Deploying with recipes in Orchard

One feature, which we haven’t look into extensively are recipes combined with the import and export functionalities in Orchard. At the Orchard Harvest event Sipke gave a long talk about module development in Orchard, also touching the subject of recipes. Right now we use already use a recipe running SpecFlow tests, and for deployment of a new clean portal instance.

What can we do with recipes?

Recipes are XML-files. When cooked they can change the Orchard instance in quite a few ways:

• download and install modules
• download and install themes
• enable features
• define ContentTypes (for instance adding ContentParts)
• change settings of ContentParts
• change global settings
• execute commands
• import data (probably Orchard 1.7)

How do we create recipes?

There is an export function (see Import-Export-Module). After changing everything you want in the admin panel, we can simply export all the needed information into a recipe file. It is that simple.

Of course we could also create the XML file for the recipe just via text editor, assuming we know what to put into it.

When creating custom ContentParts which should be included in import and export, we have to add these methods in the corresponding Driver.

How can recipes help with deployment?

We could create a developer recipe which serves as a clean slate for developers. It could include test data, and adjust all settings for debugging and such. Recipes can now also be executed while Orchard is running – effectively applying the changes defined in the recipe.

Local to Stage and Stage to Live

Changes to the system which need to be deployed can be exported and applied to stage or live. Of course data would not be touched. This would result in incremental recipes with all the changes. Alternatively we could have one stage recipe, which would be updated appropriately. We could have one live recipe for each portal, which would have custom settings, like the theme.

Live to Stage and Live to Local

If there is a bug or another need, we could export the live or stage configuration and data to a recipe and import it easily into a local environment. There we would have all the freedom for fixing the bug. Changes to the settings and data could be reapplied to stage and live environments.

All in all I think through recipes we will be able to better change the portal installation according to our needs. Probably we will automate the process. There is a documentation to making recipes on the orchard site.