Mobile CI/CD is a build and release process to achieve quick and frequent release schedules for your mobile apps. These days, most mobile teams are using this process to remove the silos between teams to deliver their mobile apps quickly.
Mobile DevOps as a Service
When you are using a DevOps platform as a cloud-based service like Bitrise, it takes care of all the stages and processes that are required for mobile apps, from development to production, such as:
- Source Code management
- Artifacts management
- CI/CD pipelines
- Unit, Integration and UI tests
- Automation App Deployment
Steps are the heart of Bitrise’s CI/CD service: they are the building blocks of our Workflow Editor.
Steps are open-source integrations that let you do just about anything: they build, test, and deploy your apps, they can notify your teammates, open Jira tickets, and so much more.
Bitrise has over 330 Steps for all mobile platforms and all of them are open-source. A Bitrise Step is a specific task: for example, the Git Clone Step clones your Git repository at the start of a build while the Google Play Deploy Step can deploy your finished app to the Play Store.
You can endlessly customize your Bitrise Workflows by adding or removing Steps and create a CI/CD pipeline that fits your specific needs.
A Workflow is a collection of Bitrise Steps to implement a CI/CD pipeline, including different tasks for building, testing, and deploying your mobile app.
The Workflow Editor is where most of the Bitrise magic happens. You can configure every aspect of your Bitrise build here: all the tools, services, and integrations you want to use.
By setting up Environment Variables, both on the app level and on the Workflow level, you can manage all the files you need for your builds, including the code signing files.
How do Workflows work?
When you add your project to the Bitrise platform by connecting your code repository, the Bitrise Project Scanner will check your repository and help you with setting up the correct stack for your project
For example: if it’s Android it will give you a Linux (Ubuntu) machine with Docker support, but if it’s an iOS project it will be a macOS machine. In both cases, the machine will have all the required tools installed, ready to configure and use.
After completing the steps, you’ll get default workflows based on the type of app you’ve added to Bitrise.
The last step is to kick off your first build with this default workflow:
Customizing your Bitrise Workflows
Now it’s time to customize your workflow based on your needs, for example:
- A Workflow to run on every pull request or code commit
- A Workflow to run the UI tests every night as a nightly build
- A Workflow to deploy the beta version of our app
- A Workflow to deploy the production app to the app stores.
- Main Workflow to build the app and different sub workflows to run in parallel with different tasks to save the build time.
Moreover, you can customize the workflow as you prefer to apply your DevOps processes
How does it work?
Once the first build finishes on Bitrise, you can click on the Edit Workflow Editor button to switch to the Workflow Editor. In other words, it’s the designer view where you can edit your Workflows.
The Workflow Editor will be displayed, including the Steps in the default Workflow and other options to add new Workflows, rearrange, or delete existing ones.
On top of that, you also have different tabs to manage your apps such as Code Sign, Secret, Environment Variables, Trigger map, Stack, and the Bitrise YAML.
In the Workflows tab, you will notice that there are two default Workflows (primary and deploy). You can rename these Workflows or even delete them, if you’d like to create your own Workflows from scratch instead.
To customize the Workflow, let’s assume that you need to implement the following CI/CD pipeline.
You will need to add the new Bitrise Steps that match the above Workflow to implement this process.
By clicking on the (+ ) plus button in the Workflow Editor, the Steps windows will open, showing all the Steps. You can then search for the Steps you need.
For example, if you build an app for testing, add it to the Workflow, and configure it.
And the final Workflow will look like this:
If you need to create a new Workflow, you can do it by clicking on the + Workflow button and entering its name.
NOTE: it can be an empty Workflow or you can create a new Workflow based on one of the existing ones.
You can also combine more than one Workflow in the same Workflow using these buttons:
And in the trigger map you can specify which Workflow should run, based on the Gitflow. For example on every pull request, we need to run the CI Workflow, but on tags, we need to run the CI/CD, and so on.
Finally, customization options give you more flexibility to be able to implement your own CI/CD pipelines, based on your specific needs, and help your team scale and expand your app.