Fast-tracking service deployment with Port: a plain vanilla internal developer portal

Introduction

There are many things you can do with an internal developer portal. Anything from API governance, just-in-time permissions, FinOps management and more. 

But what is the core use case for an internal developer portal? The core use case is ensuring efficient and effective software development lifecycles (SDLC) so that developers can focus on what’s important and not wait for TicketOps to deliver what they need. 

To deliver on this plain-vanilla approach to what’s inside a portal - we’ve built this guide that takes you through the thought process and actual work involved in implementing a basic internal developer portal. This requires no more than 4-5 hours of work. 

The primary objective of the use cases covered by this guide is to fast-track time to value by focusing on core operations developers need to accomplish within the SDLC process. This will provide developers with the ability to:

• Independently view and manage the deployment process in one place
• Reduce the time required to deploy code
• Enhance developer satisfaction and productivity
• Free up DevOps time for other critical tasks

Determining the internal developer portal’s key features 

Here’s a diagram of what we think needs to be in a plain-vanilla internal developer portal:

This internal developer portal MVP is structured around several user stories.This is the value each brings to the table:

1. Service scaffolding -user story

‍As a developer, I should be able to scaffold a new service quickly and efficiently.

Value: 

• Reduced cognitive load: Developers no longer need to remember every configuration detail, ask around for tribal knowledge, search docs or make guesses. They can simply follow a streamlined process, with baked-in golden paths.
• Increased autonomy: By enabling developers to scaffold services independently, we minimize their dependency on DevOps teams, speeding up the development process.
• Standardization: Ensuring that all new services adhere to organizational standards and guardrails improves software consistency and quality.

2. Catalog - user story

As a developer, I should be able to view all of my services, see data about their runtime, and understand the latest deployments.

Value:

• Enhanced visibility: Developers gain a comprehensive view of all their services, including critical runtime data and deployment history. This visibility helps in quickly identifying the state and health of services, facilitating better monitoring and maintenance.
• Improved decision-making: With access to detailed runtime data and recent deployment information, developers can make informed decisions about debugging, scaling, and optimizing their services. This leads to more efficient troubleshooting and performance enhancements.
• Operational efficiency: Having a centralized catalog of services reduces the time spent searching for information across multiple platforms. Developers can quickly access all necessary data in one place, streamlining workflows and reducing time-to-resolution for issues.
• Collaboration and knowledge sharing: A unified catalog promotes better collaboration among team members by providing a single source of truth. It helps new team members get up to speed faster and ensures that everyone is aligned with the latest service information.
• Historical insights: By understanding the history of deployments and runtime metrics, developers can track changes over time, analyze trends, and improve future deployments based on past performance data.

3. Test environment setup user story

As a developer, I should be able to create a new test environment and run a specific service with a specific version.

Value:

• Accelerated testing: Quick setup of test environments enables faster testing cycles, crucial for agile development.
• Version control: Developers can test specific service versions, ensuring compatibility and stability before production deployment.
• Less bottlenecks: By automating environment setup, we reduce bottlenecks and delays often caused by waiting for manual test environment configurations.

4. Promotion to production user story 

As a developer, I should be able to seamlessly promote a service to production.

Value:

• Streamlined deployment: Automating the promotion process reduces errors and ensures a smooth transition from staging to production.
• Risk mitigation: Defined and automated promotion workflows minimize the risk associated with manual deployments, improving reliability.
• Faster time-to-market: With reduced deployment time, features and updates can be released to users more quickly, enhancing overall product agility.

5. Service Rollback user story 

As a developer, I should be able to efficiently rollback a service from different environments.

Value:

• Error recovery: Quick rollback capabilities allow for immediate recovery from deployment errors, minimizing downtime and impact on users.
• Safety net: Developers have a safety net, knowing they can revert changes if something goes wrong.
• Operational continuity: Maintaining operational continuity with efficient rollback processes ensures that any issues in production can be swiftly addressed, maintaining service reliability.

Used together, these user stories cover the SDLC process.

Tech stack 

