💍 One Ring to bring them all

…and in the darkness guide them.

As mobile teams grow bigger, the ways of sharing the build during a release cycle increase with it. When it was just you and your friend building apps, you could just AirDrop the binary or put it in a shared folder for them to access. Now, with your team grown to include PMs, testers, designers, and other developers, you have to send the release candidates to a bunch of people via a multitude of channels across different integrations.

Tramline provides a centralized platform where teams can efficiently manage build distribution or simply monitor its progress within the release cycle. All the necessary information and actions can be accessed directly through Tramline, eliminating the need to navigate multiple platforms for these tasks.

After your CI system generates the appropriate binary file, we take that artifact and ensure its distribution across all the designated distribution channels, including the stores.

You can define the exact destinations for your build without any concerns about the technical aspects of sending it there. The interfaces across different integrations evolve quite often in the mobile world making your distribution process flaky even when you are using a very effective tool like Fastlane. We relieve you from the burdensome task of handling these operations and ensure your build reaches where it is supposed to.

For example, if you decide to incorporate Firebase App Distribution into your release cycle in the future, Tramline makes the integration seamless. With just a few clicks within the dashboard, you can effortlessly add Firebase App Distribution to your existing release workflow.

You can read more about the build distribution integrations we support in our docs.

👻 App Store and the Review Process

Everyone we know has their own App Store-review scary stories that they share with each other over the bonfire at camps. We, at Tramline, want to be the Ghostbusters to remove all your App Store woes!

Once your build is uploaded to TestFlight by your CI system, Tramline manages the entire process until release including:

• sending the build to external groups for beta testing

• preparing the store release with appropriate version, build, and release notes

• submitting the release version for review

• releasing the app with or without phased release once the review is approved

A simplified App Store release lifecycle in Tramline looks like this:

Due to current limitations with App Store Connect API, binary uploads to TestFlight are not yet supported. However, we are actively working on integrating this feature, and it will be available in the near future.

🎢 Stage Roll ‘em out

All crucial, if not all, features in mobile apps go through the cautious process of phased releases or staged rollouts.

Tramline handles staged rollout in App Store and Play Store differently due to the differences in the stores.

For Play Store, we allow the creation of a template for staged rollout and apply that template for every release cycle. It allows users to move the release through the different stages as and when they feel comfortable.

For App Store, it allows pausing and resuming rollout during the 7-day phased release process.

❄️ What else?

While Tramline aims to unify the user experience across various app stores as much as possible, it recognizes the importance of adapting to the distinct requirements and differences of each store.

For posterity and general knowledge, we maintain an ever-growing set of store quirks. It is compiled from our experience and scouring through developer forums, Stack Overflow, and various other sources of developer documentation.

✨ Future

We are actively improving the distribution mechanism for builds, and the following improvements are in progress and coming soon:

• Implementing triggers to monitor and automatically pause phased releases in the App Store based on configured metrics

• Automating staged rollout for the Play Store based on existing templates

• Enabling the upload of iOS builds to TestFlight

That’s all for this month, until the next train! 🚃

This is the first in this month’s edition of our product updates focused entirely on release visibility. We hope you like it!

🔮 Your app in the store at a glance

While you're busy shipping a new release, making it stable, and getting it out to different distribution channels, it's helpful to have a quick summary and make sure everything looks great on the storefront.

As soon as you connect your app, we start periodically pulling the current status of the app on the App Store or Play Store. This data is fetched and updated regardless of an active release cycle on Tramline.

🔔 Keep your entire team informed on Slack

Tramline will actively (and sometimes proactively) inform the team about important highlights during a release. You can connect Slack as a notification provider and pick a channel to send updates, such as:

A new release has been kicked off (and a release branch has been cut)

A release version has been rolled out to a percentage of users

A release was fully rolled out to all users

…and a whole lot more.

Refer to the docs on how to get set up with Slack notifications.

We are actively working on improving notifications and are also exploring other providers like Microsoft Teams and plain old e-mail for the near future.

