v5_development
Developing in the V5 World
This article should be a short guide on what to do if one implements new features or changes old features in the v5 world.
Development Steps
No matter what exactly has do be done, there are some steps that should always be performed when working with the v5 code base.
<HTML><ol></HTML>
- create a trello ticket
- setup the card according to the guideline (https://docs.google.com/presentation/d/1xNUwz5ddyoXdTWUSmju-vUO6mttbVDkR1iNshceZq-k/edit#slide=id.geb68c3dee2_1_3)
- note all the requirements as exactly as possible!
example: creating an endpoint: what is the interface? what should be returned in error cases? are there time limits?
- add a list of required steps to complete the task
- setup git / create a new branch
- clone git / pull / check that you are in master
- create a new branch for the feature, naming convention: <ID>_<NAME> where ID is the trello card number
- setup / check the local developing environment
- make sure all tests are running
- build.sh + run_local.sh (or the projects equivalent) are working
- implementation
- do one thing at a time (dont work on independent features in parallel)
- understand the implications of a change (changing a function - where is it used? changing a db query - do indexes have to be reevaluated / changed? and so on)
- have as few code duplication as possible.
- use type hints for parameters and returned values
- logging: everything that may be useful for debugging later on should be logged; use the correct level
- tests: new feature = new test; changing code = check / change existing tests; removing code = check / change existing tests
test the positive case, but more importantly test cases where the input is not as “usually expected”
- documentation: code should be clear, simple and readable, but there are definitely cases that require documentation; just make sure that someone who reads the code without explanation can understand whats going on. writing a non trivial function? docstring; creating an endpoint? docstring; doing black magic or 3 steps in one line? comment; adding a complete new feature, changing a pipeline, etc? update the README.md
- make an entry in the CHANGELOG.md
- merge request + commit meeting
- make sure that you pushed all the changes to the feature branch, then create a merge request
- get someone for the commit meeting and prepare to answer questions about your changes
- merge
- deployment + (pre-)live system changes
- change back to master an pull the changes and run the tests again
- make sure that it is fine to deploy (check the logs of the live system, is it used right now?)
- use the deploy pipeline of the project
- test that the deployment worked correctly (logs, health endpoint, test scripts, check index usage)
- are there changes necessary to the live system outside the code? e.g. database changes (tables, indexes,… also keep in mind to perform analyze after postgres changes) or cronjob changes<HTML></ol></HTML>
v5_development.txt · Last modified: 2024/04/11 14:23 by 127.0.0.1