search

SSHOC / sshoc-marketplace-backend

Code for the backend
Apache License 2.0
2 stars 0 forks source link

Rules of procedure: issue workflow #398

Open KlausIllmayer opened 1 year ago

KlausIllmayer commented 1 year ago

Anyone is invited to create new issues if the topic belongs to backend including API endpoints, database problems, SOLR settings, behavior of the business logic. If it is about design and edit workflows of the frontend, please use the dedicated frontend repository and issue list: https://github.com/SSHOC/sshoc-marketplace-frontend/issues

It is not always easy to understand if an issue relates more to backend or to frontend. Therefore the best approach for a new issue is to put @KlausIllmayer as an Assignee, so that I can give a first reply and also see, if the issue is at the correct place. If not, the issue will be moved to a better fitting repository.

If an issue is identified as relevant for backend, the next step is to forward it to the backend team for further investigation. For this the label "to do" is applied to the issue and one of the backend team is added as new assignee.

Issues that need to be solved as soon as possible because they do block other tasks or are important for the maintenance of the marketplace do get the label "critical". This should give them a priority boost. Additionally, they are communicated on our Slack channel, so that the backend-team is aware about this critical issue. If backend agrees to take over the issue, the issue is applied to a milestone (see next paragraphs on how milestones work)

The list of open issues are discussed in a dedicated meeting and they are prioritized there. We work with the help of milestones, where a milestone stand for a quarter of the year (e.g. milestone Q1 2023 contains issues that should be solved by the backend team until end of March 2023). Based on the available resources, issues are applied to such a milestone. We usually only plan for the next milestone (= the next quarter of the year). Open issues, that are not applied to a milestone, will be discussed in the next meeting. As resources are limited, some issues will need to wait longer than other issues.

If backend team works on an issue, a dedicated branch for this issue is created. After fixing, a pull request to the develop-branch is created and all assignees of the issue should have a look before applying the pull request. After accepting the pull request an automatic deployment on the stage instance is done. The change now can be tested there. To mark this state, the issue moves from label "to do" to label "in review". If the issue still is not solved or follow-up problems are spotted, the label "in review" is now replaced with the label "to do" and in the issue a comment is posted, describing what went wrong. Backend team then will again look into it.

If the tests on stage are fine a pull request to the main-branch is created, an comment is added to the issue and it is closed. The pull request is applied usually on Monday or Tuesday afternoon around 17h, as this means that the production instance gets the new code and a short downtime will happen (and in some cases, the search index needs to be re-created, which takes some hours, where the search is not available - thus the availability should be there again in the morning of the next working day). When testing the deployment on production show that everything went fine, the "in review" label is deleted.

laureD19 commented 11 months ago

documentation. Maybe to add to the Github wiki