👀 Find the pesky build that one user is complaining about

Your CI/CD workflow happily generates all the build artifacts. And then what? How does your team end up finding stuff when they actually need it?

Tramline treats a release as first-class, so we have a view into all the builds you have ever created. You can search builds by their number or name, figure out what release cycle the build belonged to, the specific CI workflow responsible for its creation, the various distribution channels it was sent to, and a direct download link for the build artifact.

Here’s the All Builds page in action, you can find it on your App page.

🕵️ Who did what and when

If you look under the covers, there’s actually a surprising amount of context and information created during a release cycle that is perhaps not self-evident. The point of shipping a release, of course, is to make forward progress, but it can be super helpful to take a look back at what all goes into a release and who is responsible for what. This isn’t just useful for auditing, but also for improving bottlenecks in the release process.

For every release, we maintain a detailed event log of all the important events. These are broadly divided into categories of — neutral notices, successful operations, and notable failures.

What else?

Get started today on Tramline, or book a call with us and we’ll help you automate and streamline your app releases. If you need support, find us here!

That’s all for this week, until the next train! 🚃

Open source & public roadmap

We're proud to announce that our codebase is now open source under the Apache License, Version 2.0. This means that you can not only access our source code, but also self-host Tramline inside your infrastructure and join our growing community on Discord! Get started by reading our self-hosting guide on GitHub.

Why open source though? We wrote about this in our 2022 recap but it bears repeating again:

• Software that sits in the infrastructure layer should come with a high degree of reliability and longevity. Open source software guarantees that to everyone.

• Workflow software is difficult to build in a closed room. After all, how can a small team design something that’ll fit a wide variety of workflows?

• We cannot simply hope for convergence of ideas and best practices; we will have to create a welcoming space. Open source communities have done this successfully for decades.

Of course, open sourcing the code is only one step towards building trust and fostering collaboration. We’re also making our roadmap public on GitHub which gives you visibility into upcoming features and improvements, and a chance to participate in our future.

Growth Plan: sign-ups now open

Our SaaS offering provides a hassle-free experience with priority support, seamless maintenance of integrations, and continuous updates. Today we're excited to open sign-ups for everyone along with details on our Growth Plan. As an integration-heavy platform, we understand it can get confusing to set things up yourself so we handhold all teams through the onboarding process.

Have questions before you get started? Book a personalized demo call with our founding team, and we’ll walk you through the platform.

Enterprise Plan: now available

For organizations with regulatory requirements and access constraints, we offer our Enterprise plan. We provide SLAs for support requests, tailored release process consulting, and managed on-premise hosting if needed. Perhaps you want to use an integration we don’t support yet? We can prioritize that for you!

If Enterprise is what you need, write to us at hello@tramline.app and we will get back to you promptly.

Welcome aboard!

We're thrilled to share these updates with our growing community, and we look forward to your feedback and continued support. Together, we will create a future that empowers mobile teams everywhere and accelerates the mobile DevOps ecosystem.

See you on GitHub and Discord!

🚃

In the early months, we spent a lot of time talking to mobile teams of all shapes and sizes — from award-winning indie developers, going all the way to large mobile platform teams generating millions of dollars of revenue every day.

A sign of a maturing platform is the differences between how teams operate, which is evident in the mobile app ecosystem. App teams work differently from each other, even when looking at similar team sizes, geographies, or industry verticals. Interestingly, backend and web frontend teams don't show this degree of disparity, even across organizations. Even at mobile-first businesses, backend and frontend teams display a high degree of operational maturity compared to their app teams.1

The tools and systems that support running an app-first business still have a long way to go. For e.g. PaaS systems (Render, Fly), IaC systems (Argonaut) or declarative CD systems (ArgoCD) cannot be directly translated to the world of apps, but it appears that there haven’t been enough attempts to figure out what apps need.

The struggles of delivery

