Difference between revisions of "ESciDoc CoreService Upgrade"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 5: Line 5:


*latest core-service (decision by dev team if we work with build or RC candidate)
*latest core-service (decision by dev team if we work with build or RC candidate)
deployed always on latest-coreservice.mpdl.mpg.de (already exists, practice a bit abandoned?)
** deployed always on latest-coreservice.mpdl.mpg.de (already exists, practice a bit abandoned?)
*latest released solutions/code should be run against the latest core-service
*latest released solutions/code should be run against the latest core-service
**necessary test data should be ingested for all solutions
**necessary test data should be ingested for all solutions

Revision as of 08:29, 17 March 2010

IN PROGRESS

Core service adoption/upgrade procedure at MPDL[edit]

Pre-requisites for adoption of new core-service[edit]

  • latest core-service (decision by dev team if we work with build or RC candidate)
    • deployed always on latest-coreservice.mpdl.mpg.de (already exists, practice a bit abandoned?)
  • latest released solutions/code should be run against the latest core-service
    • necessary test data should be ingested for all solutions
    • bug/reports should be forwarded to FIZ
    • solution/service developments allowed only for interface changes
  • no green light from MPDL side until solutions (latest releases) are running stable
  • FIZ has to have access to test environment for own tests with our data/solutions
  • duration proposed: focused team max 10 - 15 days
  • when can it start: as soon as we have agreed with FIZ on new RC candidate test
    • solutions in development are not considered for testing
    • branch of released solution code to be created for these purposes
      • issues with merging afterwards to be checked

Pre-requisites for stable core service[edit]

  • feedback from solution developments
  • agree on "stable"
    • already existing features work properly
    • bugs reported in previous versions do not appear again
    • performance is not affected in negative manner
    • if there is a need for migration of core-service data - migration procedure must be tested and run without problems

Upgrade procedure[edit]

  • make new release of branched solutions (if these are properly tested)
  • QA
    • last tests (further to be detailed whether) and evtl bug-fixes of solutions
  • PRODUCTION
    • send/prepare notifications wherever needed
      • checklist
        • pilots
        • blogs
        • gwdg
        • content management systems
        • ..?
    • check space
    • release on production
  • DEVELOPMENT
    • upgrade dev-coreservice
    • merge development with new releases