Recommended workflow for maintaining sync across multiple site locations?

Quote from: shamblett at Oct 25, 2009, 04:56 PM

Trivial example of where I’m coming from a bit.

There is a bug in a core file that stops your site working as you want it, OK, not good and maybe not that usual but it happens. You JIRA it, fair enough, you identify and propose a fix on the JIRA, trial it and it works. What do you do now to fix your site, which must be fixed right now?

Hand modify the affected file on your production server, this is probably what most if not all people do now.

First off, most people don’t provide patches themselves; as a developer, you’d be identifying the bugs, fixing it in the source of the 3PC and hopefully building/publishing a new version. Most folks will simply see a new package version and run an upgrade of it, which should fix the problem, if you built and tested the upgrade of the package properly.

Bugs in the core of the framework is a completely different issue and besides the point of what we are discussing here.

Quote from: shamblett at Oct 25, 2009, 04:56 PM

How would packaging help here? Are you saying package up the whole core from your dev box and apply it on production?

Updating the source of the bug from a package. Pretty simple concept...again, this has nothing to do with core development. Bugs in the core should be identified between the developer of a 3PC and the framework developers before something is released anyway. If not, you provide a workaround in your 3PC until a new core release is provided, or you patch the core yourself and make sure we know about it in JIRA. This is pretty standard workflow between framework and component developers, no?

Quote from: shamblett at Oct 25, 2009, 04:56 PM

And I’d sure rather be able to handle dependency resolution in a script I can attach to a new version of a package...

I think this would be impossible to do, how would you write the script?. You don’t know the install environment till its installed. Then of course what if we can’t resolve? The ever perennial question, rollback, fail or what.
This again is management, not packaging as such.

Management is exactly what packages are about, so I’m not following here. It’s not impossible to test for expected pre-conditions and take actions; this is what scripting is. And if it doesn’t work, the user will be notified and can take the appropriate action (i.e. uninstall and restore previous state). I think you are trying to overcomplicate this.

Quote from: shamblett at Oct 25, 2009, 04:56 PM

If we follow the simple, reusable component philosophy when developing our packages, the patterns will emerge for automation and improvement, including how to handle dependency resolution

Yes agreed, but that’s just for us(’our’, above), 3PC’s can do what they like, package or not as they like and people can use these if and when they like. This is the real world, we can’t just assume we can automate installation and resolve dependencies just by writing smart install scripts, it won’t work. I’d rather not get into this area, if a user installs/upgrades a package that trashes several local edits he had in the package then so be it, we could help in this case by ’diffing’ the package to be installed with what’s installed, but this again is management, not packaging itself.

There’s been few threads lately where it’s been suggested that ’packaging’ can help/solve/make easier some process or other. I’m not sure it can in these cases or ever will be able to without significant effort.

And what would help without significant effort? I think you are being unnecessarily resistant to the ideas and potential we’re showing off with xPDO’s transport packaging. Saying it won’t work is non-sense; we are using it already to do upgrades of our 3PC’s in productions sites, and yes there are pitfalls, but the benefits far outweigh these in most cases. How about using it, trying it, and offering ideas for improvement rather than resistance and discouragement against the whole idea? Or at least offering alternative ideas?

How about using it, trying it, and offering ideas for improvement rather than resistance and discouragement against the whole idea? Or at least offering alternative ideas?

I do use it, I do try it, I’ve written the scripts/3PC code, for Docmanager(ported it) , for Provisioner(Ok new) and a number of template/simple widget conversions. Its fine for what it is a ’transport package’ ie move this from here to here nicely and allow me to install it. Im not trying to overcomplicate it I’m trying to say don’t overcomplicate it, by using it for processes it wasn’t intended for(IMHO anyway).

Maybe its because of this that when I see statements like ’we could use packaging for this if we just....’ I get a bit apprehensive because I just can’t see how.

The acid test of course is to do this, why don’t we issue the next upgrade to revo(beta 5, RC1 whatever) as a package thats just ’installed’ to your existing installation, then bingo, its latest, and I can uninstall it if it breaks.

Whoa, now, everyone slow down.

First off, let’s get MODx Revolution 2.0.0 out. Then we can worry about the more advanced features and workflow, and address those in 2.1.

To be honest, I think this thread is trying to bite off more than it can chew. I’d *much* rather see the efforts discussed in this thread redirected to creating good 3rd Party Components for Revolution as it is, writing documentation for the current Revo, and helping report/fix bugs for the current Revo version. We don’t even have a solid search 3PC for Revolution, and you guys are talking about dev->staging->production? Slow down!

I’d much rather see work on:
- Helping fix revo bugs
- writing a search 3pc
- writing a good replacement for ditto
- writing a blog 3pc, using custom Resource types (ie, modWeblink is a custom resource type, we can work out the best way of doing this, and we can alter the code now to make this easy to add)
- writing a solid gallery/photo 3pc
- writing integrations with social media
- writing other needed 3pcs

Steady progress, guys. These things will definitely be major concerns for 2.1 and onward. Let’s not put the cart before the horse - let’s get 2.0 out first. Overreaching is the #1 way to kill a project. Heck, the reason Revo’s been so slow in releasing is because we might have added *too* much.

Quote from: shamblett at Oct 26, 2009, 02:47 PM

The acid test of course is to do this, why don’t we issue the next upgrade to revo(beta 5, RC1 whatever) as a package thats just ’installed’ to your existing installation, then bingo, its latest, and I can uninstall it if it breaks.

We’ve talked about this, and thrown in around (hence the ’bootstrap’ files in setup/ that currently do nothing), but getting this working on the myriad of different environments out there is proving to be quite the challenge. If you’d like to look into tackling that, please feel free to.

Quote from: splittingred at Oct 26, 2009, 03:09 PM

Whoa, now, everyone slow down. . . .

Good points, especialy when we don’t yet have either Wayfinder or Ditto fully converted and debugged for Revoloution.

Still, it’s fun to to take a break from the grunt work and discuss high-level issues once in a while .

Whoa, now, everyone slow down. Smiley

First off, let’s get MODx Revolution 2.0.0 out. Wink Then we can worry about the more advanced features and workflow, and address those in 2.1.

Yes, you are of course correct, let’s try and get all hands to the pump on where we are and what we need to do next.

Discussions like this are great as long as we don’t lose focus.

I for one need to look at the docs and the pdf doc generation part of the site. I’ve simply not got round to this yet but hey, lets do this next and try and improve things here.

Other than that, I’m not sure about the ditto and photogallery stuff as i don’t really use these(so I don’t really know how they work) but this one :-

writing other needed 3pcs

please mail/message me, there maybe some conversions we can do here that are quite straightforward.

Quote from: shamblett at Oct 26, 2009, 06:10 PM

please mail/message me, there maybe some conversions we can do here that are quite straightforward.

Email sent.