Skip to content. | Skip to navigation

Personal tools
This is Lite Plone Theme
You are here: Home / Documentation / Internal Scandiatransplant Documentation / Technical Documentation / Release & Bugzilla Workflow

Release & Bugzilla Workflow

The Scandiatransplant office handles all aspects in the application update decribed below.
Each 'Sprint' starts with a planning-meeting which includes risk assessment of all included 'Bugzillas' and when needed ends with a 'Sprint' review-meeting.

The following statuses are used in the Bugzilla installation at the Scandiatransplant office
New 200
Assigned 300
Reopend 400
Resolved 500
Verified 600
Closed 700
The following picture illustrats the typical workflow with transitions between statuses. In the figure 'Developer' refers to the 'Programmers' and 'Tester' means 'Clinical Data Managers'.

 

 

As a general rule, when bugs require action from others than the assignee, they are reassigned.

Status: New
When bugs (errors, enhancements) are registered they get the status 'New'.
If the reporter (could be the same as the assignee) feels like estimating the amount of time it will take to resolve the bug, it can be done when submitting the bug initially (Show Advanced Fields -> Orig. Est.), but otherwise the assignee should do it as soon as possible at latest at the first work-day of the following week. Time estimates are also done at Backlog Estimation once a week. It is imperative that the estimation is done as soon as possible for the priority-functionality to work properly. Non-estimated issues are outlined in red and shows up at the top in the prioritized list: https://sc42.scandiatransplant.org/bugzList.htm


Status: Assigned
Developer, when a developer starts working on a bug, he should change the bugs' status to ‘Assigned’. The ‘Assigned’ status will be used to get an indication of which bugs are being worked on. Therefore, if for some reason a developer leaves a bug and stops working on it for more than a week, the bug status should be changed to ‘New’. A developer should not be working on more than a handful of bugs at a time.

Developers can at any time re-estimate bugs and should do so when commenting work done; i.e. note Hours Worked as well as a new estimation in Hours Left.

 

Status: Resolved + fixed
Developer, when a solution is ready for test, the assignee
1) changes the bug status to 'Resolved' and 'Fixed'.
2) states as a comment where the fix can be tested as well as the version (e.g. 'Ready for test on sc37/tghTopix, v0.2.1-105-g87872e0'), and
3) reassigns the bug to the tester.

 

Status: Resolved + remind
Tester completes 1st test - Pre release testing - of the suggested solution on local/individual branch (point 2 above). If test result is satisfactory and it should be included in the next 'Release candidate' 
1) bug status is changed to 'Resolved' + 'Remind'. 
2) reassigns the bug to the developer who has fixed the bug.

 

Timeline for release - pre-release:
Monday week no. 1: At internal meeting next release is agreed upon and primary responsible Developer is appointed. All developers push included items to master.
Responsible Developer creates 'Release candidate' on test server. When candidate is ready all Developers are asked to make a sanity check. The following days developers must also check that rebuild of the database is possible and that nothing is missing.

 

Status: Resolved + remind
Developers makes a sanity check on the test server on potential 'Release candidate' to see that it has been included correctly. Reassigns the bug to the Tester.

 

Timeline for release - pre-release:
Wednesday week no. 1: Responsible Developer freezes test environment and notifies the Tester.


Status: Verified + Fixed
Tester completes 2nd test on the test server, bug status is changed to ‘Verified’ + ‘Fixed’. Now all objects for the upcoming release must be included in 'Release candidate'. If test result is satisfactory the issues in 'Release candidate' are ready for production.

 

Timeline for release - release:
Wednesday week no. 2: Responsible Developer releases test version to production and notifies staff when the update is completed.


Status: Closed + Fixed
Tester, solution has been made public as a part of the production system.
Tester completes 3rd test on 'Production server' and if test result is satisfactory the bug status is changed to 'Closed' by tester.
Newsletter is sent out to all users announcing the changes in the new version.

 

Timeline for release - post-release:
Thursday and Friday week no. 2: Responsible Developer keeps a close eye on
- the rebuild of the database and takes the lead if errors occure and/or if anything is missing. 
- the log to see if the users run into problems, these can be discussed with the Data Manager
- incomming e-mails related to the update

 

Status: Reopened
At any time in the process the bug can be reopened and reassigned, with description of problem. It should be considered to create new bug(s) if enhancements are substantial.