The goal of this thread is to propose a base design for a new module enabling a user to exchange content, assets and modules between two Orchard tenants, local or distant. Some effort has already been done by Damien Clarke, and this proposal is
here in order to extend what he already did and make it more extensible. Feel free to approve or complete this proposal.
Deployment plans are created in order to aggregate the logics that will comprise all the contents, assets and modules which have to be pushed to another instance. Deployment plans are created in the Admin UI by configuring specific aggregators.
Deployment plans can be scheduled to be executed at a specific time, or repeatedly.
The result of a deployment plan execution is called a deployment package, and will probably be a Nuget package under the hood.
These are some features defining how to grab contents, assets and modules. The result of their execution will be integrated in a given deployment plan. It is extensible as any developer might have different requirements to retrieve the elements of deployment
Examples of implementations:
Would let a user select which content items have to be included in a plan, using a content picker. Would also provide a part to let attach a specific content item to a bundle.
Include the result of a query to a plan. For instance, all content which have been modified since last week, or since last successful deployment of a specific plan.
Select which files to include in the plan.
Select which modules to include in the plan. It can also include themes as themes are modules. It could also be separate in order not to add any confusion.
Adds specific metadata information to the plan, for instance to update content types on the target environment.
If enabled on the other instance, can define which files have to be updated and add them to the plan.
Services are responsible for pushing and pulling deployment packages. Services have to be extensible and configurable as they will provide specific ways of communication between environments.
Examples of implementations:
Uses WebAPI via HTTP ports to push data to an environment. It will require secured authentication via private key, and the system to have known HTTP endpoints. It can represent a security threat/concern for production environment. This is a PUSH service, as
the initial environment will initiate the deployment.
Uses a GIT repository to store temporarily the deployment package, so that different target environment can pull it. This is a PULL service as the target environments have to poll the GIT repository. Optionally they can receive a HTTP signal letting them know
a package is available.
The same logic can be replicated for any kind of storage.
This technique is more secure than the REST service as both the source and the target environments will connect to the repository, and don't need any ingoing port to be open.
Processors will behave as filters on a package, letting a user add custom post processing logic to a package, for instance resolving dependencies, validating a package, reorganizing, …
Other scenarios enabled:
- Syncing two instances by setting up reverse deployment plans. Can even sync two tenants, one being used for admin and the other for front end website only.
- Deploying content after a user approves a content using the Workflows module