====== 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.
    * //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: _ 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