CI/CD for iOS Projects

Continuous Integration & Delivery pipelines with GitHub, Travis CI, SwiftLint, Danger, HoundCI and HockeyApp.

GitHub Links:

iOS Project Template
https://github.com/messeb/ios-project-template

Setup an iOS Project Environment
https://github.com/messeb/ios-project-env-setup

Ansible iOS Build Server Provisioning
https://github.com/messeb/ansible-ios-build-server

Transcript

1. CI/CD for iOS Projects
   Everything as Code
   

   View Slide

2. Who am i
   2
   Sebastian
   Meßingfeld
   iOS Developer
   https://github.com/messeb
   

   View Slide

3. Code
   clone it, fork it, star it
   3
   • iOS Project Template
   • https://github.com/messeb/ios-project-template
   • Setup an iOS Project Environment
   • https://github.com/messeb/ios-project-env-setup
   • Ansible iOS Build Server Provisioning
   • https://github.com/messeb/ansible-ios-build-server
   

   View Slide

4. Disclaimer
   4
   • Based on my experience in projects
   • Changing team during project term
   • Working conditions
   • Git as SCM
   • GitLab or GitHub as Git frontend
   • Build server / service is present in the project
   

   View Slide

5. CI? CD? CD?
   5
   • Continuous Integration
   • Constant integration of new features in main app branch
   • Verification of integration
   • Continuous Delivery
   • Build a release version with new features
   • Continuous Deployment
   • Bring the app live to customers
   • (Internal testers, product owner)
   

   View Slide

6. Everything as Code
   6
   App Tests
   Project
   Setup
   Build
   CI/CD
   Pipeline
   Quality
   Checks
   Deploy-
   ment
   Infrastructure
   

   View Slide

7. Everything as Code
   Why?
   7
   • Automation of manual steps
   • Traceable of everything
   • Open for contributions
   • Versioned state
   

   View Slide

8. Everything as Code
   8
   Project
   Setup
   Build
   CI/CD
   Pipeline
   Quality
   Checks
   Deploy-
   ment
   Infrastructure
   

   View Slide

9. Infrastructure as Code
   9
   • iOS Buildserver
   • macOS 10.14
   • Connected to SCM
   • Build Service
   • Travis CI, Bitrise, Circle CI
   • own Hardware
   • Xcode installation and GitLab CI Runner, Jenkins
   

   View Slide

10. Infrastructure as Code
    Build Service
    10
    • Travis CI, Circle CI, Bitrise
    • Simple configuration in project
    • Mostly GitHub.com only solutions
    # .travis.yml
    language: objective-c
    osx_image: xcode10.1
    # .circleci/config.yml
    version: 2
    jobs:
    build:
    macos:
    xcode: "10.1"
    

    View Slide

11. Infrastructure as Code
    Own Hardware
    11
    • Self-administered installation of components
    • Determine required preinstalled components
    • Xcode
    • Homebrew
    • RVM (Ruby Version Manager)
    • iOS Project contains other dependencies (Project
    setup, Build)
    • Solution: Ansible
    

    View Slide

12. Infrastructure as Code
    Ansible
    12
    • software for the centralized management and
    administration of distributed servers
    • Connects over SSH to build servers (without agent)
    • Install components over predefined commands or
    custom commands
    • Can be run in an additional CI Pipeline
    

    View Slide

13. Infrastructure as Code
    Ansible (Example)
    13
    # macOS updates & configuration
    - name: Install macOS updates
    command: softwareupdate -i -a --restart
    - name: Disable computer sleep
    command: systemsetup -setcomputersleep Never
    become: true
    # Homebrew update
    - name: Install Homebrew
    command: bash -c "\curl -fsSL
    https://raw.githubusercontent.com/Homebrew/install/master/install | ruby”
    # Xcode download
    - name: Query Xcode download
    command: ruby ~/xcode-download.rb
    

    View Slide

14. Project Setup
    14
    • Installs all dependencies
    • Homebrew packages
    • Ruby Gems
    • Project frameworks
    • For new team members and build server (Pipeline)
    • Build server doesn‘t read README.md
    • Should be only one command
    

    View Slide

15. Project Setup
    15
    • make with Makefile is a good solution
    • Defined execution order of task (targets)
    • Command: make bootstrap (make release_build)
    # Makefile
    default: bootstrap
    bootstrap: \
    check_for_rvm \
    check_for_homebrew \
    update_homebrew \
    install_bundler_gem \
    install_ruby_gems \
    install_cocoapods
    # Install Cocopods dependencies
    install_cocoapods:
    $(info Install Cocoapods ...)
    bundle exec pod install
    

    View Slide

16. Project / Build Setup
    16
    • Configuration of build
    artefacts in project
    • + encrypted Certificates
    & Profiles in app repo
    • Independent from build
    tool and server (Build)
    • Build tool configures
    environment
    

    View Slide

