Yes. Two different things going on here.

1) Workflow - as we use the term - is all about content approval. This
is where many enterprise platforms like Teamsite or Reddot start (and
end). When Sandy in marketing makes a content change, someone from
compliance has to approve that, then someone from QA has to approve
that, then someone from the relevant department, etc. Any step might
roll back in different ways. Different things might trip different
workflows (these guys need to approve SEO changes, those guys need to
approve new content, etc). THAT'S what we have in late Alpha/early
Beta now and will be the heart of a new "enterprise tools for
concrete5" offering we're working on.

2) Development cycle. How do a dozen developers collaborate around
working on the site? Tools like Reddot or Teamsite tend to be local
server setups that in the end push static HTML up to the live
webserver. Since we're middleware based, we have a lot more
flexibility to easily add functionality like forms or forums to a live
site, but it also means it can be quite tricky if you have some
changes that involve both code and content. We've seen large clients
solve this challenge in a number of ways depending on the type of
thing they're doing and the way they like to work. I don't think
there's any perfect way to pull this one off. The truth is you're
always swapping parts out on a moving car at this level, and you're
always going to have to put on your thinking cap to pull that off.
What we're looking at doing now (and hope to include in a point
release after 5.6) is the ability to easily export/import parts of
your site as XML. Right now there's a couple of ways you could do
this.. The Package format lets you bundle functionality and content
together for a quick install, but it's tedious to make a package if
you're just trying to launch a new section of your website. We also
have the starting point architecture, but it really is limited to some
but not all of the data in your concrete5 database. What we've been
discussing around the office and with a client who could really
benefit from it is the idea of being able to really represent an
entire site accurately in XML and then import just parts of that. So
if you've got a new product with a couple dozen pages and some new
functionality you could work on it on a stage, get it just so, then
upload the templates with whatever you use to manage code (git and
gitflow for example) but also grab the content for that product area
from the master XML def, cut out just those nodes, and "create" those
pages darn close to instantaneously on the live site from the export
off of stage.

That what you want? Or can you imagine a better way?


best wishes

Franz Maruna
CEO - concrete5.org
http://about.me/frz

I guess that's probably as good as it will get for a system like C5, Franz.

I guess I'm showing my background a bit. I've designed a number of dev/test/qa/prod development cycle systems that allow different teams to work on their view of the overall system. In these, the core is a configuration management system (I've worked with just about all of them over the years).

The key is that each "server" checks out a "release" i.e. a particular configuration of static files and database (stored as SQL) and then instantiates the particular Web site with the appropriate data. Thus, the "QA" site can check out a load of sample data whereas the "test" checks out edge case data that can be used for testing.

The only one that doesn't check out fresh data is the production site. Instead, this checks out a set of migration scripts that migrate the production data as needed to support the new functionality.

At all times, each site can roll back to a previous release.

I think that could be done with what Franz is working on in the XML solution. Each setup wouldn't be a connected pipeline but the content can still be passed around. If this upcoming release allows for custom tools/addons to be fired during stages/events, then you could easily make it seem as one fluid system.