Support & DevOps Flow


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.



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.
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.


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.



A more complete example flow is as follows:

  1. User Submits a ticket
  2. Support attempts to provide self help or first line support to see if the issue can be fixed
  3. If the ticket can be solved, then there's no need to create a DevOps counterpart
  4. If not, a work item is created (New)
  5. This work item is either put on the backlog (New), or scheduled for development (Ready)
  6. The developer picks up the work item (In Progress) - requester is notified 
  7. The developer can go back to the requester for more information (Pending) - requester notified
  8. Requester replies - the developer is notified
  9. The developer starts / continues work on the work item (In Progress)
  10. The developer can't complete the work, or the issue is with a third party
  11. The developer puts the ticket on hold - requester notified again
  12. Third party responds - developer puts ticket back to active (In progress) - requester notified
  13. Developer completes the work Resolved (Dev Complete) - requester notified
  14. Pull request goes in, unit, integration and regression tests are run on the code
  15. Code passes and moves to build stage
  16. Build completes and Release is scheduled
  17. Release completes
  18. Release has automated testing ran on it
  19. Release has manual QA ran on it
  20. QA Fails - ticket goes back to Active as "not fixed" - requester notified (In Progress)
  21. Developer fixes the bug, go back to step 14
  22. Release passes Quality Assurance
  23. Release artifacts uploaded and tagged.
  24. Developer marks work item as Closed (Released) - requester notified
  25. Client gets release and upgrades
  26. Client discovers this isn't truly fixed, changes the ticket to In progress - developer notified
  27. Developer goes back to step 6 - or
  28. Client marks ticket as Solved - developer notified
  29. Case closed.






Was this article helpful?
1 out of 1 found this helpful



Please sign in to leave a comment.