Workflow
Understanding how the work transitions from one area to another is critical. Here we will list the main components that will help you develop and deploy your tickets.
DuroLabs follows an AGILE workflow.
There are three main worksets that we use to achieve this.
1. Jira
Jira is the main hub of Durolabs engineering. Here sprints will be created, roadmaps planned out, and tickets assigned. It goes without saying that it is important to turn on any notifications you may need.
In order to work more closely with the AGILE mindset, Jira has 7 stages or swimlanes
- TO DO
- IN PROGRESS
- CODE REVIEW
- QA
- STAGING
- TO DEPLOY
- DONE
Within a Jira Ticket you will have:
- Description
- Requirements
- Labels
- Original estimate
- Start date
- Time tracking
- Components
- Sprint
- Priority
- Zendesk Support
- Epic Link
- Fix versions
- Due date
It is important to view each aspect of the ticket to ensure accuracy of PR.
Ticket Discusssion
Tickets that have been assigned to you can be discussed in either Slack or Jira. It is important when starting a new thread or post, to reference the issue being discussed if applicable.
GitHub
You will work on and review tickets that have been assigned to you in Jira here. It is important to note that every ticket requires a review before it is pushed to QA.
Ticket Development
The development of a ticket will follow the stages setforth by the Jira swimlanes. Below you will find an explanation for each one:
1. TO DO
This stage of development is where new tickets are added or old tickets placed. It is a great source of tickets to be worked on. Whenever you find youself without tickets, this is the first place to look.
Also please note that tickets in a sprint are always stack ranked. So be sure to take the next ticket at the top of the To Do column.
2. IN PROGRESS
Ticket is moved to In Progress swimlane. At this stage, you are actively working on your ticket in your local environment.
3. CODE REVIEW
Ticket is moved to Code Review swimlane. When you have completed work on a ticket, you must have another fellow engineer review your code. You can do this by clicking 'request review' on the upper right hand side in the ticket page on GitHub. That ticket is then reassigned to the person who was requested to review it. This way we can always rely on the Jira swimlane to know what work we have to do.
4. QA
Ticket is moved to QA swimlane. This is also assigned to a person who is to QA the ticket. Typically this is the PM. The PM will do manual tests to confirm requirements are met and the implementation meets their own expectations (i.e. UI/UX)
When the ticket has been reviewed, it will be merged to the QA branch. Here it undergoes a series of tests to validate it's stability for production.
5. STAGING
Moved to Staging swimlane. When your ticket passes the tests in the QA branch, the feature branch is then merged into Staging. Where it will undergo further, in depth tests.
6. TO DEPLOY
Moved to Deploy swimlane. After a thourough inspection and trial by fire of tests, edge-cases, and more, the entire staging branch will then be merged into production.
7. DONE
Tickets are moved to DONE once the staging branch has been deployed to production. And all necessary database migrations have completed.
Your ticket is now closed, and can be moved into the Closed swimlane