Boss: “Can you release a new version of
Developer: “ Yeah, sure. Hmm 🤔. Hey boss, how should I do that?”
Boss: “Just run
fastlane android alpha.”
Developer: “Yeah, but what about version? Shouldn’t I update it in those Gradle files?”
Boss: “No. Just run
fastlane android alpha.”
Developer: “And build number? We use it as a version code on google play.”
Boss: “Just run
fastlane android alpha and let’s have a coffee. ☕ I’ll tell you how it works.”
Recently I was thinking about how to use semantic release package for my React Native Apps that use Fastlane. I like the idea to absolutely not think about versioning or build numbers. And I like conventional commits.
Semantic release as a Fastlane plugin 🎉
That’s why I wrote this plugin. When you install the
semantic_release plugin to your Fastlane. You’ll be able to use these actions —
conventional_changelog. The code is open-sourced on my GitHub. This plugin is also used for releasing the plugin itself. So you can get inspired in the Fastfile!fastlane add_plugin semantic_release
Fastlane Config of React Native App
I will share with you a simplified config of my Fastlane. First of all, we need to find out what build number is next. Because we use build number as a version code on google play. This happens before all lanes. (Read comments in the snippet.)
iOS Alpha Deploy
Let’s go step by step from the end of the workflow.
- generates a changelog
- pushes a tag of the next version to the GIT repository
- sends release notes to the Slack channel
A format of the tag is always
[platform]/[flavor]/[semver]/[build_number]. It uses this tag to know what version was deployed last time. You might be wondering where we got the
next_version. It is generated by
analyze_commits action. We’ll talk about it later. Now, let’s talk about
Conventional Changelog Action
What do you get when you use
conventional_changelog? Look at the right side of the following picture. That’s what you get as a
string. The changelog grouped by types of commits.
It takes commits marked as a
fix and commits marked as a
feat, groups them and create this changelog in either
markdown format. You can set up section titles and also their order. You can set up which commits will be skipped and which will be included in the changelog. Everything is up to you!
In this step, we need to take the
next_version number and save it to Xcode files. We use already known Fastlane actions as
increment_build_number_in_plist. Easy with Fastlane!
Build — Android
Just short jump to the build of Android workflow. Maybe you are wondering how to set up the version in
app/build.gradle file. We send properties to the Gradle task. Build number and next version.
build.gradle I get these properties and set the default config for
Back to iOS. That’s the action where everything starts. First of all, it ensures that GIT status is clean. Then we split run to “On CI Machine” and “On Local Machine”. Just because we want to save some minutes on CircleCI. We usually deploy both
Android versions together. So we don’t have to install dependencies and check the code quality twice.
Analyze Commits Action
true if the version should be released. It also provides some useful variables to the
lane_context. So you have access to them everywhere in Fastlane. For example, the execution on the following picture would store
1.4.2 to the
lane_context[SharedValues::RELEASE_NEXT_VERSION]. We used it before in those snippets. 😉
This action is very useful when you have set up nightly deploys with CI. If there are no changes since the last night it won’t be deployed. Or if there are only changes that do not have any impact on the app itself. For example, just updating documentation or building scripts.
How do you release your React Native app?
Please let me know what do you think about this plugin. Would it be helpful for you? Do you need to adjust some parameters of the actions? Do you need to add some action to make your release absolutely automated?