Projects:Retail Backward Compatibility Tests
Introduction
In multi-server environments it is quite possible that different systems are updated at different points in time. This means that our solution should be able to handle a situation where different versions are running together and interacting with eachother.
After internal design discussions (see documentation) the consensus is that we should follow the approach:
- In a multi-server environment always update the central server first followed by the store servers.
- This means that the store servers can be 'older' than the central server.
- WebPOS systems will then be based on client side code/artifacts of a previous version compared with the central server.
- The central server will receive json messages with 'old' content and should be able to handle this.
To support this approach we need to check and validate that the following architecture runs without problems:
- central server in new release
- webpos system running previous release
The goal of this project is to result in an automated test build task which checks a webpos client of a previous release against a server from a newer release. This automated test build task does something like this:
- create a complete OB install of the latest version
- replace the WebContent/web directory with a WebContent/web directory of a previous release
- create a pi-mobile branch corresponding to the previous release
- run all the testcases
The project will be done in 2 phases:
- in the first phase the idea is to prototype the approach and see what obstacles we encounter. The result of the first phase should be a document describing the steps to create the test environment and run the previous version of the tests. Also we need to know the interval of the build job (daily probably). This phase will be executed in the 16Q4 dev cycle.
- in the second phase the idea is to implement the ideas in a real build task which is integrated/run as part of the OB Commerce ci environment. This phase will be executed in the 17Q1 dev cycle.
The role of release management in the first phase is to discuss and give feedback. In the second phase the role of release management is larger as the new build has to be setup and run as part of the rest of the ci-jobs.
Documentation
- https://docs.google.com/document/d/1j4p5troCM6Ya7EbG1AkuWVmseT1t9J7gDRLQBYKX94c/edit
- https://docs.google.com/presentation/d/1fFkf1UcV6TgkyZHNulBmR8qyJAaG1ep2xQyYofTyZVE/edit