Full System Upgrades: How Often Should They Happen?

classic Classic list List threaded Threaded
6 messages Options
Dawn Smith Dawn Smith
Reply | Threaded
Open this post in threaded view
|

Full System Upgrades: How Often Should They Happen?

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

[hidden email] from OpenMRS Implementers' mailing list
Joaquín Blaya Joaquín Blaya
Reply | Threaded
Open this post in threaded view
|

Re: Full System Upgrades: How Often Should They Happen?

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
Research Fellow, Escuela de Medicina de Harvard
Moderador, GHDOnline.org


On Tue, Apr 24, 2012 at 6:15 PM, Dawn Smith <[hidden email]> 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

[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Full System Upgrades: How Often Should They Happen?

Joaquín,

Have you tried the release testing helper module?  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 <[hidden email]> 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
Research Fellow, Escuela de Medicina de Harvard
Moderador, GHDOnline.org



On Tue, Apr 24, 2012 at 6:15 PM, Dawn Smith <[hidden email]> 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

[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Joaquín Blaya Joaquín Blaya
Reply | Threaded
Open this post in threaded view
|

Re: Full System Upgrades: How Often Should They Happen?

No I haven't, but I will. 

Thanks!

Joaquín
___________________________________________________________________
Gerente de Desarrollo, eHealth Systems
Research Fellow, Escuela de Medicina de Harvard
Moderador, GHDOnline.org


On Wed, Apr 25, 2012 at 9:52 AM, Burke Mamlin <[hidden email]> wrote:
Joaquín,

Have you tried the release testing helper module?  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 <[hidden email]> 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
Research Fellow, Escuela de Medicina de Harvard
Moderador, GHDOnline.org



On Tue, Apr 24, 2012 at 6:15 PM, Dawn Smith <[hidden email]> 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

[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Dawn Smith Dawn Smith
Reply | Threaded
Open this post in threaded view
|

Re: Full System Upgrades: How Often Should They Happen?

Thanks, Joaquin!!

What do others think about this?

On Wed, Apr 25, 2012 at 11:54 AM, Joaquín Blaya <[hidden email]> wrote:
No I haven't, but I will. 

Thanks!


Joaquín
___________________________________________________________________
Gerente de Desarrollo, eHealth Systems
Research Fellow, Escuela de Medicina de Harvard
Moderador, GHDOnline.org


On Wed, Apr 25, 2012 at 9:52 AM, Burke Mamlin <[hidden email]> wrote:
Joaquín,

Have you tried the release testing helper module?  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 <[hidden email]> 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
Research Fellow, Escuela de Medicina de Harvard
Moderador, GHDOnline.org



On Tue, Apr 24, 2012 at 6:15 PM, Dawn Smith <[hidden email]> 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

[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list



--
Sincerely,
 
Dawn C. Smith, MPH, CHES
Project Coordinator for OpenMRS
O: +1 317-423-5583


[hidden email] from OpenMRS Implementers' mailing list
James Arbaugh James Arbaugh
Reply | Threaded
Open this post in threaded view
|

Re: Full System Upgrades: How Often Should They Happen?

In reply to this post by Dawn Smith

Hi Dawn,

 

For us (HAS), fewer changes with more frequent releases would be best.  Having fewer changes at a time would be beneficial for us because of the large single implementation that we run.  Doing the database updates during an upgrade takes a considerable amount of time.  Having that split into multiple releases over time would be favorable.

 

Our testing consists of updating our test server with the database dump from the previous night, and deploying the war file to be tested.  I prefer doing it this way as opposed to using the Release Testing Helper module and Standalone because the latter option doesn’t test my environment; compatibility with my OS, Java, and Tomcat versions; the OpenMRS stand alone is also a BIG download for us.

 

For the community, supporting a version base that includes more similar versions released in a shorter time-span would be better.  It would also reduce the need to back-port as much if a new version is released more frequently, older versions would also reach EOL sooner.

 

At the same time, we allocate a significant amount of time to testing the potential releases.  Doing this more frequently would require additional resources.  This is one way that we can contribute back to the community.

 

Having a major release per our current frequency isn’t bad, but slightly more frequently might be better.

 

Thanks,

James

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Dawn Smith
Sent: Tuesday, April 24, 2012 5:16 PM
To: [hidden email]
Subject: [OPENMRS-IMPLEMENTERS] Full System Upgrades: How Often Should They Happen?

 

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


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list