End-to-End Automated Release Management for Mobile Apps with GitHub, Jira, and Slack Integration

Managing release cycles efficiently and reliably is essential for mobile app development. In this talk, we introduce an end-to-end automated release management solution that combines GitHub, Jira, Firebase, Bitrise, and Slack to streamline every phase of the release process—from triggering to deployment. Our approach removes manual steps, enhancing collaboration, transparency, and traceability while reducing human error.

We’ll showcase a Python-based release script that integrates seamlessly with Jira to generate release notes from ticket data, automate changelog creation, perform release validations, and ensure safe branch management. The scripts, integrated into a Bitrise CI/CD pipeline, are designed to be triggered remotely. Through a cloud function hosted on Firebase and connected to a Slack channel, releases can be initiated by a simple Slack command. This setup allows anyone in the team to start a release from Slack, with every step of the process—from branch creation to final deployment—fully automated.

Attendees will learn how this system reduces friction in the release process, empowering developers, QA engineers, and DevOps teams to collaborate more effectively. This talk will be of particular value to teams looking to streamline their release workflows, enhance automation, and improve release consistency and speed for mobile applications. Join us to see how this robust integration can elevate your mobile app release strategy!

Driving App Reliability with Real-Time Monitoring and SLIs

In today’s always-on digital world, user expectations are relentless—apps must be fast, responsive, and available around the clock. But behind every seamless experience is a solid monitoring strategy. This session dives into how real-time monitoring and Service Level Indicators (SLIs) can make or break the reliability of your app.
We’ll explore real-world use cases where feature availability, latency, and error severity levels must be tightly monitored to avoid catastrophic user experiences—especially in apps handling real-time data, IoT, or safety-critical alerts. You’ll learn how to define meaningful SLIs, categorize errors by impact, and build a scalable monitoring framework that works across teams and environments.
Expect actionable strategies, lightweight formulas, and lessons from SRE practices that you can apply immediately—whether you're a developer, engineering lead, or just passionate about making your app bulletproof.

To scale or not to scale, that is the question.

Yesterday was five of you, today you can fill a stadium with all of you! Lengthy, old-fashioned, and overly complicated processes across teams? Immeasurable/infinite roadmap with non-stop stakeholders requests? Legacy code with a mixture of patterns? Code smell? Limited code coverage? High crash rate? Highlander ticket on your board?

No problem! You are not alone.

Team and process scaling is not a simple and smooth job if it's not reached gradually by a step-by-step incremental path. Accelerating this process due to business needs can bring a lot of problems at different company levels creating bottlenecks between people. Colleagues in the same squad, between different squads or across different teams can stop work properly introducing delays or loops across the flow.

So, where to start? How we can analyze and judge processes? How do we create a 'list of priorities and tasks? How we can achieve a good result and how do we measure it? How we can speed up our process and make team scale and at the same time find improve our code base?

This talk will guide you on our experience of how we survived (or at least we try to) in this ecosystem, and how we reacted to starting to create a good working env. At the end of the talk, you will have a good MacGyver-knife framework to use in similar situations which will help to improve your (and your team's) manner of working.

"The best way to beat a problem is to make it work for you." - MacGyver

This talk is based on the experience of my last 3 jobs across 8 years of experience I had the possibility to work in different organizations and face different problems.

The short version is a (20ish) light talk which can be easily extended bringing more examples to a full talk (40ish). The perfect audience for this talk is a mix one: engineers, managers, and PMs (not very much tech knowledge is required here) because the topic of the talk is investigating different (software cycle) layers.

Nitrogen in your (test) pyramid. (2) - Instrument tests for your design.

Unit, integration, UI tests are part of the famous test pyramid, different tools were used in order to full fill it, but still today there are lot of issues about how to execute it in a proper manner and how to sync all environments (local, ci, etc) in order to satisfy all the testing criteria, and having a good reports.

From IO 2018 with the announcement of project Nitrogen, Google'd like to "nitrogenize" our tests creating a single entry point and solve all issues
we had in the past. With October release of Robolectric 4.0 and androidx.test 1.0.0, both testing environments are converging on a set of common test APIs. Robolectric now supports the AndroidJUnit4 test runner, ActivityTestRule, and Espresso for interacting with UI components.

Let's see togheter how to organise different levels of our 'test pyramid', with a focus to the last news/releases in order ot be ready for the Nitrogen release.

Nitrogen in your (test) pyramid.

Unit, integration, UI tests are part of the famous test pyramid, different tools were used in order to full fill it, but still today there are lot of issues about how to execute it in a proper manner and how to sync all environments (local, ci, etc) in order to satisfy all the testing criteria, and having a good reports. From IO 2018 with the announcement of project Nitrogen, Google'd like to "nitrogenize" our tests creating a single entry point and solve all issues we had in the past. With October release of Robolectric 4.0 and androidx.test 1.0.0, both testing environments are converging on a set of common test APIs. Robolectric now supports the AndroidJUnit4 test runner, ActivityTestRule, and Espresso for interacting with UI components. Let's see togheter how to organise different levels of our 'test pyramid', with a focus to the last news/releases in order ot be ready for the Nitrogen release.

'Nitrogenize' your project with Mvvm, Compose, UTP - A killer combination for successful deliveries

Compose took on the table a new approach to developing in Android. Besides this great new framework, large portions of our apps won’t change at all, and Unidirectional Data Flow best practices should be used.

What will change in our project? Which patterns should we adapt in our app to work with these new techs? Is my app ready to be migrated with Compose? Let's see how use this new declarative UI framework in an already structured and organised project maintaining its own design pattern architecture.
What will be the advantages and disadvantages?

Unified Test Platform (UTP), best known as project code Nitrogen, it's another fantastic tech presented this year at Google IO. Let's see together what it is, why is so useful and why we should adopt it in our app.
We will use this extensible test executor to 'nitrogenize' our UI test suite covering some UI cases in our project. Let's scale together our test suite with Gradle managed devices in parallel using new test metrics, and finally, inspecting test results and possible failures by emulator snapshots.

After this talk, you will know if your app architecture is ready for Compose, you will be ready to transform your test suite into a more reliable scalable and productive env and you will speed up the delivery and the code quality of your project.

Nitrogen in your (test) pyramid.

Unit, integration, UI tests are part of the famous test pyramid, different tools were used in order to full fill it, but still today there are lot of issues about how to execute it in a proper manner and how to sync all environments (local, ci, etc) in order to satisfy all the testing criteria, and having a good reports.

From IO 2018 with the announcement of project Nitrogen, Google'd like to "nitrogenize" our tests creating a single entry point and solve all issues
we had in the past. With October release of Robolectric 4.0 and androidx.test 1.0.0, both testing environments are converging on a set of common test APIs. Robolectric now supports the AndroidJUnit4 test runner, ActivityTestRule, and Espresso for interacting with UI components.

Let's see togheter how to organise different levels of our 'test pyramid', with a focus to the last news/releases in order ot be ready for the Nitrogen release.