Team-best-practices

Proposing technical changes

When someone wants to propose any change on the technical part of the project, for example adding a new gem, changing a Rubocop rule, refactor some parts, etc., we follow this path:

1. Open a new thread on discussions, describing in depth what, why and, if available, how to do it
2. Post the newly created thread in backend team Slack channel, just to let the team know that a new discussion is available.
3. When some decision have been made and a code change is needed, we proceed creating the related Jira task.
4. As we already do, in the "Technical changes description" of the related PR, we'll post detailed information about the change and the link to the discussion made.

Breaking changes

We must avoid breaking changes. There are many strategies to deploy backward compatible code, and they must be decided along with the developer teams of impacted clients. An example can be:

• add new logics in backend side
• let the clients use new endpoint/params/models
• remove old logics from backend
• let the clients cleanup backward compatibility changes

Reasons:

1. it's very risky
2. it requires deployment coordination between backend and all the clients
3. something can brake during a deploy
4. it requires TWPRO frontend deployment to be instant
5. instant deployment on TWPRO frontend means N venues re-synching all data in the same instant
6. N venues re-synching all data in the same instant means a possible downtime in the whole TWPRO ecosystem
7. a rollback on non-backward compatible change would not be possible