VBO to deploy content

This would be really cool.

It's something we've been thinking about too, and is on the roadmap. The CouchDB replicator allows you to pass in a string of doc ids (UUIDs) which you want to replicate. We could have views generate that list of UUIDs then pass this into the replicator.

I'm going to close this as a duplicate for now. We seem to have a load of issues across all of the modules asking about filtering the content that gets replicated in some way.

We do plan a VBO style UI as detailed in https://marvelapp.com/11jd8hd#10008743

ok, lets leave it open for now then.

Hi Timmillwood,

A question about UI design :
Results list will be showing all the contents in present workspace or just newly added/changed content compared to target workspace?

If all content displayed: User need to select all content entries for deployment every time. If someone forgets to select any older content, will it delete that content from other target workspace?

If only newly added/changed content displayed: How can someone delete old content from target workspace?

Old content will not be deleted on deployment, we only deploy changes.
To delete content from a target workspace delete it on the current workspace, then deploy the deleted entity.

Thanks for reply !!
When can we expect release of this deploy filter?

There's no target yet.

I'm interested in possibly tackling the selection UI but I have a few questions:

Is there a plan for handling content dependencies like entity references and menu items? Does Replicate or Multiversion provide a canonical way to gather content dependencies?

Also, can you verify that the following is basically the correct approach:

1) Create a VBO action that aggregates the UUIDs of the selected content and then creates a new replication at the end
2) We feed a ReplicationTask into the replication with a UuidFilter as the filter on the task, with the list of selected UUIDs
3) Run the replication

Here is a simple workflow I imagine a lot of sites using:

1) Intent is to build a new "section" of the site
2) Author makes a bunch of content such as nodes, taxonomy terms, images and menu items
4) Editor selects all of the new content and deploys it to production.

That's the simple workflow where there is only one "staging" workspace. Have you given any thought to how this would work in a situation where there might be lots of workspaces used for different content "initiatives?" I feel like that workflow could go something like this:

1) Intent is to build a new "section" of the site
2) Author gets a new workspace
3) If he/she needs to edit existing content, someone selectively deploys that to their workspace. Otherwise, the new workspace would begin as empty.
4) Author makes a bunch of content such as nodes, taxonomy terms, images and menu items, and possibly edits existing content in their workspace that was deployed from production.
5) Editor approves content and deploys their workspace to production (this could use the same UuidFilter and just looks for everything in the new workspace).

Let me know if these assumptions are correct!

@josephdpurcell has been working a lot recently on the filtering functionality.

Firstly if you need filtering for a deployment (push replication) then chances are you have your workflow wrong. Take the analogy of git, you don't create a feature branch but then pick only specific files to merge into master, you merge the whole branch. Workspaces are designed to work in the same way. You make changes in a workspace, then merge all of them into live.

That being said the work Joe has been doing is to have some replication settings where you can choose a filter to use on deployment (push replication) and a filter to use on update (pull replication). We're hoping to get this live soon. There is no UI choosing entities, the filter is a plugin and the replication settings are a config entity, so you could create a custom module with filters defined in a custom plugin and the replication settings to use that plugin in a yaml file.

For the most part I agree with the approach in your second paragraph. Still, I think we would need some kind of UI for choosing what content to sync into a "branch" workspace. Take the example where an editor needed to make changes to one or two nodes. Without a UI, how would they be able to choose which nodes they should get workspace instances of?

Also, is there an issue where Joe is tracking his work? As is so often the case, time is of the essence for us, and I would like to be able to help where I can.

If an editor wants to make changes to one or two nodes they should create a workspace, update it from the live workspace, edit the one or two nodes, then deploy to the live workspace.

I feel like this would present a scalability issue in large, media rich sites, and there is no batch functionality that I have seen. Updating a new workspace from live would mean copying every node and all of it's assets.

Do you have any thoughts on how this would scale?

@timmillwood: On the git analogy, you can always make partial commits, so someone could be editing twenty nodes but only five of them are ready for publishing right now while the others go through additional fine tuning, just like you can do an interactive "git add" and limit which changes are ready for committing.

I think we should separate these two issues:

• Running update (which also happens during a deployment) has concerns regarding performance. Lets move this discussion into #2780827: Performance concerns with D8 branch?.
• Providing a method to limit which entities are pushed during a deployment, i.e. this issue.

Anyone agree? :)

Hey @dpolant, I've been working in #2749177: Propose UI for Replication Filters. I believe this ticket can be closed as a duplicate of it.

There is discussion of what the user workflow will be like in #2764293: What is a "Published" workspace?.

If workbench moderation states are used, I can envision a flow something like this:

• Workspace enters a "pre-deployment" state (perhaps even just draft would do) and the user sees an interface to select what content should be deployed
• After curating the content to deploy, the interface creates a ReplicationSettings config entity and sets that as the "push" replication settings on the Workspace. These settings would use a UUID filter and include all the UUIDs the user has selected as parameters to the filter.
• Workspace moves to a "published" workbench moderation state and the WorkbenchModerationSubscriber "pushes" the content from the Workspace to its upstream/parent workspace.

While this isn't the direction we are going in, the "plumbing" is there--I have written some now outdated documentation at #2750263: Add Developer Documentation for Replication Settings which I will update soon. That aside, please feel welcome to reach out to me and I would be happy to give guidance or answer any questions.

Whoops! I commented on top of other people--setting the status back to what it was since that was not my intention.

Oh! And this is for Deploy module, which doesn't have "push" or "pull" replication settings on the Workspace. Sorry for the confusion!

The same high level concept should apply for Deploy: build a UI that collects UUIDs to deploy, pass a ReplicationTask to the ReplicationInterface with those UUIDs and use the UUID filter.

Hello,

For information, I am currently developing a module that add VBO to deploy content: https://www.drupal.org/project/deploy_individual