Developer Self-service Actions

Self-service actions are often the first thing that developers associate with internal developer portals. There’s a good reason for that: self-service actions make developers more productive (and happier), by promoting autonomy along with guardrails and golden paths. 

Read: How internal developer portals pave golden paths

Self-service actions promote developer productivity and engineering standards

Enabling self-service developer actions achieves several goals:

• Provides developers with autonomy to perform routine tasks themselves (e.g., spinning up a dev environment) without filing tickets or waiting for other teams
• Lets developers provision ephemeral environments
• Lets developers act when on-call quickly and easily, such as requesting just in time permissions
• Ensures compliance with organizational security policies and best practices by requiring those from developers while abstracting tools and complexity
• Enables actions in context (e.g., a developer can see all runtime details on related microservices before scaffolding a new microservice)
• Provides a “golden path,” reinforced through the UI and role-based access control
• Enforces guardrails around organizational policies (e.g., TTL for ephemeral environments, approval processes)
• Supports engineering quality standards by enforcing them in the scaffolding phase

Self-service actions drive efficiency and developer productivity by allowing developers to execute tasks independently and asynchronously, without having to rely on DevOps teams. This is achieved through a curated UI in the developer portal – with an abstraction of underlying workflows configured by the DevOps or platform engineering team, guided by organizational best practices. 

Two keys to powerful self-service actions

Self-service actions should be loosely coupled (deliberately segregated) from the underlying infrastructure of the platform. This separation ensures that regardless of how the infrastructure evolves (e.g., if the underlying cloud resources, CI or CD systems are replaced), developers will still have the same experience built with a product mindset and designed to reinforce golden paths. For a variety of technical and security reasons, it’s considered best practice for the portal to remain loosely coupled from underlying GitOps platforms. 

Another important aspect of self-service actions is that they are reflected in the catalog, which is always kept up-to-date. In this sense, the catalog serves as a dynamic reference point—a repository for deployed services, environments, and other critical entities. Every self-service action affects catalog entities: creating, modifying, or deleting them. 

By aligning self-service actions with the catalog's status, developers gain informed, real-time insights into the development environment.

Categories of self-service actions

Self-service actions fall into three categories:

1. Create: This action initiates a provisioning process in your infrastructure to create a new entity.
2. Day-2: This action updates or modifies an existing entity in your catalog by triggering specific logic in your infrastructure.
3. Delete: This action removes an existing entity by activating the delete process in your infrastructure.

Often, the focus is on ‘create’ self-service actions such as scaffolding a new microservice, because these are real pain points that platform engineers are keen to address quickly. However, day-2 operations as self-service actions are also crucial; because:

1. Best practices require day-2 ops: day-2 operations can make sure you’re providing your developers with the means to always follow golden paths.
2. Day-2 ops go beyond a quick win and help to ensure the platform engineering team can achieve their primary objective. 
   

Examples of self-service actions

• Microservices SDLC (examples: scaffold a new microservice, add secret, feature flag, lock deployments, add package version)
• Developer environments (examples: spin up developer environment for 5 days, ETL mock data to environment, invite developer to environment, extend TTL by 3 days)
• Cloud resources (examples: provision a cloud resource, modify cloud resource, just in time permissions  to access cloud resource)
• SRE (examples: update Pod Count, update auto-scaling group, execute Incident Response Runbook automation)
• Data & ML (examples: train model, spin up remote Jupyter notebook, pre-process dataset, run Airflow DAG)

Check out our docs for further self-service actions examples. 

Self-service actions may also be asynchronous. Two examples are long-running actions and ones that require manual approval. It’s important that the portal be able to handle these – see “manual approval and run logs” below.

Manual approval and run logs

While self-service actions increase independence and efficiency of developers, certain critical processes may require oversight and approval from DevOps teams. In these cases, enabling manual approvals is crucial. Manual approvals require that developers ask for permission before taking certain actions, which helps ensure compliance over critical processes. 

For all actions developers take (whether or not they require manual approvals), run logs allow for visibility and enable them to detect and fix any issues easily – and understand the status of a long-running developer self-service action which is performed asynchronously. Run logs also make it possible to abstract the complexity that usually lies within the complete CI/CD pipeline log, providing a curated log of actions that a developer might actually care about.

Self-service actions to start with

Your approach to self-service actions really depends on the tasks that you most want your developers to be able to perform independently. 

Having said that, we believe that a good minimal value portal includes a set of basic self-service interactions that allow a developer to take a microservice from code to production.

The primary task for developers is to write code. However, they have many other responsibilities, and many of these can be addressed by a self-service MVP in the internal developer portal. The aim is to provide a comprehensive solution that takes developers from coding to production seamlessly. This approach ensures that developers:

• Avoid the need for frequent context switching.
• Understand the best practices and recommended paths.
• Get the abstracted data they need from the software catalog
• Can focus on core tasks without needing to master peripheral tools and technologies.
• Can independently complete most tasks through a streamlined process, eliminating the need for tribal knowledge or devops tickets.‍