ESciDoc CoreService Upgrade

IN PROGRESS =Core service adoption/upgrade procedure at MPDL=

Pre-requisites for adoption of new core-service

 * 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

 * 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
 * availability is not affected in negative manner (outofmemory errors)

Upgrade procedure

 * make new release of branched solutions (if these are properly tested)
 * QA
 * deploy solutions on qa
 * deploy core-service on 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
 * release on production


 * DEVELOPMENT
 * upgrade dev-coreservice
 * merge evtl. new developments with new releases