Mobile development and delivery at scale

The last thing mobile engineers want to do is fight with their infrastructure as they scale their teams. When infrastructure prevents you from releasing features faster, the problem will only continue to grow as you scale. Scott Campagna understands the struggles of scaling mobile development and delivery — “a general app update at FIS was somewhere in the realm of 3-6 months after we were done with development. So the actual delivery process was at least a half a year just to get one app update out,” recalls Scott.

Scott Campagna is the Head of Mobile Development and Delivery at FIS. For the last 12 years, he’s been part of the FIS mobile team, which creates a white-label mobile banking app that supports around 800 financial institutions across the US. In Scott’s session at the inaugural Mobile DevOps Summit, he shared advice for building scalable mobile applications. Let’s recap the discussion.

As FIS scaled its app and business, it ran into frequent infrastructure issues with its self-hosted Jenkins CI/CD. When building and releasing new features, the mobile team ran into issues because they relied on multiple teams to do various things — the development team, the management team, and the implementation team all needed to be involved in different parts of the workflow with manual handoffs at each stage.

“As you can imagine, you can’t really do very much in that kind of space. You have to be very Monolithic. You have to be very ‘waterfall’. You can’t have frequent app updates because you just can’t get them to your clients quickly and easily,” says Scott.

Building a solid foundation for your application

To build a mobile app that is easy to scale, you need to create a solid foundation. As Scott describes, a solid foundation makes your delivery process easier and faster. Your foundation consists of your app’s codebase, framework, and automation infrastructure. 

When building or updating your codebase to be scalable, leverage the common skillsets that everyone on the team has. For example, the FIS mobile team switched from two separate native codebases to a hybrid codebase using Angular-Ionic and Capacitor. This way, they managed one codebase to manage multiple apps and shared skillsets with the other teams that run on Angular.

When building your framework for a scalable mobile application, Scott suggests building a shared mobile framework. When building a mobile app, you need to build the app and the browser it goes in. In other words, “you’re sort of building a container, as well as the actual functionality that you want to provide for your end users,” says Scott. A shared mobile framework provides an SDK that acts as a common container that any team member can use. It provides app building, configuration, navigation, networking, and branding.

Building a modular pipeline

When you are working with distributed teams across different groups to scale your mobile app, different teams tend to have different priorities and needs. Scott recalls a time at FIS with long SLAs, where the team was building with hard-to-manage machines, and they couldn’t release or compile code fast enough.

When FIS moved to a modular pipeline, the workflow and updates became stable, easy to manage, and more easily scalable. With a modular pipeline, FIS can build features, compile them, and store them in their corporate library. Then, when they need to build an app for a client, they can take these features from the corporate library. These features can be anything from money transfers to bill payments to chatbots.

The modular model helps the FIS team ensure they can quickly and easily “build an app with ‘n’ number of features that have already been compiled and have solid code behind them. Part of that is making sure that we automate,” says Scott.

Automating your mobile workflow

When it comes to building and scaling a mobile app, automation is key to saving developer time, and it ultimately creates a better internal developer experience. Mobile tasks — such as pushing updates and running scans — take up a lot of time when done manually and can result in errors in code. 

Using Bitrise, Scott and the team at FIS automate their mobile workflows as follows:

• Framework automation that automates the base and SDK of the app, such as code signing (TIP: you can use the Bitrise Manage iOS Code Signing Step or the Android Sign Step to automate code signing)
• Feature automation that automates the end-user feature testing such as unit testing, UI testing, and security testing (TIP: you can use the Veracode Security Bitrise Step for app security testing)
• Integration automation that automates the testing of building multiple features together
• Client automation that automates the deployment process (TIP: use Bitrise Steps like the Fastlane Step for iOS App Store deployment)

💡TIP: Check out the Bitrise integration library to see the 330+ Steps available to tackle Mobile DevOps automation, app building, and more.

“We went from a manual process that would take someone [anywhere] from a couple of days to do all of the Steps to being able to push a button and have the app in the store and do all of those Steps in about 10 minutes. [Automation] is absolutely revolutionizing the way we work on a day-to-day basis. All of this automation is incredibly helpful and makes our lives significantly better… it just changes the entire way that we operate,” says Scott.

Building for mobile at scale

Building a scalable mobile app is not easy, and it requires someone on your team with the foresight and knowledge to create a foundation that can be easily scalable — specifically for mobile apps. If you’re like Scott and find yourself building with an antiquated mobile app release process, it’s not too late to update your infrastructure. Building higher-quality apps might involve updates to your codebase, framework, or automation infrastructure.

In his Mobile DevOps Summit session, Scott shared FIS’ previous process and how the team improved its quality. Before they updated the infrastructure and processes, even minor releases caused problems for end users and developers. When the FIS team switched to Bitrise, Scott recalls that the experience got better for their customers.

“We’ve had fewer issues reported by our banks in this complete rewrite of our applications… the complete re-platforming of our applications had fewer complaints than a minor release that we would do on our previous platform”, recalls Scott.

‍

Scott's session is now available on-demand if you missed it.