IDP Release Plugin

For engineers across our enterprise, managing releases is often unpredictable, fragmented, and inefficient. The current release management experience lacks the integration, visibility, and automation needed to support a seamless development workflow. At best, teams navigate a mix of disconnected tools and ad-hoc processes; at worst, they face delays, uncertainty, and unnecessary friction that slow down innovation.

Our challenge was to transform release management into a cohesive, intuitive experience that not only streamlines the process but also lays the foundation for a fully integrated development environment. By embedding robust release management practices into our IDE/IDP initiative, we are creating a platform that empowers developers with stability, efficiency, and confidence in every release.

Approve releases with ease

Answer required audit/cyber requirements and approve your release without friction.

Action releases with confidence

Use the PAR activity trail to track Artemis activity and make a decision with confidence.

Communicate with asset owners

Communicate directly with release owners to gain context on the release.

Over the years, we have witnessed sustained growth in tools and processes that support the Software Development Lifecycle (SDLC). While that growth may be great, it has created an ecosystem of disconnected, yet required tooling and platforms that force developers to constantly context shift throughout their work day.

At the end of the day, we believe our developers want to maintain flow state and limit the cognitive load in orchestrating processes over disconnected tools.

Why did this effort start?

At the start of 2024, one of the core initiatives our CEO had set was to improve the developer experience as a whole and start treating internal developers the same way we treat external customers. In March of the same year, the Developer Experience team (DevX) began socializing the IDP, or Internal Developer Platform, which would give developers a one-stop shop for their development needs.

The key goal: "Automate everything but the creative problem solving in developing software." In the target state, developers spend the majority of their time in two primary screens, the IDE and the IDP.

About 7 months of planning and execution later, the IDP platform was stood up with mostly out-of-the-box features. After much deliberation, planning, and a build-vs-buy analysis, leadership decided to prioritize the Release Plugin. The ability for developers to ship code is paramount to the developer workflow, which makes it critical for an end-to-end IDP experience. Working with our product partners, we landed on an MVP definition for the capabilities and features the plugin should have at release.

To kick off this work stream we wanted to do some sense-making between the IDP Ideal, MVP, and current One Pipeline experiences for our three user types: ICs, Approvers, and Escalators.

Where do we start?

We needed to understand how all of the systems worked, so we had our product and engineering partners walk us through the experiences for each primary persona.

Over 2–3 days, we were able to better understand the OPL UI current state with regards to the release process.

To help ensure we were aware of any edge cases and designing for the ideal experience, I created a detailed wireflow depicting what goes on at each step.

We conducted eight 30-minute Jobs-to-be-Done interviews with developers to validate if we were on the right path with the flows we and our engineering and product partners had worked on.

JTBDs validated

• ▸Initiate Release: PROD release after a developer merges, pre-prod environment deployments, scheduling or deferring for later, and deploying specific versions
• ▸Approve Release: PAR Approver approves with one click, notifications go out to approvers and the team, and escalation is available when needed
• ▸Track Release: viewing deployment status across QA, Staging, Prod, and E/W regions, status notifications, and self-service deployment errors with clear next actions
• ▸Roll Back / Roll Forward: selecting a previous stable build, auto-rollback on failure, verification via testing, and feature flags on main that enable roll-forward
• ▸Audit / Review Release: release activity logged in an accessible table, with data captured to meet audit requirements

While some of these directions were out of scope for the beta release, our product and engineering partners were receptive to the designs and could see them being prioritized in the next PI.

Concept 1

• ▸Explored audit questions behind a modal, with CTAs sitting high on the page so users can't miss them
• ▸Release metadata is present, in front of the user
• ▸Release Workflow component is visible, but further down the page

Concept 2

Our product team informed us the audit questions had to live on the page at all times. So I explored how that might look on the UI, placing a release tracker component within the leftmost column of the layout, plus secondary metadata in that same column.

Concept 3: usability and concept testing

After refinement with our product partners, we landed on the following concept. We used a 9:3 layout, with primary actions and content in the middle and secondary metadata in an adjacent smaller column.

Usability testing was successful, but users identified opportunities to improve clarity and context across touchpoints.

“There were times where I was not sure if I completed a step…and there's no easy way to track that in the system.”

“A Slack link is definitely going to help because I am going to check in with my team. 'Hey what's this all about?' rather than go through extra steps.”

“I wish the fields would just auto-fill based on what I've done before. I shouldn't have to manually enter things over and over.”

Better contextual information

• ▸Users expressed the need for systems that adapt to their workflows and provide contextually relevant information
• ▸Alerts at the top of the page contextual to the user's role (PAR Approver, ESC Approver, Dev), putting CTAs front and center
• ▸PAR activity and release information now higher up, with detailed justification providing transparency and accountability

Consistent communication channels

Users were relying on external tools like Slack and email to supplement the IDP's lack of communication features. Developers spend a lot of time in Slack for communicating and troubleshooting, so I added buttons that allow approvers to immediately start up conversations with the release submitter.

Bulk-approve multiple releases

Users frequently operate on "autopilot" due to the repetitive nature of release approvals. I designed a feature where PAR approvers can quickly approve multiple releases without friction.

While this was out of scope for the beta release, our product and engineering partners were receptive to the designs and could see them being prioritized and implemented during the next PI.

To determine if our work was impactful, we needed a way to track how well our design changes were affecting users, while also confirming we were helping the business succeed.

The primary OKR our business partners are trying to meet with this initiative: reduce time spent in deployment by 7%.

For user metrics, we used our established Google HEART framework (HAT in our case) as the foundation. Our internal user-tracking software wasn't integrated into the IDP for the closed beta, so we were limited on what we could collect, and we relied on UMUX-lite, NPS, and surveys.

• ▸NPS gathers overall user satisfaction and qualitative feedback
• ▸UMUX-lite gathers data on overall usability and task effectiveness, or how well the product is meeting user expectations

Prioritize high-leverage items

There was a lot of work to be done, but it was important to prioritize what the enterprise needed rather than lower-impact features.

It's okay to be flexible

There were numerous pivots, including what I like to call "fire-drill designs," that shortened or lengthened timelines based on shifting needs and constraints.

Talk to users throughout the process

Many people believe you only talk to your users at the start, but constant developer feedback let us tackle real problems we wouldn't have otherwise found.

Scalability is ideal

We were able to contribute a few components back to the IDP design system, enabling other development teams to build with less overhead.