Home
Welcome to the Highway wiki. Please choose your topic from the sidebar on the right.
We've used Bitrise and sometimes Fastlane to automate our development flow. However, these tools have their own advantages and disadvantages:
Bitrise pros
- One YAML file does everything. We use bitrise.yml to set up trigger maps, workflows, variables and basically everything else that happens on CI.
- First-party integration with CI . Bitrise.yml works seamlessly with Bitrise CI, doesn’t require any workarounds or special considerations.
- Runs locally (kind of) . You can run Bitrise via CLI.
Bitrise cons
- Built around Git . Bitrise was not designed for arbitrary scripting. Instead, it was designed as a system for CI and made trade-offs to achieve that.
- Tightly coupled with Bitrise . We can't change our CI if something happens. I’m not suggesting we’ll be migration off it — Bitrise is great! — but so was Parse and Buddybuild. 😉
- Uses different ecosystems . There are too many ways to do the same thing which is both a blessing and a curse.
Fastlane pros
- It has enormous living ecosystem. Fast support, hundreds of steps and plugins, weekly releases and a large team of Google employees working full-time to ease the pain of hundreds of thousands of iOS and macOS developers.
- It runs on any CI server and locally . All that it needs is a Mac with Ruby installed. Fastlane doesn’t rely on Git, nor on any CI service.
- It makes continuous delivery possible . Fastlane (and its underlying Spaceship system) is currently best solution for App Store deployment. Even Bitrise and Microsoft App Center uses it under the hood.
Fastlane cons
- It consists of imperative instructions. Easy to use at first but not so maintainable after a while. If you want to write complicated workflows like we do in Netguru, Fastlane quickly turns into a if-o-mania.
- It has unreasonable defaults . It was designed for small teams and indie developers, not for large teams and even larger projects, especially with multiple targets and build configurations.
- Advanced usage requires Ruby skills . This can be a huge blocker for teams like ours. While knowledge of additional technologies is always appreciated, it shouldn’t be a requirement.
- It lazily defers errors . Failures after 30 mins because of a typo? Standard. Decentralized configuration. Requires us to still use spreadsheets if we want many projects to adopt a change in the development flow.
- It carries a huge compatibility burden . Fastfile is just an eval'd Ruby file. This means that Fastlane just can’t break backwards compatibility. That is clearly visible if you dive into its codebase.
Highway combines what’s best about Bitrise and Fastlane into one tool. It is a build system built on top of Fastlane.
- Combine what's best of Bitrise.yml and Fastlane. Highway prefers declarative configuration over convenience and takes advantage of a broad library of steps provided by Fastlane.
- Reduce feedback loops. Provide information faster and in more detail so that you don't waste time, especially when integrated with Danger.
- Bring us closer to Continuous Delivery. Highway allows to easily take advantage of existing tools to finally implement production CD in our projects.
- Allow centralization of configuration. Provide a first-party support to set default values and behaviors across projects. In the future, adding e.g. Carthage-Rome to our projects will be a matter of editing a central “default” configuration file in some repository.
Highway can do literally anything. You can use it for scripting, run it locally and on Continuous Integration. It’s configured by Highwayfile which is a very simple YAML file.