Speeding up Product Development Feedback Loops at Shippo
As we grow and scale product development on our web properties at Shippo, receiving feedback from stakeholders early in the development process becomes increasingly crucial.
Getting feedback involves either taking screenshots or video recordings and sharing async with design or product management partners. If developers want to get feedback on interaction changes, then we would have to schedule a meeting and screen share local changes that have not yet made it into our QA shared test environment or wait until the changes are deployed there so they’re available to stakeholders. Debugging UI changes during development is also a bit involved since engineers have to pull a working branch and run it locally to then be able to interact with the changes. When changes are requested at this stage it becomes tedious to have to potentially revert them out of QA or have enough time to test them due to the impending production release deadline. We currently release twice a week which ultimately means developers have roughly a day and a half to test and review requested changes.
UI infrastructure team
To address these problems, Shippo Engineering recently spun up the UI infrastructure team which delivered a framework to achieve tighter in-development feedback loops and the ability to live debug UI changes on demand. The goal of the UI infra team is to address and solve pain points in our UI development workflows and processes as we grow and scale; like our CEO Laura Behrens Wu says — “build painkillers, not vitamins.”
What we built
The inaugural painkiller is a framework for dynamically serving the UI application per development branch. For example, when working on some changes to a button’s interaction, the changes can be pushed to the corresponding remote branch at which point our build tool, CircleCI, will deploy the bundled application into our storage service, AWS S3. The app is then accessible to our stakeholders via a subdomain on our QA environment and the new button changes can be interacted with and debugged using browser dev tools. We’ve now alleviated a ton of the pain points involved in gathering UI feedback and debugging, and can now introduce earlier testing into the development life cycle.
How dynamically served branch apps work
We use Jira to track development tickets, so when creating a work branch to address the ticket and to subscribe to the dynamically deployed app framework, we ensure that the branch name includes the ticket number, ie ENG-12345/feature-xyz.
We then added a step to our CircleCI workflow triggered when changes are pushed to the remote branch. CircleCI will then deploy the bundle into an AWS S3 bucket name spaced by the ticket number, ie s3://s3-bucket-url/ENG-12345.
To deliver the app to our stakeholders, we’ve set up a wildcard subdomain record on Cloudflare, our DNS provider. The entry looks something like this *.ui.goshippodevqa.com. A Cloudflare Worker handles requests going to that wildcard subdomain and proxies file requests to an AWS CloudFront distribution which fronts the S3 bucket origin.
In our example, we would access eng-12345.ui.goshippodevqa.com and the worker will redirect us to the corresponding branch application. Since our main UI application is a single page application, client side routes are kicked back by the worker to the index.html file and we let the client handle the routes.
This is one of the many initiatives we’re tackling on the UI infra team so we can make crafting UIs at Shippo painstakingly easy and quick to iterate on. If solving these kinds of problems resonates with you, we’re always hiring, so check out our jobs page to see if there are openings.
