On the Way to Build a Best-in-Class Release Process

By
,
This is some text inside of a div block.
minute read

At Branchspace, continuous improvement drives our efforts to create a best-in-class release process. Over time, we’ve refined our approach to ensure faster, more flexible deployments that meet customer needs.

When Dawid Bajor, Senior Quality Assurance Engineer, joined the team, the release process relied heavily on the need to synchronise all teams to prepare a new release. As our projects grew more complex, this system became less efficient, limiting our ability to deploy features quickly and reliably.

Key Improvements

To address these challenges, we focused on several key changes:

1. Prepare for one per sprint to daily releases: Change the purpose of the sign-off environment with a new release once per sprint to a mixed (internal and external) stable environment, released daily with verified changes, to check if we are capable or what we need to do to achieve it.

2. Empower Product Teams: Each product team is accountable for the full Software Development Life Cycle (SDLC), ie. the systematic process for designing, developing, testing, deploying, and maintaining a software product. This means our product teams are responsible for the successful merge and quality of the feature to spread and simplify new version preparation and single understanding of when the feature is done to resolve misalignments.

3. Architectural Changes: To make the deployment process more efficient, we also made architectural improvements that enable quicker, more flexible environment creation. This reduces complexity and makes it easier to scale deployments.

Next Steps

Looking ahead, we aim to enhance our release process even further with the following initiatives:

1. Ephemeral Environments for Developers: Ephemeral environments are temporary, short-lived computing environments created to perform specific tasks or tests and then automatically deleted once the task is complete. Giving developers the ability to create their own environments for specific tasks will improve flexibility and speed. This is crucial for handling multiple versions simultaneously.

2. Separation of Release Approvals and Hotfixes: We will separate release approval environments from hotfix environments, allowing for more efficient approval workflows while maintaining the ability to address urgent issues.

3. Feature-Specific Environments: Providing separate environments for each feature will enable customers to approve specific updates without waiting for larger deployments. This will streamline the approval process and reduce wait times for new features.

4. Multiple Versions of Modules: We are working towards the ability to deploy multiple versions of each file, which will further increase our deployment flexibility and help us better serve customer needs.

As Dawid concludes, "By continuously refining our release process, we aim to provide faster, more reliable deliveries with the flexibility that our customers expect." With these improvements, we are on track to build a best-in-class release process that meets both current and future demands.

Stay tuned—there's much more to come as we continue refining our release process to meet evolving customer needs.

The average airline web portals is not broken. It loads, it sells tickets. It technically does what it's supposed to do.

And yet, the experience feels tiring.

You notice it when you try to do something simple. Change a seat. Find your gate. Understand what happens if a flight is delayed. Suddenly you are scanning long pages, decoding airline terminology, clicking back and forth just to stay oriented.

The problem is not with the features, It is effort effort required in getting from A to B.

Airline portals still expect travellers to think like systems. To understand menus, categories, fare families, ancillaries, rules. But travellers arrive with something much simpler. Intent.

They want to get something done and get on with their journey.

This article posits that airline web portals should stop behaving like navigation systems and start acting as intent-aware decision environments. When UX is designed to reduce effort, adapt to context, and quietly support travellers at each stage of the journey, portals become calmer to use, easier to trust, and far more effective for airlines.

The basics still matter more than airlines think

Before talking about AI or personalisation, it is worth being honest about the fundamentals.

You can see that accessibility standards aren’t yet being applied and portals aren’t optimised for mobile, which results in performance drops. Navigation feels heavier than it needs to be. Search often works, but only if you already know what to ask and how the airline expects you to ask it.

These are not exciting topics, but they shape everything that comes after. If a portal is slow, confusing, or inaccessible, no amount of intelligence layered on top will fix the experience.

At Branchspace, we see this repeatedly. Airlines want to move faster, personalise more, experiment. But the UX foundation is not always ready to support that ambition.

Where portals lose traveller trust

The biggest UX issues are rarely dramatic, they are subtle and cumulative:

  • A vague error message that offers no next step
  • A long paragraph that hides the one thing the traveller needs to know
  • Three different words for the same concept depending on where you are in the journey
  • A mobile page that technically works but feels endless

In isolation these are small instances, but they compound to create friction for a user. And friction erodes confidence.

Travellers begin to hesitate, scan more carefully, and spend extra effort just trying to stay oriented. They stop trusting that the portal will help them when things go wrong. Good UX goes beyond delight, it is about reassurance.

Decision-making is the real job of UX

Every airline portal is a decision-making environment:

  1. Choose a flight
  1. Choose a fare
  1. Choose a seat
  1. Decide whether to rebook or wait

The role of UX is not to present all options equally. It is to reduce the mental work required to choose well.

That is where simple principles matter more than flashy ideas: clear visual hierarchy, familiar patterns, plain language, and progressive disclosure.

When these are done properly, travellers stop analysing the interface and start moving confidently through it.

This is also where intent-led thinking becomes powerful. When portals are designed around tasks rather than pages, complexity begins to fall away naturally.

What changes when you design for intent

airline web portal checklist items

When you stop designing for navigation and start designing for intent, the portal behaves differently:

  • Shift the focus to intent and the portal begins to respond in new ways
  • Search leads the experience rather than sitting in the background
  • Logged-in travellers with an upcoming trip see what they can do next, instead of being asked to explore

This is the direction we have been taking with platforms like Triplake by allowing the portal to respond to context, trip stage, loyalty status and behaviour.

Where AI actually helps and where it should stay quiet

AI has a role in airline UX, but it works best when it stays in the background rather than taking centre stage. The strongest AI-driven experiences are often the ones you barely notice, because the interface feels simpler and the path forward feels clearer.

That might mean routing a traveller straight to the right outcome based on a natural language query, or surfacing the most relevant rebooking option when a disruption occurs. In other moments, it is about removing repetition altogether, using known preferences to spare travellers from making the same choices again and again.

At its best, AI offers clarity, supports decisions without trying to make them on the traveller’s behalf. People still want to feel in control of their journey, they just do not want to work so hard to get there.

The portal is becoming a living interface

The most interesting shift we are seeing has very little to do with technology and everything to do with behaviour. Airline portals are gradually moving away from being static websites and towards adaptive interfaces that respond to where a traveller is in their journey.

Before the trip, the portal helps you prepare. On the day of travel, it shifts into a supportive role, surfacing the information that matters most in the moment. Afterwards, it follows up, closing the loop rather than simply ending the experience.

Making this work demands modular design systems, flexible platforms, and teams that think beyond individual pages and flows. It is not an easy change, but it is both achievable and increasingly necessary.