Skip to content

iOS On-Demand delivery architecture via slack/jenkins/fastlane. Demo project for: #PragmaConf2019

License

Notifications You must be signed in to change notification settings

d4r1091/on-demand-delivery-fastlane-slack

Repository files navigation

On-Demand delivery for iOS via Jenkins and Slack

Slack a message to get an app!

Thanks to

Purpose

  • Automate, or better delegate, the process of building and delivering that specific version of your app to a different source.
  • Make your app delivery more reliable
  • Save you time, a lot.

Introduction

Let's provide some context and real use-case scenario this architecture can be applied to.

Imagine having your App to match:

  • different theme/style
  • specific add-ons
  • different settings

The codebase will be the same, apart from some details.

You can come up with many ideas like:

  • building up a Framework and import that framework to each specific Xcode Project (or Workspace of course)
  • having different targets in one Xcode Project (or Workspace of course)

In this example we've chosen the second option, the targets one.

This is applicable to any project of any scale (even single-target project). The example is meant to cover the scenario in which more than an App delivery is involved.

Tools 🧰

Can be an instance of a Mac Machine somewhere as well as your in-house Mac machine.

Getting started

In the machine you would like to set-up your architecture...

Make sure you have the latest Xcode command lines tools Run:

xcode-select --install

Create project and initialize Fastlane

dotenv

To facilitate our work of mix and match we introduced the .env environment as recommended from the fastlane doc, storing environment that is target specific.

Dotenv wants you to make files following its convention, which is absolutely the way you should go for if you have one project to maintain. In the case studied and explained in the talk, I've mentioned about different environment, projects, variables, so I had to adapt the dotenv loading to be controlled manually. That's why in the project we'll show how to tailor it having:

  • target
    • we will call it partner within the dotenv structure
  • build configuration (development, staging, uat, production)
    • we will call it environment within the dotenv structure

If you'd like to make your dotenv files encrypted, follow secure_dotenv project

Reminder 🚨: in the example Fasfile is used the manually loaded procedure.
  • Create your dotenv files following the standard convention

    • .env (root file)
    • .env.development (development file) .env.staging and so on…
  • Create your dotenv files following the manually loaded files

    • .env (root file)
    • [partner]-[environment].env (i.e. - partnerA-Staging.env) and so on…

Populate .env file

Open the newly created .env file and paste this line:

ENV_VAR_TEST=Hi there I'm an EVN VAR loaded from the root dotenv file 😁 !

Testing time 🤞🏽👨🏼‍⚕️

Lets see if our journey is going well, let's try to launch a fastlane action from the terminal. Reminder: you must be in the project directory.

bundle exec fastlane test_dotenv

That's how the output should look like:

Creating a subsidiary Fastfile

Code separation is always a good practice. We are going to manage our Fastlane's lanes having more or less the same approach. In the example there are few more Fastfile to be imported.

  • BetaDeliveryFastfile: manages the beta delivery through services like Fabric
  • PartnerDeliveryFastfile: exsclusively delegated to handle partner facing / production-like releases
  • ArchiveFastfile: contains the lane that manages the Archiving process (creates .ipa)
  • CodeSignFastfile: manages the process of manually codesign the app processing certificates and provisioning profiles
  • AuxiliaryFastfile: contains lane helpers which don't necessarily belong to any of the above

Having the three Fastfiles in our project, by executing the public lane:

bundle exec fastlane test_external_fastfile_import

In this test we will load the Partner and Beta Delivery Fastfile The result on your terminal will look like this:

OK! The basic stuff have been setup! 👌

Let's go ahead setting up:

  • Homebrew
    • open your terminal and paste /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
  • Jenkins following its dedicated doc

Skip the docker integration below if you've tried the cloud hosted one

In your Xcode Project:

In oder to deliver ready-to-test builds, we choose Firebase App Distribution as provider of such.

For further setup and more info follow: