Mastering Bitrise workflows for steady iOS app supply

Fast intro to Bitrise workflows

A Bitrise workflow is a group 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 an easy illustration of a construct activity, 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 suitable place with a single click on. The workflow editor is a very nice approach 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 when you have some actually particular want, you’ll be able to write your personal one through the use of a easy shell script or golang. Anyway, it is extra possible that you’re going to discover what you are on the lookout for 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 short intro, let’s dive into the technical particulars of my workflow setup. Often, I wish 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 every single day 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 great 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 software on Bitrise, by default there’s a main workflow primarily based on the platform of your app. We have now to vary this fundamental one somewhat bit. First, let’s rename it to nightly-build. I at all times use the next steps for my iOS builds, however not crucial within the following order:

I like to make use of the Bitrise cache mechanism to cache Pods. So as 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 if you’re coping with numerous CocoaPods.

I additionally favor to make use of the set venture 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 positioned beneath the next place: $BITRISE_SCHEME/Belongings/Data.plist (might be completely different for you).

At this level, I’ll assume that you simply 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 software, it might probably assist you numerous, so go forward & attempt it. You will not remorse it. So at this level for those who’ve completed all the pieces 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” possibility. The method is de facto 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 attainable to set a particular workflow and for those who go to the superior tab, there might be a curl command on the underside of the listing 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 for those who do not wish to depend on a hard and fast schedule, however fairly ship out new variations from the release-x.y branches.

Organizing your workflows

To date so good, we’ve a working steady integration service for our growth 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 hassle.

If you happen to comply with 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 it’s important 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 means of the CI service could be separated from delivering the tip product. That is the very same strategy that I wish to comply with in my setup. The one downside 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 through the use of Xcode. This particular codesign situation is the rationale why I’m 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 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 would not actually matter how Xcode will signal the ultimate product, the one aim of this workflow is to be sure that all the pieces is prepared for the precise construct course of. 🔨

Supply

The primary aim 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 must duplicate this stage for each launch goal.

Notification

The final stage is all about notifying individuals, so you may 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 all the pieces 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 truly 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 will say that the nightly-build workflow is simply an empty container that is answerable 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 approach simpler with this setup. As you’ll be able to see the preparation & notification phases are kind of the identical, you solely must create a brand new supply technique (preview-delivery) for the TestFlight builds. Right here is the overview of all the workflow setup:

Preview construct

• Preparation
• Supply (preview)
• Notification

Supply (preview)

As I stated earlier than, you simply must duplicate the nightly-delivery stream and substitute the deployment step with the Deploy to iTunes Join step, that’ll push your remaining product to the suitable place. On this step you may must set your Apple identifier and a few particulars in regards to the supply, however that is fairly easy and there’s a fairly good description for every obtainable possibility. At all times just remember to 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 huge workflow clearly has some advantages. Repeatedly delivering your software could be actually efficient, particularly if you’re utilizing the suitable instruments with the correct setup. I hope this tutorial will assist you to to have a greater expertise.

If you happen to’ve by no means heard about Bitrise earlier than it’s best to positively attempt it out, as a result of at present it is among the finest CI/CD options for cell software builders. 😉