Mastering Bitrise workflows for steady iOS app supply

Fast intro to Bitrise workflows

A Bitrise workflow is a set of Steps. When a construct of an app is working, the steps will likely be executed within the order that’s outlined within the workflow. – hyperlink

A step is an easy illustration of a construct process, they run one after one other within the workflow. Inserting a brand new one is fairly easy, there’s a + button in between each 2 steps, so you’ll be able to add a brand new aspect simply to the proper place with a single click on. The workflow editor is a very nice method of including, eradicating or arranging them, nonetheless, in case you are aware of the bitrise.yml file format, it may be quicker to edit that manually.

There are many out there open supply steps for Bitrise, additionally when you’ve got some actually particular want, you’ll be able to write your personal one by utilizing a easy shell script or golang. Anyway, it is extra seemingly that you’re going to discover what you are in search of within the step library, so don’t be concerned an excessive amount of about this, as a result of you recognize “there’s a step for that”.

Establishing an automatic nightly construct

After the fast intro, let’s dive into the technical particulars of my workflow setup. Often, I prefer to have an automatic nightly construct that creates an inside launch straight out from the dev department of the git repository. This fashion all the newest modifications are going to be out there for inside testing daily within the morning.

Git workflow:

I am principally following the succesfull git branching mannequin methodology created by Vincent Driessen again in 2010. It is actually good things, if you do not have a branching technique you must learn this text too, as a result of it is fairly a gem. 💎

Primary iOS Bitrise setup

After you arrange your iOS software on Bitrise, by default there’s a major workflow based mostly on the platform of your app. We’ve to vary this fundamental one a little bit bit. First, let’s rename it to nightly-build. I at all times use the next steps for my iOS builds, however not obligatory within the following order:

I like to make use of the Bitrise cache mechanism to cache Pods. In an effort to do that you simply have so as to add a brand new surroundings variable referred to as BITRISE_CACHE_DIR with the next worth: ./Pods -> ./Podfile.lock. Utilizing this method will velocity up your construct time in case you are coping with a lot of CocoaPods.

I additionally favor to make use of the set challenge quantity step to synchronize my construct quantity with my precise Bitrise construct quantity. The one factor I’ve to set is the Data.plist file’s path, which is normally positioned beneath the next place: $BITRISE_SCHEME/Property/Data.plist (could possibly be totally different for you).

At this level, I’ll assume that you just exported the required provisioning profiles otherwise you’re utilizing the auto provision step. That is the toughest a part of the job, however Codesigndoc is an incredible instrument, it might probably assist you a large number, so go forward & strive it. You will not remorse it. So at this level if you happen to’ve accomplished every thing proper you must have a workflow that builds with out errors. It is time to arrange a schedule for it. ⏰

Construct schedule

In case you press the Begin/Schedule a Construct button you’ll be able to allow the “Schedule this construct” choice. The method is basically easy, you’ll be able to enter the hour and minute values, and choose any given days to kick off your builds. It is also doable to set a particular workflow and if you happen to go to the superior tab, there will likely be a curl command on the underside of the record that can be utilized to start out the construct remotely. 👍

Set off on push as an alternative of scheduled builds

On the Triggers tab of the Workflow Editor, you’ll be able to map a department to a given workflow. If a push occasion occurs on that department a brand new construct will likely be triggered on Bitrise. This is available in fairly useful if you happen to do not need to depend on a set schedule, however relatively ship out new variations from the release-x.y branches.

Organizing your workflows

To this point so good, we have now a working steady integration service for our improvement course of. Nonetheless, if you would like to help extra supply strategies from a number of branches issues can get fairly difficult. The very first thing that you are able to do is to duplicate your whole workflow, however in the long run which may trigger some bother.

In case you comply with the standard git branching method you may have to create separate supply workflows for the nightly, preview and launch builds. As a substitute of copying the entire workflow, we’re going to create a chain of smaller workflows. This fashion if it’s a must to change a parameter in a step, you do not have to manually alter that setting in each different occasion within the duplicates. Right here is my answer. 🚀

