8. Introducing new game version
• Logic changes synced with „fast” game update
• Backwards compatibility
NO VERSIONING
9. Supporting old game versions
VERSIONING REQUIRED• Requirement to support multiple logic paths
10.
11. Summary
• Convenient way of rolling out new game versions
REASONS FOR VERSIONING
• Supporting old versions with different business logic
• Protecting access to old/new features
28. Implementation
• Duplicate tables of versioned entities for each version
• Table names depend on current data version
• Foreign keys are duplicated too
• Except for foreign keys from unversioned to versioned data
29. Implementation
• Data version is a request parameter
• Hook into Doctrine metadata loader to change tablenames
• Hook into Doctrine metadata cache loader
39. Server Agent
• Updates server state through HTTP
MANAGEMENT
• Registers the server in a server manager
• Sends commands to server process with bash
github.com: yohang/finite
• Uses state machine for bullet proof state transitions
• States include: starting, running, graceful-stopping, stopped, updating etc.
40. Server Manager
• Provides current tasks for each servers
• HTTP RESTful service
• Analyzes current server requirements and spawns tasks for servers
VERSION
MANAGER
COORDINATOR
• Handles server registration & state updates
• Background process
• Notifies about not enough servers in the pool
• Capable of auto-scaling based on the game servers usage by
players
41. Server Manager
• Manager spawns minimum number of servers
• Human defines minimum/maximum number of servers per game version
• Manager adjusts number of servers to cover current load
SERVER PROVISIONING
Jako GOG.com jesteśmy firmą działającą w przemyśle growym
Ogólny model komunikacji asynchronicznej
Ogólny model komunikacji asynchronicznej
Ogólny model komunikacji asynchronicznej
Ogólny model komunikacji asynchronicznej
Ogólny model komunikacji asynchronicznej
Ogólny model komunikacji asynchronicznej
Services updated independently
Client AND Services only has to know one version number
Introducing new version we make sure stuff is compatible
Fallback allows for not updating other services
Protocol+Client composer repositories
Microservices: passing API version in messages & calls
Testing with integration tests (which we don’t have!)
No client request = no known version -> save last used user version
Possibility to lock user version, disallow downgrading
Query because: versioning is optional, backward compatible, visible in access logs, easy to debug
Not path because: path describes entity
Not header because: proxies, HTTP cache, hacky, hard to debug
Microservices communication: passing API version in messages & calls (generic message envelope in async, context generation)
Automatically choose controller action with fallback
Semantic strategy class methods for enabling features, selecting code paths or for factories
Dropping support for old API versions: denying, removing versioning;
Diagram for game versions with different data
Diagram for game versions with different data
Passing around in messages & calls, background processes
Query parameter
Versioned and unversioned entities, duplicated tables, foreign keys lost and retained
Doctrine mappings switch realtime, doctrine metadata cache
User -> Versioned — manual consistency
Versioned and unversioned entities, duplicated tables, foreign keys lost and retained
Doctrine mappings switch realtime, doctrine metadata cache
Updating schema challenges
Versioned and unversioned entities, duplicated tables, foreign keys lost and retained
Doctrine mappings switch realtime, doctrine metadata cache
Updating schema challenges
Rankings
Rankings
Unit & integration tests for logic, only QA tests for data
Privileges, locking from editing; removing old DV
Active servers on the left
Servers in the pool on the right
Ogólny model komunikacji asynchronicznej
Ogólny model komunikacji asynchronicznej
PHP long running process -> Leszek Krupiński presentation
PHP long running process -> Leszek Krupiński presentation
Unit + functional tests for checking the logic on multiple api/data versions
Isolated, allows to check if all the services integrate properly with each other
Independent client which checks services API responses all the time
Native game client configured to follow predefined scenarios and check for correct behavior of webservices
As it has high hardware requirements we cannot run too much of them
Native game client – just missing the UI part
Thanks too much lower requirements we can run hordes of them (dozens of thousands) to even make internal stress tests