Quote from: OpenGeek at Oct 19, 2009, 12:37 AMLogging all the changes made in one deployment and synchronizing them with a production environment via Subversion (for example) will not work in many scenarios, either because during development you tend to "try out" a lot of things that will not go into the end product, and/or because production data is being changed directly in production while development is going on.
It’s true the fact that data is being changed directly in production while development is going on; just as an example, I can think to news or blog post being published by the client on a site, or a web designer different from the php coders who independently updates the template whenever he feels to, or several php coders, etc.
But concurrent development on files can be managed by traditional version control tools, as long as the sfs-RDM is an option, because it’s all a matter of filesystem stuff.
We already develop in team on MODx with a "document-id independent" approach, and with a file-based documents approach, to minimize the efforts in synchronizing our environments, and the development and production environments. But a lot of manual work is still in front of us when we have to move our work from dev to prod.
Besides, even if (in Evolution) we use documents to store calls to snippets that load stuff from files as often suggested on this regard, we would like to better use the caching features of MODx, with the "real" content stored into the db: so my sfs-RDM proposal takes this into account, where I want that
the filesystem is just "an alternative frontend", but still staying within the rails of MODx, which is designed with real contents copy/pasted into the manager UI fields to be saved in the database.
Quote from: OpenGeek at Oct 19, 2009, 12:37 AMI think being able to manage promotion of specific changes though a combination of Registry-based audit logs and Transport Packages, which can contain scripted logic where needed to validate dependencies or resolve conflicts, is going to be the best solution for the widest number of scenarios. And, we can start the work of making this manageable without developer intervention after we identify and work through the specifics of the solution as developers.
We already "promote" stuff on production by manually and carefully overwriting the right files in filesystem, and doing the right updates within the manager UI. Of course I agree that a tool allowing for selective promotion of detected changes would be very useful.
But this would be an evolution: the core thing, imho is the check on editedon audit fields on db and timestamps of files to see what needs evaluation. If the evaluation is automatic, it’s done by the extension itself and the rule should be to promote the fresh.
And yes if we want to look further, also a manual promotion tool could be implemented with this approach, e.g. a "manual" setting in the sfs-RDM extension, with a module in manager where we can browse the pending changes detected and selectively include/exclude those we want from promotion. But I say, better to have the "little thing", and then eventually build on it.
Unfortunately I still can’t see how this could be done with the MODx Registry instead of audit fields, so if you have followed my posts and understand what I’m describing, I’d like to support the Registry cause and forget the db/sfs date checks, since it wouldn’t require to wait for 2.1 to have someone good jumping in and starting coding, but really I have a problem in imagining how the Registry thing could be useful for this one (maybe I need a simple example, or better a scheme like the one I wrote in a
post above).