Construct vs supply

The construct and the supply processes are fairly totally different. Constructing an artifact by the CI service could be separated from delivering the tip product. That is the very same strategy that I prefer to comply with in my setup. The one drawback right here is cell provisioning. Sadly, you’ll be able to’t merely resign your beforehand generated product, so the supply course of has to construct the ultimate signed iOS app by utilizing Xcode. This particular codesign subject is the explanation why I am going with 3 phases.

Preparation, supply, notification phases

So mainly these are workflows that may be triggered individually, however they are often linked collectively they usually all have totally different functions. Let me give some particulars.

Preparation

On this part I setup all the essential stuff that is required for the Xcode construct course of. It does not actually matter how Xcode will signal the ultimate product, the one purpose of this workflow is to make it possible for every thing is prepared for the precise construct course of. 🔨

Supply

The principle purpose of the supply course of is to construct & ship the signed software to its correct place. That may be a Bitrise.io deployment or a TestFlight supply utilizing fastlane instruments. I solely should duplicate this stage for each launch goal.

Notification

The final stage is all about notifying folks, so you will get notified through your most well-liked notification system a couple of profitable supply. In many of the instances I’ve a devoted Slack channel for construct standing notifications, so every thing goes there by default. 📩

Constructing by triggering workflows

As you’ll be able to see it is comparatively straightforward to separate the unique nightly-build workflow into smaller reusable items, and set off one workflow earlier than (or after) one other. Let’s do precisely like this. Listed below are the brand new workflow parts.

Preparation

• Activate SSH key (RSA non-public key)
• Git Clone Repository
• Bitrise.io Cache:Pull (for CocoaPods cache)
• Run CocoaPods set up (if I’ve pods)
• Bitrise.io Cache:Push
• Recreate Person Schemes
• Set Xcode Mission Construct Quantity
• Certificates and profile installer (or iOS Auto Provision)

Supply (nightly)

• Xcode Archive & Export for iOS
• Deploy to Bitrise.io – Apps, Logs, Artifacts

Notification

• Ship a Slack message (non-compulsory)

So really there are 4 workflows now, the 4th one is simply calling the preparation, All of the required workflows are literally referred to as earlier than the nightly-build. We are able to say that the nightly-build workflow is simply an empty container that is accountable for calling the opposite 3 (preparation, nightly-delivery and the notification) phases within the correct order. I favor having these names for the phases:

• preparation: generic reusable element
• nightly-delivery: builds & deploys ipa to Bitrise.io
• notification: generic reusable element
• nightly-build: scheduled (or triggered) builds from dev

Let’s make yet one more supply stage, that builds from the grasp department and uploads the artifact for TestFlight beta testing.

Preview (TestFlight launch) builds utilizing App Retailer join supply stage

Creating a brand new workflow for App Retailer join builds is method simpler with this setup. As you’ll be able to see the preparation & notification phases are kind of the identical, you solely should create a brand new supply methodology (preview-delivery) for the TestFlight builds. Right here is the overview of your entire workflow setup:

Preview construct

• Preparation
• Supply (preview)
• Notification

Supply (preview)

As I mentioned earlier than, you simply should duplicate the nightly-delivery move and change the deployment step with the Deploy to iTunes Join step, that’ll push your closing product to the proper place. On this step you will should set your Apple identifier and a few particulars concerning the supply, however that is fairly easy and there’s a fairly good description for every out there choice. At all times just be sure you have all of the required entitlements & code signing certificates for this supply goal too! 🔥

As you’ll be able to see having smaller reusable parts as an alternative of only one huge workflow clearly has some advantages. Repeatedly delivering your software could be actually efficient, particularly in case you are utilizing the proper instruments with the correct setup. I hope this tutorial will provide help to to have a greater expertise.

In case you’ve by no means heard about Bitrise earlier than you must positively strive it out, as a result of at the moment it is the most effective CI/CD options for cell software builders. 😉