Simplifying Shopify app deployment with a new versioning system

Over the years, the Shopify app platform has added many new capabilities, allowing developers to extend Shopify for specific merchant needs. Many extension types were introduced, offering new ways to natively integrate into Shopify’s interfaces and processes.

However, different teams built extensions independently, leading to a fragmented developer experience. Each extension had bespoke workflows for configuration, development, and deployment. We commonly heard complaints from our developers about this lack of consistency.

The team’s goal was to unify the developer experience, and set strong standards for all extensions. I led the design effort for unified app deployment – a project focused on simplifying the versioning and release workflow.

Impact

This project had a significant impact on key metrics. Data was collected before launch and 1 month after launch, and the most noticeable changes to the developer experience during that time were from this project.

• +10% in retained active developers
• +16% in developers making their first API call < 1 day
• +14% in developers creating their first app from Shopify CLI (key part of our product strategy is to be CLI-first)
• +6% in satisfaction with the Shopify development environment
• +3% in satisfaction with the Shopify CLI

The problem: inconsistent worfklows

Before this project shipped, the app platform had a fragmented developer experience:

• Some extensions were managed in the dashboard, and others were managed in code.
• Some extensions were versioned independently, and some had no versioning.
• Some extensions needed to go through a review from Shopify before being published, and some didn’t.
• Some extensions needed to be published to be properly tested, and some had a custom-built preview mode.
• App configuration had become bloated with irrelevant settings and inconsistent patterns.

There was a lot of user feedback around these shortcomings. The platform had accumulated a lot of debt over the years, and now it was necessary to standardize these core workflows.

Previous workflow

Before this project shipped, extensions were independently versioned. You could edit an extension and push changes to a working draft for testing. After that, you could manually create a version from the draft, and then publish afterwards.

This workflow was designed years ago, when the platform only had dashboard-managed extensions. It wasn’t ideal for CLI-based workflows, given how many manual steps there are in the dashboard. It also didn’t scale well. Management becomes more tedious with each new extension added to an app.

Order! Order!

We moved toward a cohesive app model, where all app configuration and extensions are:

• managed in code
• previewable during development
• versioned together
• deployed with Shopify CLI

It was a challenge to retrofit all existing app configuration and extensions to follow these rules. I worked with many other teams to understand their use case and negotiate workflow changes. For every decision I made, I had to balance the benefit of the cohesive app model with the constraints of the legacy workflows.

Aligning on the right conceptual model

One of the biggest challenges in this project was aligning as a team on a conceptual model and terminology that made sense for our platform. There were many strong opinions on the team, which was difficult to manage. But I drove the discussion forward by identifying models and exploring user flows.

Deployments

My product and engineering partners initially pushed for a model that simply extended our current workflow for individual extensions. In this model, all changes from CLI and dashboard managed extensions would update the app’s working draft, and then you could manually create and publish deployments from the dashboard.

I explored the idea to understand their point of view, but ultimately it didn’t align with how other platforms worked. I pushed for us to look at common patterns in the industry and apply the ones that work for our platform.

Builds and releases

I explored a model similar to iOS and Android platforms and their app stores. The idea is that you have builds, which represent bundles of functionality, and releases, which represent public-facing app versions to users.

While this provides a clear mental model for developers, it added too much complexity for a large group of developers who build apps for individual stores, and don’t publish their apps on the app store. There are extra steps to get your changes out to users. Also, the deployment process couldn’t be automated, since publishing was only available through the dashboard.

App versions

Ultimately, I landed on the concept of app versions, which fit our platform needs and kept the workflow simple. An app version can go through review, which is required if you make certain changes. Developers can also roll back older app versions if they need to quickly fix an issue.

You can find the final model and designs earlier in this case study.

Reflection

This project was quite the journey with many UX, technical, and communication challenges.

As the UX lead for the project, I dove into the technical details with engineers, debated rollout strategy with product management, and worked closely with fellow designers to deliver this project. Our team overcame these challenges and we shipped a much more simplified and rationalized app development experience.

Shipping this project also unblocked many other projects that depended on this infrastructure. Now, teams at Shopify are able to build new extension types quickly, with many capabilities for free, out of the box.