Thanks, Joaquin!! What do others think about this?
On Wed, Apr 25, 2012 at 11:54 AM, Joaquín Blaya < [email protected]> wrote: > 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 >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list > -- Sincerely, Dawn C. Smith, MPH, CHES Project Coordinator for OpenMRS <http://openmrs.org/> O: +1 317-423-5583 _________________________________________ 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]