17. Build Setup
    fastlane as build tool
    17
    • fastlane (https://fastlane.tools)
    • Ruby frontend for xcodebuild
    • Own „domain specific language“
    • Provides actions for typical tasks
    • App individualizations, like icon bagdes
    • Distribution of app
    • Extendable with plugins or custom Ruby code
    

    View Slide

18. Build Setup
    fastlane as build tool
    18
    Usage
    # Fastfile
    lane :test do
    run_tests(scheme: 'iOSProject')
    end
    lane :release do
    build_ios_app(
    scheme: 'iOSProject',
    export_method: 'app-store',
    configuration: 'Release'
    )
    upload_to_testflight(skip_submission: true)
    end
    $ fastlane test
    $ fastlane release
    

    View Slide

19. Build Setup
    Usage of fastlane
    19
    • Creates build environment on build server
    • Decrypts certificates & provisioning profiles
    • Creates keychain & copy profiles
    • App customizations
    • Build (Dev, Stage, Prod) (Pipeline)
    • with Xcode configuration
    

    View Slide

20. Quality Checks
    20
    • Predefined team rules
    • Code Style
    • Test coverage
    • Commit rules
    • Local & Pull Requests (Pipeline)
    • Local: Xcode run scripts, git hooks
    • Build server: fastlane
    • Keep annoying discussion from the team members
    

    View Slide

21. Quality Checks
    Swiftlint
    21
    • Prevents code smells
    • Force casts
    • Non-weak delegate
    • Uniform code style
    • Rules in .swiftlint
    • Local & Pull Requests
    

    View Slide

22. Quality Checks
    Codecov
    22
    • Test coverage as „quality
    indicator“
    • Test coverage for new
    features
    • Visualization of test
    coverage to identify gaps
    

    View Slide

23. Quality Checks
    Danger
    23
    • „Linter“ for Pull Requests (https://danger.systems)
    • Custom Rulesets
    • E.g. entry in CHANGELOG.md file missing
    • Works as bot user on GitHub, GitLab & BitBucket
    • Info, Warning, Error messages
    

    View Slide

24. Quality Checks
    Danger
    24
    # Dangerfile
    # changes in the project folder
    has_app_changes = !git.modified_files.grep(/iOSProject/).empty?
    # Changelog entries are required for changes to library files.
    no_changelog_entry = !git.modified_files.include?("CHANGELOG.yml")
    if has_app_changes && no_changelog_entry
    warn("Any meaningful changes to the project ....")
    end
    

    View Slide

25. Delivery / Deployment
    25
    • In House
    • During development with Auto-Updates
    • Services: Crashlytics Beta, HockeyApp
    • Ad-hoc or enterprise distribution
    • App Store
    • Testflight
    • App Store distribution
    • fastlane actions for distributions
    

    View Slide

26. Delivery / Deployment
    HockeyApp
    26
    Crash-Report Auto-Update
    

    View Slide

27. Pipeline
    27
    • Description of CI / CD process
    • In app repository
    • Not in Jenkins input fields
    • Not as visual workflow
    • Runs the same code as a developer
    • Prevents untraceable errors
    • Use abstraction of Project Setup and Build
    

    View Slide

28. Pipeline
    28
    • Description of CI / CD process
    • In app repository
    • Not in Jenkins input fields
    • Not as visual workflow
    • Runs the same code as a developer
    • Prevents untraceable errors
    • Use abstraction of Project Setup and Build
    

    View Slide

29. Pipeline
    29
    • Description of CI / CD process
    • In app repository
    • Not in Jenkins input fields
    • Not as visual workflow
    • Runs the same code as a developer
    • Prevents untraceable errors
    • Use abstraction of Project Setup and Build
    

    View Slide

30. Pipeline
    Rules
    30
    # .gitlab-ci.yml
    before_script:
    - make bootstrap
    stages:
    - test
    - build
    test:
    stage: test
    script:
    - make test
    tags:
    - Xcode10.0
    release_build:
    stage: build
    only:
    - /^release\/.+$/
    except:
    - branches
    script:
    - make release_build
    # .travis.yml
    language: objective-c
    osx_image: xcode10.1
    install: make bootstrap
    stages:
    - build
    jobs:
    include:
    - name: Pull Request
    if: type = pull_request
    stage: build
    script: make pull_request
    - name: Staging
    if: branch = master
    stage: build
    script: make staging_build
    - name: Release
    if: tag IS present
    stage: build
    script: make release_build
    

    View Slide

31. Pipeline
    Rules
    31
    • Feature Branch / Pull Request
    • Tests
    • Quality Checks
    • Merge to develop / master
    • Build & distribute develop / stage app version
    • Release Tag
    • Build & Distribute App Store version
    

    View Slide

32. Conclusion
    32
    • IaaS: Build services are good solutions
    • Project Setup: Configure your project build-ready
    • Build / Distribution: use fastlane
    • Quality-Checks: Run during development
    • Pipeline: Visible for developers & execute same code
    

    View Slide