Revision as of 08:29, 17 March 2010

IN PROGRESS

Core service adoption/upgrade procedure at MPDL[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

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

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

@@ Line 5: / Line 5: @@
 *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
 **necessary test data should be ingested for all solutions