Background
At LemonEdge, we are committed to evolving our support and development workflows to minimise disruption, whilst simultaneously providing fast and stable iterations of our platform. Our teams are working together to constantly improve our flows. This means a certain degree of fluidity, and so the content below is subject to change.
We have two workflows:
- LemonEdge Support (external facing)
- DevOps CI/CD (Continuous Integration/Delivery) - internal facing
We have integrated these workflows and below is an overview of this process.
Process
See the following diagram, which can be downloaded as an attachment (pdf).
The above is a diagram of a simplified flow; for brevity, this is the happy path - illustrating the most ideal workflow. In reality, work can bounce back and forth depending on the information provided in the ticket, or complexities that arise during the development process.
Statuses in the Support Portal are as follows:
| Open | In Progress | Development Complete | Pending | On Hold | Released | Solved |
Statuses in DevOps are as follows:
| New | Ready | Active | On Hold | Resolved | Closed |
They map as follows:
| Support Status | DevOps Status | Notes |
| Open | New | Support tickets are triaged by support, and created as new. Development then triage and allocate work to be picked up. Work can be backlogged or immediately actioned. |
| Ready | ||
| In Progress | Active | Developer is actively working on the work item. |
| Pending | On Hold | Pending means that the developer needs more information from the requester. On Hold means that the developer is waiting on an external dependency before continuing. |
| On Hold | ||
| Dev Complete | Resolved | Dev is complete, pull request, tests, QA, build and release. |
| Released | Closed | Development is closed, and the client has a new release containing the fix / new code. The user can then mark the ticket as solved. Support might do this after a period of time. |
| Solved |
As per the diagram, a developer changing the state of a work item is reflected in the support ticket status. The requester is notified by email and through the support site that the status has changed.
Example
A more complete example flow is as follows:
- User Submits a ticket
- Support attempts to provide self help or first line support to see if the issue can be fixed
- If the ticket can be solved, then there's no need to create a DevOps counterpart
- If not, a work item is created (New)
- This work item is either put on the backlog (New), or scheduled for development (Ready)
- The developer picks up the work item (In Progress) - requester is notified
- The developer can go back to the requester for more information (Pending) - requester notified
- Requester replies - the developer is notified
- The developer starts / continues work on the work item (In Progress)
- The developer can't complete the work, or the issue is with a third party
- The developer puts the ticket on hold - requester notified again
- Third party responds - developer puts ticket back to active (In progress) - requester notified
- Developer completes the work Resolved (Dev Complete) - requester notified
- Pull request goes in, unit, integration and regression tests are run on the code
- Code passes and moves to build stage
- Build completes and Release is scheduled
- Release completes
- Release has automated testing ran on it
- Release has manual QA ran on it
- QA Fails - ticket goes back to Active as "not fixed" - requester notified (In Progress)
- Developer fixes the bug, go back to step 14
- Release passes Quality Assurance
- Release artifacts uploaded and tagged.
- Developer marks work item as Closed (Released) - requester notified
- Client gets release and upgrades
- Client discovers this isn't truly fixed, changes the ticket to In progress - developer notified
- Developer goes back to step 6 - or
- Client marks ticket as Solved - developer notified
- Case closed.
Comments
Please sign in to leave a comment.