PagSeguro provides online or mobile payment-based services for commercial operations. Their mission is to disrupt and democratize financial services in Brazil — a concentrated, underpenetrated, and high-interest rate market — by providing an end-to-end digital banking ecosystem that is safe, affordable, simple, and mobile-first, for both merchants and consumers.
Their mobile app, PagBank app offers a complete digital account, integrated with an end-to-end banking ecosystem that enables its customers to accept a wide range of online and in-person payment methods — including credit cards, debit cards, meal voucher cards, bills, bank transfers, bank debits, and cash deposits. The app had over 8.6 million downloads in the last quarter, more than 5 million new customers in 2020, and is one of the best-rated apps in its category.
Read our interview with PagSeguro's mobile team below:
Can you tell us a bit about your mobile development processes? What’s your team structure like and what kind of technologies you’re using?
Jonatas Teixeira: We have more than 40 agile teams, all working on Android and iOS native apps. Each team is responsible for a set of specific features, from design through implementation to operation.
We integrated our ecosystem in a way that we can track all the development life cycles of each delivery that we made and implemented technologies that help solve our day-to-day problems.
Flexibility is crucial: we have a modular-based app with a stack containing several technologies, such as Swift, Kotlin, Flutter, GitHub, JFrog, Bitrise, BrowserStack, New Relic, Firebase, and more. Continuous integration applies to the entire test pyramid. We have tests that cover UI, end-to-end, and unit tests — all of them integrated into our CI.
You also have a team dedicated to building mobile infrastructure. Can you expand on how this team was born and how this setup works in practice?
Frederico Oliveira: We have multidisciplinary teams developing and maintaining their services or features independently and autonomously. Following this strategy, we have some teams that are solely responsible for the common app structure, such as the architecture, delivery process, infrastructure, and taking care of its standards.
These teams were born out of the necessity to deal with the increasing number of engineers working on the app. Just to have a figure of what we were facing: we went from being a single team app to a product developed by dozens of teams in just 4 years. To keep up with such rapid growth, we had to create new tools and processes to guarantee that we could maintain our release cycle.
We release new versions of the PagBank app every two weeks and since the app’s launch, we’ve strictly followed this cadence. To coordinate the development, we use pull requests, which are validated on a CI that compiles and runs all checks that we have in place — to assure that a new piece of code won’t compromise anything in the app. On average 50 pull requests are merged per release, with nearly 900.000 unit tests and 800 UI tests being executed on each at least once.
On this scale, concurrency is a big issue, so we had to make sure that our integration could scale horizontally to absorb the large amount of code being merged. We made sure to automate everything we could to avoid human error and came up with clever ways to optimize these processes.
How do these teams collaborate with each other and what are the main advantages of this setup?
Frederico Oliveira: These teams are made up of professionals who not only know how to build and maintain this whole structure but also have in-depth knowledge of their respective mobile platforms. This guarantees that we are always in tune with the app's architecture and we have an infrastructure that validates that everything is working as planned.
The main benefit is that other teams don’t have to worry about anything — other than the challenges related to their own features and services. This makes us very efficient in delivering functionalities fast and reliably, which is the formula for our success.
Like many other mobile teams, you’ve gone through the evolution from self-hosted Jenkins to using Bitrise for your mobile app. How did this change your day-to-day job?
Vinicius Fonseca Pinheiro: When we started using Bitrise, we noticed that the environment became more reliable and we could keep the stack up to date more easily. We can now run builds on different OS systems and all the information is accessible to development teams.
What kind of impact has the switch had on your app development processes?
Vinicius Fonseca Pinheiro: Before migrating to Bitrise we had to manage our local servers to create policies, manually install updates, or change routines. As infrastructure is not the core of our solution, it was difficult to maintain. Since then, infrastructure is not a concern anymore and the environment has great uptime.
Bitrise is specialized for mobile platforms, like iOS, Android, and more — making it possible to run parallel CI/CD executions and speed up our features delivery. These days, we have an average of 700 pipeline executions per month for each platform. In addition to this, we’ve developed a very close relationship with their support team.
What were your main learnings throughout the migration?
One of the main learnings was to use the principles of software engineering in the CI/CD codes to treat the pipeline as software, rather than a set of scripts. Another important piece of advice is to try to always keep the CI/CD portable, cleanable, versionable, with low coupling and high cohesion, and the ability to reuse Steps across platforms. These things are immensely helpful in maintaining and evolving our CI/CD process. — Jonatas Teixeira
During the migration, we faced some challenges, especially when it came to keeping our bi-weekly release trains, without interruptions. Since our entire process was based on intranet tools, these had to be migrated to a cloud provider to allow everything to work in Bitrise. Besides that, it was necessary to externalize the base code and the libraries, and rewrite our groovy scripts, as well.
Are there any potential new ways you feel you would be able to use Bitrise in the future?
João Felipe Calvo Nunes: We are always thinking about ways to evolve — both from the product and the company perspectives. Since we have a great relationship, we regularly make suggestions for feature requests and improvements to the Bitrise team.
Today, we divide the use of resources into stacks. Our plan is to be able to make this division by prioritizing the type of flow, while still managing to weigh resources with other apps. This would allow us to use the resources more effectively, without jeopardizing priority tasks. We're also looking to try Bitrise's add-ons for insights to quickly analyze possible problems and see where improvements are needed.
We are also aiming to further accelerate our release cycles with at least weekly deployments to the app stores — for more business agility, a higher-quality app, and greater customer satisfaction.
If all of this makes a lot of sense to you and you’d love to be a part of the PagSeguro team and help democratize financial services in Brazil, check out their open positions.
If you'd like to learn more about building better mobile apps in the heavily regulated finance and banking space, download our latest report, Mobile product success in finance and banking, 2022 or sign up for our upcoming webinar How to win in mobile finance: A panel discussion.
If you’d like to find out more about how we can help you with building fintech apps, visit our landing page for finance and banking apps or request a demo here.
.jpg)
.jpg)
