Responsibilities » History » Version 3
Sebastian Manger, 09 Feb 2016 13:55
1 | 1 | Sebastian Manger | h1. Responsibilities |
---|---|---|---|
2 | 2 | Sebastian Manger | |
3 | h2. Environments |
||
4 | |||
5 | * New Requirements |
||
6 | > * "Agile Board column":https://redmine.cde.unibe.ch/projects/qcat/agile/board - New |
||
7 | > * Responsible: Kurt Gerber (User Stories are complete in form and content; Issues are sorted according to priority). |
||
8 | > * Hosting: None |
||
9 | > * Notes: Application errors are new user stories as well - they might just be on the top of the list. |
||
10 | |||
11 | * In progess |
||
12 | > * "Agile Board column":https://redmine.cde.unibe.ch/projects/qcat/agile/board - In Progress |
||
13 | > * Responsible: Developers (Lukas / Sebastian) |
||
14 | > * Hosting: https://qcat-dev.wocat.net |
||
15 | 3 | Sebastian Manger | > * QR Code !qcat_dev.png! |
16 | 2 | Sebastian Manger | > * Notes: User Stories result in feature branches; Continuous delivery is active for the develop branch only. If a feature is finished, the issues status must be updated on redmine. |
17 | |||
18 | * Review |
||
19 | > * "Agile Board column":https://redmine.cde.unibe.ch/projects/qcat/agile/board - Resolved |
||
20 | > * Responsible: Kurt Gerber / Project Management |
||
21 | > * Hosting: https://qcat-beta.wocat.net (to be defined) |
||
22 | 3 | Sebastian Manger | > * QR Code !qcat_beta.png! |
23 | 2 | Sebastian Manger | > * Notes: Review should be done after each sprint. Kurt Gerber decides if the PM must also review a feature. |
24 | |||
25 | * Done |
||
26 | > * "Agile Board column":https://redmine.cde.unibe.ch/projects/qcat/agile/board - Feedback |
||
27 | > * Responsible: Developers |
||
28 | > * Hosting: https://qcat.wocat.net |
||
29 | 3 | Sebastian Manger | > * QR Code !qcat_live.png! |
30 | 2 | Sebastian Manger | > * Notes: If an issue is done, it must be deployed to the live environment. |
31 | |||
32 | h2. Workflow: new requirements and application errors |
||
33 | |||
34 | * The review must only check for the defined acceptance criteria |
||
35 | * If new requirements are asked for, a new subtask is created. The new issue is treated as any other issue. |
||
36 | * If an application error occurs, Kurt Gerber decides on its priority. |
||
37 | > * If it must be resolved immediately, a hotfix is created. |
||
38 | > * A hotfix also results in a new task and is reviewed. |
||
39 | > * The hotfix is merged into the beta-branch first. |
||
40 | |||
41 | h2. To be defined: |
||
42 | |||
43 | * How do we implement these responsibilities? |
||
44 | * Beta and live deploy: |
||
45 | > * do we use git tags? |
||
46 | > * manual deploy with a defined release calendar or integrated with the continuous delivery system? |
||
47 | |||
48 | h2. Tools: |
||
49 | |||
50 | * "Opbeat":https://opbeat.com/university-of-bern-cde/ measures the performance and logs all errors. |
||
51 | * "Shippable":https://app.shippable.com/ is used for continuous delivery (deploys the latest state of the develop branch to qcat-dev if all tests pass). |