Scaling automation can feel hopeless at times, with day to day activites feeling more like death from a thousand cuts than empowered and agile.
At the John Lewis and Waitrose Partnership in the automation team, new code or changes to existing code needed to be managed. These two activities were managed via Jira [https://www.atlassian.com/software/jira]. We used this tool to manage our automation development and therefore all development work was tracked through it. Both activities posed problems for the automation team:
- Requests to change production code (because of a bug or scope change) often originate from the business users who may not have Jira access. The option of providing Jira access across the business and providing ongoing maintenance and training was deemed too high an overhead. The business had G Suite, and so a Google Sheet was created and shared with the business for them to add their change requests to. This Google Sheet was then reviewed weekly and Jira tickets created by double typing the change request submission from the Google Sheet into the Jira ticket. This process was very time consuming, highly manual and meant that these change requests were not allocated to the sprint backlogs when they were raised.
- Requests to release code to production by the automation team members needed to be tracked as an development activity and for auditability ensuring the checks and balances were in place to maintain the Partnership’s code base and reduce technical debt. We initially approached this by creating a new “Release Request” ticket type in Jira and publishing guidelines to the team about which fields need to be populated and examples of the required level of detail. This process had inherent issues — the Jira requests were time-consuming to populate and even though an example ticket had been created (for the team to mimic), inconsistencies in the tickets started to emerge causing delays in the release activities and this area turned into a delivery bottleneck.
Our solution had two principal components: a Google Form to capture ticket information, and an associated Google Apps Script to execute ticket creation. Simplicity was at the heart of the design; as well as being simple for the user, we wanted the solution to be simple to code!
The high-level flow:
Once the user has submitted a form, the Google Apps Script code executes. It started off by using the respondent’s email address to find their associated Jira username if any. This was so the respondent can be added as the ticket’s Reporter, which comes in handy for allowing our internal team members to be automatically subscribed to ticket notifications.
Next: populate the ticket’s JSON body from the captured form data. Note that the empty string was used for the Assignee field which corresponds to the ‘Unassigned’ Jira user, highlighting the fact that anyone in our team can pick up the CR from the backlog:
Now create the parameters to send along with the payload (method type, content type, and so on), execute the request using the UrlFetchApp class, and voila! A ticket has been created with all the right information in all the right fields and without the user having to know anything about Jira.
The last thing to do was use the MailApp class to email the user with the ticket number, and a direct hyperlink if they have Jira access. Of course, there’s also a bunch of error handling throughout to ensure the user at least gets some meaningful response should the ticket creation not be successful. Given that the input was standardised thanks to the Google Form, the only times we see failures were he rare occasions when Jira was unavailable.
By abstracting the Jira input layer (via a Google Form) both requests (change and release) requests created a variety of benefits:
- Ease: Google UI more intuitive and recognisable
- Speed: The Google forms were quicker to complete compared to natively creating the tickets in Jira
- Access: Business users (via the Google Form link) can create Jira tickets
- Standardised: All Jira tickets raised via the Google Forms can have mandated content and a consistent look and feel
- Customisable: The Google Form can be created with explanations, examples and prompts to provide assistance and guidance
- Automated: Requests via the Google Form were immediately created in our centralised delivery tool, rather than the previous double entry solution
- Interactive: The Google Form can be built to populate fields from Jira and this bi-directional feature improves the form option further
The Google Form integration with Jira has been such a success that its was used internally by team rather than via the Jira UI to raise code changes. This in-house use of the Google Form furthers the standardisation and provides a working insight into the Google Form for further improvements/integration creating an effective feedback loop.