Difference between revisions of "ESciDoc CoreService Upgrade"
Jump to navigation
Jump to search
| (13 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
''IN PROGRESS'' | |||
=Core service adoption/upgrade procedure at MPDL= | =Core service adoption/upgrade procedure at MPDL= | ||
| Line 4: | 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?) | |||
*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 | |||
**bug/reports should be forwarded to FIZ | **bug/reports should be forwarded to FIZ | ||
**solution/service developments allowed only for interface changes | **solution/service developments allowed only for interface changes | ||
*no green light from MPDL side until solutions (latest releases) are running stable | *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 | *duration proposed: focused team max 10 - 15 days | ||
| Line 22: | Line 25: | ||
**bugs reported in previous versions do not appear again | **bugs reported in previous versions do not appear again | ||
**performance is not affected in negative manner | **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 == | ==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 | |||
*DEVELOPMENT | |||
**upgrade dev-coreservice | |||
**merge evtl. new developments with new releases | |||
[[Category:ESciDoc|CoreService Upgrade]] | |||
Latest revision as of 09:39, 7 January 2011
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
- availability is not affected in negative manner (outofmemory errors)
Upgrade procedure[edit]
- 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
- ..?
- checklist
- check space
- release on production
- send/prepare notifications wherever needed
- DEVELOPMENT
- upgrade dev-coreservice
- merge evtl. new developments with new releases