firebase-ios-sdk/ReleaseTooling/DEVELOP.md

Firebase Release Tools

This project includes Firebase release tooling including a zip builder and a Firebase release candidate creation tool.

The tools are designed to fail fast with an explanation of what went wrong, so you can fix issues or dig in without having to dig too deep into the code.

Zip Builder

For general usage, see README.md.

Firebase Release zip building

If the --zip-pods option is not specified, the tool will build a Firebase zip distribution.

For release engineers (Googlers packaging an upcoming Firebase release) these commands should also be used:

• --custom-spec-repos https://github.com/firebase/SpecsStaging.git
  • This pulls the latest podspecs from the CocoaPods staging area.
• --keep-build-artifacts Useful for debugging and verifying the zip build contents.

Putting them all together, here's a common command to build a releaseable Zip file:

swift run zip-builder --update-pod-repo \
--custom-spec-repos https://github.com/firebase/SpecsStaging.git \
--keep-build-artifacts

Carthage

Carthage binaries can also be built at the same time as the zip file. This directory should contain JSON files describing versions and download locations for each product. This will result in a folder called "carthage" at the root where the zip directory exists containing all the zip files and JSON files necessary for distribution.

Firebase Releaser

Provides several functions for staging a Firebase release candidate. See the internal go/firi link for the process documentation.

Launch Arguments

See main.swift for information on specific launch arguments.

You can pass in launch arguments with Xcode by selecting the "firebase-releaser" scheme beside the Run/Stop buttons, clicking "Edit Scheme" and adding them in the "Arguments Passed On Launch" section.

Development Philosophy

The following section describes the priorities taken while building this tool and should be followed for any modifications.

Readable and Maintainable

This code will rarely be modified outside of bug fixes, but read very frequently. There should be no "magic lines" that do multiple things. Verbosity is preferred over making the code shorter and performing multiple actions at once. All functions should be well documented.

Avoid Calling bash Commands Where Possible

Instead of using cat, find, grep, or perl use String APIs to read the contents of a file, FileManager to properly list contents of a directory, RegularExpression for pattern matching, etc. If there's a Foundation API available, it should be used.

Understandable Output

The output of the script should make it immediately obvious if there were any issues and exactly what those issues were, without looking at the code. It should also be very clear if the Zip file was properly built and output the file location.

Show Xcode and API Output on Failures

In the event that there's an Xcode build failure, the logs should be surfaced immediately to aid debugging. Release engineers should not have to find the Xcode project manually. That being said, a link to the Xcode project file should be logged as well in case it's necessary. Same goes for errors logged by exceptions (ex: FileManager).

Testable and Debuggable

Components and functions should be split up in a way that make them easy to test and easy to debug. Prefer small functions that have proper failure conditions and input validated with guard statements, throwing fatalError with a well written error message if it's a critical issue that prevents the Zip file from being built properly.

Works from the Command Line or Xcode (Environment Agnostic)

The script should be able to run from the command line to allow for easier automation and Xcode for simpler debugging and maintenance.

Any Failure Exits Immediately

The script should not continue if anything necessary for a successful Zip file fails. This includes things like compiling storyboards, moving resources, missing files, etc. This is to ensure the integrity of the zip file and that any issues during testing are SDK bugs and not related to the files and folders.

Prefer File URLs over Strings

Instead of relying on Strings to represent file paths, use URLs as soon as possible to avoid any missed or double slashes along with other issues.