Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Resolve WIT-537 "Version docker images mwaa"
# Breaking changes From now on, docker images will be versioned, and will follow the same versioning mechanism of witboost core component. # Definition of Done for Feature/Hotfixes ## All Developments * [x] Feature was implemented as per the requirements * [x] If some code parts are complex they must be commented with code documentation * [x] CI/CD is successful * [x] Code coverage is not reduced, any new code is covered * [x] E2E/integration tests are successful (whether run locally or in CI/CD) * [x] If dependencies were changed, be sure that they will not impact the project, that their license is compatible, and that they introduce no vulnerabilities * [x] Documentation have been updated * Documentation has been updated with explanation of the new feature if it is user-facing (eg component now has additional setting) or it impacts him in some other way (eg optional field that becomes mandatory) * If it is a breaking change, we have documented it as such in the MR description in a "Breaking Changes" section * [x] Check that you are not affecting any existing environments with these changes, especially the Sandbox/Playground. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed** * [x] Check that nothing is out of order and nothing problematic is included in the changes (sensitive information, credentials, customer information or other intellectual property) as they could end up being public (we have Open Source SP already published and automatically mirrored) * [x] Security, Authentication and Authorization have been considered. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved ## API Development * [ ] Semantic of API has been checked, it is comprehensible, meaningful, with no redundant information and user oriented * [ ] Meaningful unit and integration tests are present * [ ] API Parameters are checked and errors are handled * [ ] Returned errors are meaningful to the user * [ ] API contract has been defined and documented. Documentation means explaining the meaning of all fields and including at least one example * [ ] Exceptions and errors are handled, without letting the underlying framework to respond with a generic Internal Server Error * [ ] API Performance has been assessed and is good for real world use cases. Database accesses have been optimized. * [ ] API is logging in compliance with audit standards, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed ## DB Development * [ ] The database schema is designed to accurately represent the data model and meet the requirements * [ ] Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately and following a common convention * [ ] Normalization principles are applied to eliminate data redundancy and ensure data integrity * [ ] Schema semantic is meaningful * [ ] Fields naming are following naming convention ( Ex. camelCase or snake_case) * [ ] No fields with mixed behaviors and meaning. If a field is representing an enum, enum values are strongly mutually exclusive * [ ] Data Types have been reviewed and they are a good fit for each field * [ ] Indexes are defined to optimize query performance for frequently accessed data, paying attention to do not affect too much write path and the overall complexity * [ ] Sensitive data is stored securely, encrypted if required, and access is restricted to authorized users * [ ] Backup and restore procedures have been updated to introduce new or changed tables * [ ] Migration scripts to upgrade and downgrade the database have been implemented and tested Closes WIT-537
- Loading branch information