Deliverable Packages

[aaronpowell]

With content-type you can import/export a single item, but it'd be better if you could have a more complex set of deliveries, something that could:

• Add multiple doc types
• Remove doc types
• Add content
• Add macros/data types/etc

I see this working a bit like Orchard Recipes, where you define multiple things to do in a single file, and then run that single file:

umbraco> deliver PackageName

[aaronpowell]

Should this leverage the Umbraco package XML or should it be something custom?

Should it even be an Umbraco package?

My preference is the single XML file (be it Umbraco's Package XML or something unique) because then it can be stored in a SCM and diffed properly, where as an Umbraco package is just a zip so it has to be stored as binary and you loose diffing.

[aaronpowell]

So I'm going to implement this is the form of a package command that you use like this:

package MyPackageName MyOtherPackageName

So it's basically an installer for "packages" which will be in the form of an XML file that contain the usual Umbraco XML. This shouldn't be confused with Umbraco packages from the package repository a separate deliverable would be used for this

[aaronpowell]

I'm also thinking that there be another deliverable, delivery, which uses a different file format that is a list of commands, eg:

package MyPackage
some-new-command
package MyOtherPackage
other-command

This delivery command could then track which .delivery files have been run so you don't rerun them.

[sitereactor]

Sounds like a reasonable approach 👍
I've started some ground work on a package installation class, which will leverage the import methods in the PackagingService to do a full package installation. Think that could be usable if you want to create an installation with a standard starterkit-type-thing.

[sitereactor]

One thing to keep in mind is that content types some times has dependencies on "foreign" DataTypes/PropertyEditors which will need to be in place in order for the content type to be imported properly.
So maybe consider adding data types as well? (As part of the content type import, or assume that data types are imported separately).

[aaronpowell]

@sitereactor Yes the plan would be a package to be able to import anything that can be imported by the PackagingService. Think the XML that you have inside the Umbraco packages already, this would be a CLI to "run" that.

There'll be obvious differences between Chauffeur packages and Umbraco packages though, things like copying files around wouldn't be handled, nor "installing" templates/views/macro scripts/etc, all of that stuff would already be in your SCM, along with your Chauffeur scripts. Also Package Actions are unlikely to work, or at least I won't make them included any time soon 😛.

[sitereactor]

I'm still not sure how to deal with Package Actions for the new installer. But guess i'll figure it out eventually or wait until they are obsoleted and replaced with something nicer 😄

[aaronpowell]

Yeah I've never used them, but I know plenty of people do use them.

I've also got an idea about how to implement and install deliverable so you could install a fresh Umbraco instance from Chauffeur, then combine it with a package deliverable sets up your doc types, data types, templates, etc.

You'd have a delivery defined like:

# 001-Initial-Setup.delivery
install
package BaseSiteStructure BaseContent

IMO that'd be sweet.

[sniffdk]

👍 that would indeed be very sweet :)

[aaronpowell]

Alright, the main part of deliverable packages I'm calling ready, it can import:

• Data Types
• Document Types
• Templates
• Macros

These four items are what I've always found the most commonly created 'custom' parts of Umbraco that you change/share across environments.

[sniffdk]

Does that include Media Types, or ?

[aaronpowell]

@sniffdk Presently no, the PackagingService of Umbraco doesn't support media types and as that's the underpinning of it I've, so I'll need to make my own. Also it's worth noting that there's no way natively in Umbraco to export media types.

I want to get #10 underway as I think that'll give a really a powerful feature 😉

[sniffdk]

Makes sense :)

[aaronpowell]

Ok so now that install is working I think that it's time to reinvestigate the viability of this.

My plan is:

• Install Umbraco database
• Create database table to track which Delivery scripts have been run
• Define a format for a Delivery
• Have Chauffeur discover all Delivery scripts
• Check if Delivery has been run signed for
• If it's not yet signed for run it
• On success track in the db that it has run

Other things that should be considered:

• Error handling: When a Delivery fails it should halt running any others and not track the current one
• Be able to force the re-running of a specific Delivery
• Check run status from CLI

[tomvanenckevort]

That approach sounds sensible to me.

[aaronpowell]

So there's 2 outstanding features, I'm going to spin them off to separate tasks I think as I plan to cut v0.3 with Deliveries all sorted shortly.

[aaronpowell]

Created separate tasks for the 'nice to have' features: #18, #19 and #20