No I haven't, but I will. Thanks!
Joaquín ___________________________________________________________________ Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> Research Fellow, Escuela de Medicina de Harvard <http://hms.harvard.edu/> Moderador, GHDOnline.org <http://www.ghdonline.org/> On Wed, Apr 25, 2012 at 9:52 AM, Burke Mamlin <[email protected]>wrote: > Joaquín, > > Have you tried the release testing helper > module<https://modules.openmrs.org/modules/view.jsp?module=releasetestinghelper>? > You install this module on your production system and then download the > standalone & run it in testing mode. It asks for the URL for your > production machine and then authenticates to the release testing helper > module to automagically set up a test environment for you with the latest > version of OpenMRS, all of the modules from your production system, and a > subset of test data drawn directly from your production system. The goal > is to make testing your system on a newer version of OpenMRS easier (i.e., > 1. install helper module on production, 2. download standalone & run it). > > -Burke > > > On Wed, Apr 25, 2012 at 7:56 AM, Joaquín Blaya < > [email protected]> wrote: > >> Hi Dawn, >> Our tasks for when we do a full system upgrade are >> >> 1. Check our modules to see if they work, if they don't investigate >> bugs and send code to developers to fix it, then test it again >> 2. Test public modules which we use and if they don't work file bugs >> and fix them if necessary >> 3. Wait for updated MVP dictionary (this will be in the future when >> we start using it) >> 4. Redeploy custom interface >> 5. Deploy in test server and check to make sure all data is upgraded >> and that there are no bugs. If there are bugs, fix them. >> 6. Make backup of all current systems that we are hosting >> 7. Create material to provide to users about the upgrade and what >> this will mean to them >> 8. Train technical staff to answer possible questions that will arise >> from upgrade >> 9. Deploy in all of the OpenMRS instances that we have >> >> For us this is still hypothetical because we haven't upgraded from our >> 1.6 instance. >> >> >> >> Joaquín >> ___________________________________________________________________ >> Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> >> Research Fellow, Escuela de Medicina de Harvard <http://hms.harvard.edu/> >> Moderador, GHDOnline.org <http://www.ghdonline.org/> >> >> >> >> On Tue, Apr 24, 2012 at 6:15 PM, Dawn Smith <[email protected]> wrote: >> >>> Hi Everyone, >>> >>> On the recent developers forum we talked about ways in which OpenMRS has >>> changed the road map focus from version numbers (updates to the core) to a >>> road map focused on what's most important to implementations (features and >>> functionality). What we envision in the long term is that implementing >>> sites will drive the direction of development.. >>> >>> So as we move in this direction, what we want to know is: *How often >>> should full system upgrades happen?* >>> >>> One of the things we also want to understand in your answer is what the >>> overhead is for an implementation to update to a new release. This may >>> include consideration that a roll out needs to occur over multiple sites >>> and/or the resources and time it takes for an implementation to do thorough >>> testing. The more information you can provide, the better! >>> >>> Thank you in advance for your feedback. :) >>> >>> >>> >>> All the best, >>> >>> -Dawn >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>> OpenMRS Implementers' mailing list >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >> OpenMRS Implementers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list > _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
