Development Workflow: Difference between revisions

From Bloomex Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 56: Line 56:
|
|
|-
|-
|<span style="font-size:200%;color:#FF0000;">↑</span>
|<span style="font-size:100%;color:#FF0000;">↑</span>
|'''''PM Analyzing'''''
|'''''PM Analyzing'''''
|PM
|PM
Line 80: Line 80:
|
|
|-
|-
|<span style="font-size:200%;color:#FF0000;">↑</span>
|<span style="font-size:100%;color:#FF0000;">↑</span>
|'''''Rework'''''
|'''''Rework'''''
|Developer name
|Developer name
Line 111: Line 111:
|-
|-
|
|
|<span style="font-size:200%;color:#FF0000;">↑</span>
|<span style="font-size:100%;color:#FF0000;">↑</span>
|'''''Rework'''''
|'''''Rework'''''
|Developer name
|Developer name
Line 146: Line 146:
|-
|-
|
|
|<span style="font-size:200%;color:#FF0000;">↑</span>
|<span style="font-size:100%;color:#FF0000;">↑</span>
|'''''Rework'''''
|'''''Rework'''''
|QA
|QA
Line 185: Line 185:
|-
|-
|
|
|<span style="font-size:200%;color:#FF0000;">↑</span>
|<span style="font-size:100%;color:#FF0000;">↑</span>
|'''''Rework'''''
|'''''Rework'''''
|Developer name
|Developer name
Line 226: Line 226:
|
|
|-
|-
|<span style="font-size:200%;color:#FF0000;">↑</span>
|<span style="font-size:100%;color:#FF0000;">↑</span>
|'''''Rework'''''
|'''''Rework'''''
|PM
|PM
Line 245: Line 245:
|
|
|-
|-
|<span style="font-size:200%;color:#FF0000;">↑</span>
|<span style="font-size:100%;color:#FF0000;">↑</span>
|'''''Rework'''''
|'''''Rework'''''
|QA
|QA
Line 273: Line 273:
|
|
|-
|-
|<span style="font-size:200%;color:#FF0000;">↑</span>
|<span style="font-size:100%;color:#FF0000;">↑</span>
|'''''Rework'''''
|'''''Rework'''''
|Developer name (if Hotfix)
|Developer name (if Hotfix)
Line 333: Line 333:
|Responsible tester for Release moves all tickets from Release-Ticket to Test Live status
|Responsible tester for Release moves all tickets from Release-Ticket to Test Live status
|-
|-
|<span style="font-size:200%;color:#FF0000;">↑</span>
|<span style="font-size:100%;color:#FF0000;">↑</span>
|'''''Rework'''''
|'''''Rework'''''
|PM
|PM
Line 352: Line 352:
|
|
|-
|-
|<span style="font-size:200%;color:#FF0000;">↑</span>
|<span style="font-size:100%;color:#FF0000;">↑</span>
|'''''Rollback'''''
|'''''Rollback'''''
|System Administration
|System Administration

Revision as of 15:04, 25 August 2023


Development Workflow
Regular Ticket
Steps Role & Status Assignee Description
1. Creating Author
New IT Development Writing a Task and Description in Redmine for IT Development
2. Analyzing Project Manager (PM)
Analyzing Author
Analyzing PM (if on analyzing) Analyzing of the task and writing Terms of Reference and Test Planning (if needed)
Paused PM (if on pause)
Queue PM (if in line)
Development Developer name Preparing the application and developer priority (Give the application Development Priority A, B, C, or D). A maximum of 3 category A tickets can be assigned to a developer at the same time
3. Development Developer
PM Analyzing PM
In progress Developer name (if on development)
Development is suspended Developer name (if on pause) If the developer received an urgent ticket or a Hotfix, then the ticket should be moved to this status
Code review Senior Developer Write a link to the merge-request in the ticket
Senior Developer
Rework Developer name Write a comment in the ticket
In reviewing if need time
Move to Dev Developer name Aprove to Dev
Developer
Test Dev QA Merge to Dev
4. Testing on Dev Quality Assurance (QA)
Rework Developer name
In testing Tester name (if on testing) When a ticket is on testing, the QA assigns this ticket to himself. Write the test result in a comment.
Testing queue QA (if in line)
Test Dev (if needed) Author If necessary, assignee the ticket to the Author for feedback
Testing has been completed QA
Author (optional)
Rework QA
Testing has been completed QA If everything is ok and the conditions of the ticket are done. Aprove to Stage
Quality Assurance (QA)
Move to Stage Developer name Aprove to Stage
Developer
Test Stage QA Merge to Stage
5. Testing on Stage Quality Assurance (QA)
Rework Developer name
In testing Tester name (if on testing)
Testing queue QA (if in line)
!!!! Ready to Install QA
Go to Release-Ticket process
6. Release Quality Assurance (QA)
!!!! Test Live QA
7. Testing on Live Quality Assurance (QA)
Rework PM
In testing Tester name (if on testing)
Test Live Author
Author
Rework QA
Completed QA
Quality Assurance (QA)
Paused QA (preparing to Close) Transfer to Paused status if there are no bugs and errors
X Closed
Project Manager (PM)
Rework Developer name (if Hotfix) Analysing Feedback and sending to Developer for Hotfix. Adding Rollback Request to Release-Ticket.
if needed rollback go to Release Ticket

(to step 3)

X Closed create a new ticket (if needed)

New-Release-Ticket

New-Release-Ticket
Steps Role & Status Assignee Description
1. Creating (QA creates the ticket) Quality Assurance (QA)
In Progress QA The tester completes a Release-Ticket and adds to this ticket other tickets that have been tested on the Stage
Ready to Install System Administration The Release-Ticket is ready to be uploaded to Life
2. Release System Administrator
Planning and Install System Administration Planning time for Release is every Thursday 1pm EST
Test Live QA Merge to Live
Quality Assurance (QA) Responsible tester for Release moves all tickets from Release-Ticket to Test Live status
Rework PM
In testing QA Choose Responsible person who’ll test and close Release-Ticket
X Closed
Project Manager (PM)
Rollback System Administration In case we need a Rollback, write a request and send a message to IT Helpdesk (if needed)
System Administrator
Rollback completed QA
Quality Assurance (QA)
In Progress QA The tester again completes a Release-Ticket and adds to this ticket other tickets that have been tested on the Stage

If errors are found at any of the steps, change the status and Assignee as Workflow recommend

If the task requires additional materials such as design or other, the Project Manager (PM) creates a Subtask

Execution of tasks without a ticket is not allowed.

In case of critical errors, it is allowed to formulate the problem in a different way.

When creating duplicate tickets, these tickets will be closed.

When changing Assignee, comments are written about what was done: NECESSARILY