“Bitrise is too expensive?” is a funny question when you google the “bitrise” keyword. Seriously, it is not just funny, it is true! (for me 🥲).
We can’t negate that Bitrise is an awesome mobile CICD provider nowadays. They have a power weapons which opponents don’t: UI friendly pipeline editor! Instead of configure the pipeline by yml file or setup the jobs by scripts which take a lot of time to programing, validating, … With Bitrise, we just drag & drop then put the things we need!
Bitrise also maintain a power tool: StepLib . This is an open-source repository which would be used to setup the pipeline’s jobs, there’re many default steps were written by Bitrise team as well as from community contribution. Most of them are built on top of fastlane & bash scripts, actually, we can use fastlane to write our own pipeline but as a mobile developer, we mostly use native modern languages: Swift, Kotlin, Java. Fastlane requires the low level script Ruby language to program then would be a troublesome for some developers. One more reason is: we mostly setup the pipeline once so do it fast as fast possible to save time causes the Bitrise’s steps are highly appreciated.
Now we can see the Bitrise.io deserves the “expensive”. There’s an interesting you may miss: Bitrise team not only open-source the StepLib but also open-source the Bitrise CLI. It means you can run the Bitrise workflow on your own machine & fully access to the StepLib as well as the local web base of pipeline editor. A cheaper solution than Bitrise.io, sounds great? Since it is just a CLI so we still need a host to run it as well as communicate with the project repository, if you’re using Gitlab, Github, fortunately they also support a CICD solution so we can integrate with Bitrise CLI, for other provider such as Bitbucket, we can integrate via webhook which requires more additional steps. We can easily setup & getting started with Bitrise CLI from its homepage, I don’t repeat those steps here in this article.
We can easily migrate the Gitlab’s pipeline into Bitrise’s workflow as well as Gitlab’s jobs into Bitrise’s steps. For my project, I mostly wrote Gitlab’s jobs by fastlane then when migrate to Bitrise’s steps, I just choose the fastlane step & reuse my lanes accordingly. For the new jobs, I’ll try to use the Bitrise’s step if they’re available.
For the triggering flow, we can forward the trigger event from Gitlab CI to Bitrise CLI:
For other flows such as: push, schedule, chat, api … we follow the same approach. By this way we can fully manage the trigger flows by Bitrise CLI.
But wait, if Bitrise CLI supports everything then who would pay for the Bitrise.io? We mostly host by our own right? Life is never easy, there’re some essential steps are only available for Bitrise.io & workarounds:
- Caching: We can utilize the Gitlab CI to cache the build artifact.
- Storage: We can utilize the Gitlab package registry to store the output files.
- OTA deployment: We can use other services such as Firebase App Distribution.
There’re some more reasons to pay for Bitrise.io such as actively supporting, powerful build host machine, …
Conclusion:
As we can see, it is possible to combine the Gitlab CI & Bitrise CLI to obtain a powerful CICD solution with lower cost, nothing is perfect, there’re some limitations & workarounds still there for tradeoff, if you go with this approach, in the future you can migrate to Bitrise.io very quickly by uploading the workflow yml file. Is it worth to try? The answer depends on your project & team, consider wisely!
