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 operating, the steps might be executed within the order that’s outlined within the workflow. – hyperlink

A step is a straightforward illustration of a construct job, they run one after one other within the workflow. Inserting a brand new one is fairly simple, there’s a + button in between each 2 steps, so you’ll be able to add a brand new factor simply to the appropriate place with a single click on. The workflow editor is a very nice manner of including, eradicating or arranging them, nevertheless, if you’re accustomed to the bitrise.yml file format, it may be sooner to edit that manually.

There are many obtainable open supply steps for Bitrise, additionally if in case you have some actually particular want, you’ll be able to write your individual one by utilizing a easy shell script or golang. Anyway, it is extra probably that you’re going to discover what you are on the lookout for within the step library, so don’t fret 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 short intro, let’s dive into the technical particulars of my workflow setup. Normally, 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 obtainable for inside testing on daily basis within the morning.

Git workflow:

I am largely 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 it’s best to learn this text too, as a result of it is fairly a gem. 💎

Fundamental iOS Bitrise setup

After you arrange your iOS utility on Bitrise, by default there’s a main workflow based mostly on the platform of your app. We have now to alter this primary one a bit bit. First, let’s rename it to nightly-build. I all the time 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. With a view to do that you simply have so as to add a brand new setting variable known as BITRISE_CACHE_DIR with the next worth: ./Pods -> ./Podfile.lock. Utilizing this method will pace up your construct time if you’re coping with numerous CocoaPods.

I additionally desire to make use of the set undertaking 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 often situated underneath the next place: $BITRISE_SCHEME/Belongings/Data.plist (may very well be completely 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 a tremendous device, it will possibly assist you numerous, so go forward & attempt it. You will not remorse it. So at this level should you’ve finished every part proper it’s best to have a workflow that builds with out errors. It is time to arrange a schedule for it. ⏰

Construct schedule

If you happen to press the Begin/Schedule a Construct button you’ll be able to allow the “Schedule this construct” choice. The method is actually simple, you’ll be able to enter the hour and minute values, and choose any given days to kick off your builds. It is also attainable to set a particular workflow and should you go to the superior tab, there might be a curl command on the underside of the checklist that can be utilized to begin the construct remotely. 👍

Set off on push as a substitute 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 might be triggered on Bitrise. This is available in fairly useful should you do not wish to depend on a set schedule, however moderately ship out new variations from the release-x.y branches.

Organizing your workflows

To date so good, we’ve got 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 complete workflow, however in the long run which may trigger some bother.

If you happen to observe the standard git branching approach you may have to create separate supply workflows for the nightly, preview and launch builds. As an alternative of copying the entire workflow, we’re going to create a chain of smaller workflows. This fashion if you need 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 completely 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 observe 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 challenge is the explanation why I am going with 3 phases.

Preparation, supply, notification phases

So principally these are workflows that may be triggered individually, however they are often linked collectively and so they all have completely different functions. Let me give some particulars.

Preparation

On this section 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 be sure that every part is prepared for the precise construct course of. 🔨

Supply

The principle purpose of the supply course of is to construct & ship the signed utility 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 by way of your most popular notification system a few profitable supply. In many of the instances I’ve a devoted Slack channel for construct standing notifications, so every part 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 personal key)
• Git Clone Repository
• Bitrise.io Cache:Pull (for CocoaPods cache)
• Run CocoaPods set up (if I’ve pods)
• Bitrise.io Cache:Push
• Recreate Consumer Schemes
• Set Xcode Venture 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 (elective)

So really there are 4 workflows now, the 4th one is simply calling the preparation, All of the required workflows are literally known as earlier than the nightly-build. We will say that the nightly-build workflow is simply an empty container that is chargeable for calling the opposite 3 (preparation, nightly-delivery and the notification) phases within the correct order. I desire 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 another 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 manner 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 technique (preview-delivery) for the TestFlight builds. Right here is the overview of the whole workflow setup:

Preview construct

• Preparation
• Supply (preview)
• Notification

Supply (preview)

As I mentioned earlier than, you simply should duplicate the nightly-delivery movement and substitute the deployment step with the Deploy to iTunes Join step, that’ll push your ultimate product to the appropriate place. On this step you may should set your Apple identifier and a few particulars in regards to the supply, however that is fairly simple and there’s a fairly good description for every obtainable choice. All the time 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 a substitute of only one large workflow clearly has some advantages. Constantly delivering your utility could be actually efficient, particularly if you’re utilizing the appropriate instruments with the right setup. I hope this tutorial will show you how to to have a greater expertise.

If you happen to’ve by no means heard about Bitrise earlier than it’s best to undoubtedly attempt it out, as a result of presently it is the most effective CI/CD options for cell utility builders. 😉