|
| 1 | +--- |
| 2 | +id: team-processes |
| 3 | +title: Internal Processes |
| 4 | +--- |
| 5 | + |
| 6 | +### Release Process |
| 7 | + |
| 8 | +Symphony is using the continuous push methodology. This means that new code is pushed to production whenever changes are done, usually every 30 minutes. |
| 9 | +This enables the Symphony team to move fast and react to partner requests in real time. Bugs are fixed in a matter of hours, and new requests are developed in a matter of days. |
| 10 | + |
| 11 | +The product is protected by numerous automated tests. Unit tests, integrations tests and UI E2E tests are all in place to block the push in case a major feature was broken. |
| 12 | + |
| 13 | +### SEV Process |
| 14 | + |
| 15 | +The Symphony team is taking any breakage in the product seriously. |
| 16 | +Every week one team member is an “oncall” - responsible for the health of production. He is constantly fixing bugs, monitoring any report from our partners and improving the quality of the tool. |
| 17 | +Whenever a serious problem occurs, we are opening a “SEV”. SEV is an incident report, that requires “all hands on deck”. It means that all of the team is focused on solving the issue ASAP. |
| 18 | +The severity of the SEV is as follows: |
| 19 | + |
| 20 | +* SEV 3 |
| 21 | + * A high priority feature is not working in prod (e.g. connect links, pyinventory) |
| 22 | + * High number of intermittent failures |
| 23 | +* SEV2 |
| 24 | + * 1-2 prod partners are down |
| 25 | + * Internal partner is down |
| 26 | +* SEV1 |
| 27 | + * "Production" is down (Inventory\WO is inaccessible for all partners) |
| 28 | + * Data layer is inconsistent and partner's data is lost |
| 29 | + |
| 30 | +Our commitment towards fixing SEVs is as follows: |
| 31 | +* SEV 3: Fix during regular business hours. |
| 32 | +* SEV 2: Fix with reasonable after hours. Feel free to ping others or even wake up people until the problem is resolved. |
| 33 | +* SEV 1: All hands on deck until fixed! Fix, even with unreasonable after hours. |
| 34 | + |
| 35 | +After the SEV is mitigated, the team is having a “postmortem” meeting to review the SEV. SEV timeline, cause, time to mitigate- all numbers are reviewed. The team is leaving this meeting with a set of tasks to do: add automated tests, improve code infrastructure, fix bugs, etc. |
| 36 | + |
| 37 | +After every SEV, our goal is not only to fix the problem, but also to fix the code in such a way that similar SEVs will never occur. |
| 38 | + |
| 39 | +### Deprecating APIs |
| 40 | +If changes are done to the schema we will mark old endpoints as deprecated. |
| 41 | +Here you will find the list of deprecated endpoints [list of deprecated endpoints](graphql-breaking-changes.md) |
| 42 | + |
| 43 | +Partners are expected to upgrade their code to the new version. |
| 44 | +After <TBD> months of Deprecated state we will delete old endpoints. |
| 45 | + |
| 46 | +<< TBD more details >> |
0 commit comments