Making applications manageable as environments multiply
- Timeline
- 10 weeks
- Platform
- Web application
- Team
- Product Designer (Me)
Product Manager
Developers
TL;DR
Devtron lets teams deploy applications across multiple environments. Common configurations in an application are owned by application owners, whereas environment-specific configurations are owned by environment owners. The dual ownership model broke down once an environment owner overrode a configuration file.
I owned the design for this workflow, arriving at a solution that removed the conflict between the 2 personas. A constraint during the project led me to redesign the configuration management interface from scratch leading to an improved overall experience.
Context
Devtron is a software delivery platform for Kubernetes with Open-source and Enterprise offerings. Managing and deploying applications across multiple environments is one of its most used and most complex workflows.
Signals & Research
The problem surfaced from within before we went looking for it
Internal signal
Devtron's internal DevOps team
Managing deployments to 20+ enterprise customer environments. First to report the friction of working at this scale.
External signal
Enterprise customers
Enterprises using Devtron to deploy their software to customer infrastructure, struggling to manage configurations at scale.
I spoke to people from both groups, to understand where the configuration management experience was breaking down and why.
“When I need to update a common configuration value across environments, I either have to change each one manually, or coordinate with environment owners.”
“Making a change across config files (Deployment Template, ConfigMaps, and Secrets) involves a lot of clicking around and scrolling. It's not hard, just more effort than it should be.”
“Working across multiple environments always feels like there's a lot going on. I'm never fully sure I'm looking at the right one, and I worry about making a change in the wrong place.”
“I ended up creating a separate application for each environment just to keep ownership clear and prevent errors. There was no obvious benefit to managing them together, so I went with what felt safer.”
What was the problem?
Devtron lets teams deploy the same application to many environments. Configuration is not owned by one person. It splits across two roles with different scopes.
One application owner. Multiple environment owners, each responsible for a few environments.
Existing Configuration Management Model
Every environment starts by inheriting a base configuration. The moment an environment owner overrides a file to make a local change, that file forks from the base for good.
Once overridden, an environment file stops receiving updates from the base file.
This broke both roles at once. Environment owners had to take over an entire file just to change one field. Application owners lost the ability to push a shared change once it had been overridden anywhere.
Dual Ownership Challenge
Two user groups, each doing their job well, ended up working against each other.
Based on the research, I arrived at a dual ownership challenge which distilled the signals and grounded the problem in user pain points.
Application Owner
Owns fields shared across every environment: image tags, feature flags
GOAL
Apply common changes to all environments of an application.
CHALLENGE
Overridden configuration files do not inherit changes from the base file. Needs to coordinate with environment owners to update overridden files.
Environment Owner
Owns fields scoped to the one to three environments they are responsible for: resource limits, policies, connection strings
GOAL
Change only the fields specific to their environment.
CHALLENGE
Overriding a single field forks the whole file. They end up owning fields they never meant to touch, and stop receiving base updates on all of them.
Heuristic Evaluation
UX Audit to identify flaws in the existing interface and experience
I also conducted a heuristic audit of the configuration management interface and experience to uncover any usability issues that would multiply the challenges of working across multiple environments.
What are we solving?
User Goals
Application owners and environment owners should be able to manage respective configurations without stepping on each other's toes
Business Goals
Reduce engineering time spent updating and maintaining common configuration across environments
Increase adoption and trust in Devtron's configuration management feature
How might we…
enable application and environment owners to manage the configurations they own for multi-environment deployments, without interfering with each other's changes, quickly and reliably.
Solution directions
Collaborated with PM and teammates to brainstorm ideas
01.Approval Inbox
Any change to a base file shows up as a notification at overridden environment files. Environment owners can accept or reject the change. Accepting a change applies it to the overridden environment file.
- Application owners can push changes across environments
- Manual review by environment owners scales poorly
02.Bulk Propagation
Application owner changes a value in the base config, the system scans every environment for copies that have overridden that same file, and pushes the identical change into those overridden copies automatically.
- No approval overhead/dependency
- Can silently overwrite an intentional override at the environment level.
03.Patch-based override
Environment owners only define the fields they want to override at the environment level. The override is applied as a patch on the base file to get the final configuration state.
- Environment owners define only what they need
- Undefined values always remain in sync with base
- Patches can misapply if field path or base structure changes
Selected Direction
Patch-based overrides let both personas win. We defined the following modes that can be used at the environment level.
Patch-based OverrideNew
Environment owners define only specific fields as override. Inherit rest fields from base configuration file.
Replace-based OverrideExisting
Environment owners own the complete env configuration (existing behaviour). No inheritance from base.
No OverrideExisting
Environment files with no override inherit all changes made to the base file.
UI Explorations
Exploring interface and interactions to translate the selected direction
01.Extending existing interface
I tried incorporating the merge strategy concept into the existing user flow with minimal changes
User Testing - Takeaways
Showed the initial explorations to internal & external users to validate the concept without getting into visual details
The merge strategy concept resonated. Users understood the value of overriding specific keys while inheriting the rest.
Users needed to see the inherited configuration while writing an override. Working without that reference felt like working blind.
Some users mentioned running --dry-run in the terminal to preview the generated Kubernetes manifest before applying a YAML. Ability to see that in the tool would be valuable.
Seeing only the patch values was not enough. Users wanted to preview the merged result before committing to it.
02.Rethinking interface and interactions
For users to work confidently with overrides, they needed visibility of all three states: what is inherited, what they are overriding, and what the final merged result will look like.
3-tab Model
I came up with a tab-based interaction model that gave the required visibility and confidence
Inherited
Read-only view of the config being inherited.
Override
Allows user to override a config file and set the desired merge strategy
Dry Run
Preview the final merged config and generated Kubernetes manifest
The Constraint
The existing interface could not support this model
ConfigMaps and Secrets previously expanded inline in a scrollable container. Adding three tabs to each inline expansion would have made the interface unmanageable and the experience complex.
03.A file-browser interface that solved multiple problems at once
Inspired by GitHub's file navigation, I redesigned the configuration interface around a environment centric experience with each config file in its own dedicated view. The dedicated file view gave way for a clean integration of the three-tab interaction model.
- 01
Flat file list
Replaced the nested accordion. Every file visible without expanding anything, similar to Git tools and IDEs
- 02
Override state at a glance
Each configuration file shows whether it is inherited, overridden or created at the environment level
- 03
Environment switcher
Quick switching between environments while preserving the selected configuration file context
- 04
Dedicated file view
An isolated view for each configuration file gave way for a clean integration of the 3-tab model
- 05
Strategy selector
Merge strategy selector to configure how the configured environment override is treated
Drag to compare the old configuration screen with the redesign
The complete experience
Environment Owner
Needs to change 'CART_PORT' value to "8081" for 'cart-service' application on 'production' environment
- Navigates to the ConfigMap for 'production' environment. Sees the ConfigMap is being inherited from base configuration
- Navigates to the override tab → Create Override
- Selects merge strategy → 'Patch'
- Configures desired key:value as the override
- Navigates to the Dry run tab → Verifies final merged values → Saves Changes
Application Owner
Needs to enable guest checkout for all environments of 'cart-service' application
- Navigates to the ConfigMap in 'Base Configuration'
- Changes the value for 'allow_guest_checkout' to "true" → Saves Changes
- The change is propagated to environments where ConfigMap is inherited or overridden with 'patch' and allow_guest_checkout is not overridden
Release Plan & Outcomes
Broke down the release into 2 phases to push incremental changes and get early feedback
Shipping the UI overhaul first gave the development team a well-scoped piece to build while I finalized the UI states, edge cases and interaction details for the merge strategy
Phase 01
The layout overhaul
Flat file list, dedicated environment and file views. Shipped first as an independently valuable, well scoped piece.
Outcome
3 → 2
Clicks to access a ConfigMap or Secret file
3 → 1
Clicks to access same file in different environment
“The UI now feels fast and familiar. This is how it should have been.”
Phase 02
The override strategy
Patch and Replace based overrides at environment level. Built on top of the updated UI layout.
The adoption bottleneck
Migrating to 'Patch' based override was a manual file-by-file effort across every environment.
Idea
One-click migration to convert overrides from ‘Replace’ to ‘Patch’.
Drawback
Manual clicks remain inefficient at scale, as users must still trigger the migration file-by-file for every environment.
Selected Solution/Bulk Migration API
A bulk migration API to migrate all desired configuration files to ‘Patch-based override’, eliminating the need for manual file-by-file migration.
Outcome
100%
Internal adoption in 2 weeks
>60%
Enterprise adoption in 45 days
“Environment configuration management is extremely streamlined now. Common configurations are very easy to manage and update.”
Reflection
What started as an informal conversation with a few internal users, uncovered some real pain points. A few things stand out as the most important lessons from this work.
Constraints can force better outcomes
The old interface could not hold the new interaction. That constraint forced a rebuild that also fixed long standing UX issues.
The right solution is not always a screen
A one-click migration via the UI was a good idea that left a bottleneck at scale. An API solved it more effectively.
