MODX Staff
Not out of whack at all; these are problems we are working on, and yes, the intention is for Transport Packages to help ease the pain in this area, though there is still some work to do to make this a seamless process (for instance I’m working on a new Vehicle class that will allow packages to be imbedded in other packages).
Is this where Transport Packages come in? For all files/data? I.e. moving site development from 1.2->1.3, as well as upgrading the core (or plugins) itself?
Does this mean before deploy we need to create our own Transport Package? I.e. checkin to SVN so we have a stable version, then use our transport script to checkout from SVN, build Transport Package, (deploy package to internal Provider?), then manually deploy via target instances’ Manager?
Sorry if these questions are out of whack, I’m new
MODX Staff
There are three main problems:
- What are the biggest problems faced when merging sites (website 1.2 >> website 1.3, core 2.1 >> website 1.3 (core 2.0), etc.)?
- What do you recommend I work on in this area as as a newbie to MODx? Should I be trying to build my own Transport Packages (docs) for upgrading an entire site?
- What deploy method do you currently recommend for upgrading Revolution sites as it stands now (2.0.0-beta-3)?
IMHO, getting the data integrity/merging right across instances is the most important thing. I don’t mind creating lengthy scripts as long as they end up robust, repeatable and transportable.
This is a good idea, but at the moment we are slaves to the MySQL auto_increment primary key columns. I’m considering changing this functionality, starting with support at the xPDO level in the future, switching to using UUID/GUID primary keys that would be unique across deployments, but this comes with it’s own problems and limitations for developers we are working through. Your idea is interesting, but would not work with the current database architecture, again, due to the nature of auto_increment columns in MySQL that have no awareness of keys in other tables. It is likely this will require some major core refactoring to achieve, no matter the course of action we take, but I expect to solve this in time for the 2.1 release.
Based on the threads I’ve read so far (this and this) merging the databases seems to be the trickiest part. I.e. new development content (snippets, TV, etc.) plus production content (blogs, etc.) that is not in development. I had one idea for this...
How about a central service for assigning unique content identifiers? Kind of like a dhcp/ldap service. I believe database content has unique identifiers (doc id’s etc.) and so the issue is new doc on production (ID11, some blog item) conflicts with new doc on development (ID11, container for new section). But if all instances used a centralized repository for assigning ID’s then new content requests would be unique across all instances...
Production >> new blog item >> request ID from repository >>ID11
Development >> new document container >> request ID from repository >> ID12
This way content could be merged that doesn’t conflict. So you could deploy development to staging/production and even production back to development/staging because all unique content has unique identifiers across all instances. Does this seem worth looking at? It would be tricky with remote production servers, but with web services not impossible. The repository could even sit as a service in production and development machines just call on it. All this could be optional as extensions/plug ins so people can use as is, or adopt a central repository approach for managing content across several instances. This is something I don’t mind digging deep into because I think it’s critical to get upgrading websites safe and predictable.