Let’s take a look at our proposed solution. Once such an app version is tested and announced as stable, we update the app version and release it to production by triggering the manual stage in our GitLab pipeline from the same commit (merge) as the dev app was built (configuration differs). On merge to master a new build is automatically triggered, build number is incremented and the app is released to dev distribution channel This forces us to do small commits to master very often. We are utilizing so called trunk based development - we have only feature/fix branches that are merged directly to master (and features hidden behind feature toggles if needed).

This is an important part as versioning fits well to this particular architecture. GIT structure and release managementīefore we get to the versioning itself, I’d like to introduce how the code flows in our project from feature branch to production. Managing versioning manually would be a full time job for one person (including coffee breaks, of course), and two if we would count with a bus factor effect. We do several to dozen releases daily to dev and sometimes even several releases a weekly to prod. The project that I currently work on is a banking mobile application written in React Native and distributed for iOS and Android. You are like “mmgh, not again 🙄”, or even maybe NOT AGAIN 😤”Īlthough tolerable in small apps, this is a mandatory and repeated step that is very annoying and a great candidate for automation. Finally everything seems to work, all tests pass, the app is built and being uploaded … phew … when suddenly, the build is rejected by the store with a message stating that build with the same version/build number already exists. You are fixing that annoying bug in your fancy mobile application, looking forward to having it released asap (of course).

React native gradle version