This blog assumes that the tech stack is GitHub, GitHub Actions, and ArgoCD. Port can do the same for other tech stacks, too.

You can read more about Port’s integrations here and use Port for any other integrations needed in case you have a different tech stack.

How to start building the portal

Now that we have a solid understanding of user stories, their inherent value, and the potential of the portal when integrated with the Software Development Life Cycle (SDLC), let's explore how to achieve it all.

To harness the full power of user stories and the portal within the SDLC, follow these steps:

Step 1: Bring SDLC data into the portal to create a software catalog

In this step, we will integrate Software Development Life Cycle (SDLC) data into the internal developer portal by exporting data from GitHub. We'll define software catalog entities using blueprints and establish the relationships between services and environments.

What to do:

1. GitHub Integration: First, follow the onboarding flow in Port to create a service Blueprint. After completing the guide you will have a Service blueprint, which will then govern the creation of all service entities in the software catalog.
2. ArgoCD:  Use the ArgoCD integration. To complete the plain vanilla portal example, you only need the ArgoCD application blueprint. Now you’ve added ArgoCD application entities to the software catalog.
3. Relations: Learn how to relate blueprints effectively using Relate Blueprints | Port, and relate the services to the ArgoCD application entities.

Example:

The image below is a visual representation of a running service called "Authorization US."

• Authorization US (Running Service): This is the main service that's currently active.
• Authorization:2.2 (Image): This shows the specific version of the service image being used, stored on AWS.
• Prod US (Environment): This indicates the environment where the service is running, in this case, the production environment in the US.

By visualizing these components and their connections, developers can easily understand the status and dependencies of the services they are working on. This visualization helps in identifying what is currently running, what version is being used, and in which environment it is deployed, ultimately contributing to a more efficient and effective workflow.

Step 2: Implement self-service actions for scaffolding new services and managing deployments

In this step, we will set up developer self-service capabilities, allowing developers to independently scaffold new services and manage deployments. This empowers developers to quickly create new services and handle deployments with minimal friction.

What to do:

1. Scaffolding New Repositories: Create a Self Service Action that scaffolds a new service using this guide:Scaffold a New Service | Port.
2. Create a Self service action that runs a deployment or a rollback for a service using ArgoCD Deploy and Rollback| Port (in this step we will also create the image blueprint)
3. Create a Self service action that promotes deployment to production using Port | Promote Deployment to Production (make sure to use the Image blueprint we have created in the previous step).

Here is what the developer self-service hub will look like once you complete these steps:

‍Step 3: Build Scorecards and Dashboards 

Now that we have gathered all the relevant data, established relationships, and enabled actions with the click of a button, it's essential to also have the ability to view and assess everything that matters. We need to ensure our entities align with our standards. For these specific reasons, Port provides Scorecards and Dashboards.

• Read more about Scorecards here and consider which ones you’d like to add
• Read more about Dashboards  and consider which personas would use them and what information you’d like to display.

Step 4: Launch to developers and gather feedback for continuous improvement

In this final step, we will launch the internal developer portal to the development team and gather feedback. This feedback is crucial for making continuous improvements to ensure the portal meets the developers' needs.

Expected Outcomes

By following these steps, you'll create a fully functional developer portal. This portal will streamline the work for developers, leading to several key benefits:

• Simplified deployment processes: The portal will make it easier to deploy applications, reducing the complexity and time required.
• Increased feature release velocity: With more streamlined processes, new features can be released more quickly.
• Reduced workload on DevOps teams: By automating and simplifying tasks, the portal will lighten the load on DevOps teams.
• Enhanced developer autonomy and satisfaction: Developers will have more control over their work, leading to higher satisfaction and independence.
• Simplified troubleshooting and understanding architectures: By visualizing the relations between service, image, environment and running service.
  

Conclusion

This guide shows how to enhance the developer experience by providing tools that streamline the SDLC. Within half a day you can use Port to build a meaningful portal that not only simplifies deployment processes but also empowers developers to take control of their workflows, ultimately leading to more efficient and productive development cycles.

Let’s continue to innovate and drive excellence in our development processes with Port!