The communities around Android and iOS have done a lot of work on architecture patterns and cross-platform frameworks, and it has paid off in many ways. At some level this was expected because high-quality software engineering practices look similar regardless of the type of software being built. Modern programming languages liberally borrow from each other, which in turn supports the ability to create similar higher-level paradigms as well — unidirectional data flow, functional core + imperative shell, etc.

However, patterns of release engineering have little in common with those of building software. Apps are not shipped like backend services, and backends are not shipped like web frontends. Backends and frontends are delivered through standard virtualized or containerized environments and consumed through standard client-side software (e.g. browsers), but apps reach consumers exclusively via centrally-controlled marketplaces. Evolution is slow because Apple and Google make so much money from their stores, and give the community little to no say in how these stores are governed and run.

Let’s take an example of what this causes: Unlike backends or web frontends, continuous delivery of apps to stores (and consumers) is not possible2, and neither is rollback of offending builds. As a result, app teams come up with some form of a release branching strategy — a way to stabilize a release candidate build, without blocking the team from continuing development work. Unfortunately, there are no community-accepted strategies to do this and in our conversations, we learnt of teams using needlessly complicated patterns. More than a few times, our discussion with engineers led them to understand during the call itself that they can simplify their process quite a bit!

Branching strategies is just one of the oddities of the app release engineering process. On-device UI testing, different distribution channels (internal groups, external groups), phased releases, manual and automated review processes, user reviews — all of these add complexity to an app’s release cycle.

On building a new product

This is the first time that we’re building a product business from scratch, and a lot of people asked us what that has been like. The widespread literature on startups is not wrong — it is an emotional rollercoaster and a mental drain. If you choose to go down this path, have a strong support system and don’t hesitate to ask for help!

Here are two things that stood out for us.

New market or No market?

We're building a product in a new space, and we had little meaningful data when we began. Much of our early work was based on instinct and experience — there was no way to distinguish the signals from the noise. As we had more conversations and received more realistic data, flaws in our thinking became apparent.

However, some of the ideas mutated so much that we started to question the original premise itself. Even now, we often ask ourselves, "Is this the wrong answer? Or is this not a problem?" which is both amusing and stressful.

Solutions vs Products

Throughout the year, people told us again and again that what we’re building is “not that hard to do” — which is true! That is one of the reasons why solutions created by internal platforms teams work so well, as long as the business can afford to invest in them.

However extracting a solution into a product that lots of people are willing to pay for, has very little to do with the solution itself. When one starts to build for the diversity of the real world, the same solution exponentially increases in complexity. The original solution may eventually be unrecognizable, but that's just the nature of product evolution. To deal with this dilemma, we continue to focus on the problem, not the shape of the original solution.

Opening up

All said and done, what we did for most of 2022 was discover, discuss, and develop the foundation of a release platform for mobile apps. At its core, Tramline enables teams to codify their app release policy. It gives them the ability to express their release workflow in a way that it can be run by anyone.

When a system like this is adopted by an organization, there is very little room for failure. We want to assure teams of the longevity of our software, and we hope to support a rich variety of processes. However, hope is not a strategy so we’re going to go a few steps further…

Tramline will be released and developed as open source software.

We’ve been thinking about this for some time now, and it is clear to us that this is the best way forward:

• Software that sits in the infrastructure layer should come with a high degree of reliability and longevity. Open source software guarantees that to everyone.

• Workflow software is difficult to build in a closed room. After all, how can a small team design something that’ll fit a wide variety of workflows?

• We cannot simply hope for convergence of ideas and best practices; we will have to create a welcoming space. Open source communities have done this successfully for decades.

📆 🚀

Over the next few weeks, we’ll lay the groundwork for community participation. We’ll pick a license that protects both, contributors and our SaaS business. We’ll document the system as it exists today, and we’ll create separate discussion spaces for the community and our customers.

On the SaaS side, we’re already in private beta! If you’re interested in joining the program, write to us at hello@tramline.app or simply reply to this email. You can also use our Calendly to book a quick call with us.