Generic design for packaging of user changes for deployment

Question

Hi all,

OK a real question - I'd like to add the ability for users of a system I developed to make package a set of changes together so that they can deploy their package of changes to an acceptance testing environment, do their testing, and then at a later point (if testing was successful) deploy that package of changes to a live environment.

The system in this case is J2EE webapp updating relational database records, but it kinda seems like this package and deploy capability shouldn't really need to be specific to my app and could be reuseable pluggable functionality if I go about it the right way.

Anyone know of any existing solutions that might apply or got any advice on how to best to go about it?

Thanks!

Answer 1

Thanks for the answer John - the system works!

It's not the code I'm looking to package, it's the actual changes they're making as end users in the app - so say a user takes actions in their UI and the overall result of those actions would be to update a dozen database records in different tables, I want them to be able to package up those data changes.

Maybe as an analogy it's like I want to write up a few questions for this site and save them so I could publish them to the public website later after I'd had time to think about them more?

I thought about working with the database transaction rollback/commit mechanism but it feels like the wrong place to do it and a nasty dependency on a particular persistence mechanism.

Answer 2

So, if I read this correctly, you're looking to give your end users the ability to take a set of transactions from one system and run them automatically on another.

I would suggest designing something in two steps. First, build the mechanism. I would think that this would require building a simple script engine which accepts a flat file with commands listed in order. Test the functionality and make sure the commands work.

The second step is to make it end-user friendly. For the majority of users, this means some type of "Script Builder" tool that will make it easy for them to create portable scripts.

This type of solution should be portable, if designed with portability in mind. :D

Answer 3

If you're running within a Linux environment, check out RPM. I've build systems in the past that automatcically check out a branch of code from CVS, package it up, transfer it to a Prod/UAT system, run tests and install it, run some more tests and generate a status email.

The best part with using RPM is that you can uninstall the package and configure scripts (held within the RPM) to do any kind of custom tasks before or after the (un)install.