Waste no more time on setting up development environment. Rocket to the rescue!

Daniel Jankowski tells the story about how the vpTech iOS Core Team set up the local environment in no time, all thanks to a new exciting tool.

To start working on Veepee’s iOS project, there were a bunch of dependencies that needed to be installed and configured on the local development environment. With the iOS Core team, we have been providing the set of instructions written down on Confluence. However, we quickly realized that the process was error-prone and time-consuming due to the need to execute certain steps manually.

In addition to that, the contribution to another project with another set of dependencies would most likely break the existing setup.
An improved process for setting up a local development environment would not only empower new team members to hit the ground running, but it would also lower the barrier for the project’s contributions and application testing / debugging.

Taking the above into account, we have decided to automate the process of local development environment setup by creating Command Line Application (CLI) to do so.

The Tool

We kicked things off by giving a tool the code name — 🦝 rocket. The idea for naming came from the appreciation of the raccoon character from Guardians of the Galaxy movie.

When designing rocket, we had the following assumptions in mind:

• the tool is going to ensure consistent local development environment based on the project specification file
• the project specification file should be descriptive and easily understandable by humans
• the tool will be supporting macOS and Linux operating systems
• the tool will be smart, for example no reinstalling already installed dependencies
• the output logs from the tool should be kept to bare minimum, yet be descriptive

Project specification file

YAML has been chosen for the project specification file. It is easily readable by humans and there are YAML parsing libraries ready to use for most programming languages.

The project specification file must be named dev.yaml or dev.yml and placed in the project’s folder.

The example of a project description file used by rocket

The project specification file supports 4 tasks:

• script execution: it takes the path to the script file or one can define shell script content directly in the file
• installing and updating Homebrew packages: it takes the list of Homebrew packages and installs them if missing, updates otherwise
• installing Ruby: it takes the version of Ruby to be installed and uses rbenv to do so. rbenv must be pre-installed for this task to work
• installing Bundler and gems: it takes the version of Bundler to be installed and the path to Gemfile file to install gems

Zooming into the codebase, there is a dedicated runner per each task type. All runners must satisfy the following requirements:

Rocket’s runner protocol.

Rust

The programming language of choice was Rust. It checked all the boxes: portability, performance and top-notch tooling.

Binary distribution

There are a few ways of distributing Rust CLI application to the audience. The most popular ones are crates, building from source and binary distribution. Crate registry is a great fit for public package distribution, but we wanted to keep rocket private. Building the binary from source is time consuming and it requires Rust installation. Binary distribution is the most convenient for users and that is what we gave a go for rocket distribution.

Since we use GitLab, we chose GitLab Generic Packages Repository to store rocket binaries.

The image presents rocket tool uploaded to GitLab’s Package Registry.

To streamline the process of building rocket binaries and uploading them to the registry, we have developed a bash script. There is also another script for installing rocket tool. The binary is downloaded into the project’s root folder and it is git ignored.

We decided to not store rocket binary in a git repository due to increasing repository size over time and potentially time consuming git clone. Git does not do a diff for binaries, meaning each binary update results in adding binary’s size to the repository size

The usage

In order to set up the whole local development environment, one needs to call a single command — rocket up. You will find an example of command’s output below:

$ rocket up(0) Verify Xcode version
Xcode found ✓
Xcode version 14.0 ✓
✓ Verify Xcode version
(1) Homebrew
Updating Homebrew
Upgrading Homebrew package: mint
Upgrading Homebrew package: rbenv
Upgrading Homebrew package: ruby-build
✓ Homebrew
(2) Ruby
✓ Ruby
(3) Bundler
Using fastlane 2.205.1
...
Bundle complete! 13 Gemfile dependencies, 155 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
✓ Bundler
(4) Tuist
✓ Tuist
(5) Mint bootstrap
🌱 4 packages up to date
✓ Mint bootstrap
(6) Carthage bootstrap
*** Checking out Alamofire at "5.2.2"
*** Checking out AlamofireImage at "4.1.0"
...
*** Valid cache found for Alamofire, skipping build
*** Valid cache found for AlamofireImage, skipping build
...
✓ Carthage bootstrap

The number of logs is kept to minimum, however rocket supports a verbose mode in case a user wants to display detailed processing information on the screen. It is useful when someone wants to track the progress of the process or when someone wants to report a bug related to the tool.

Summary

Automated local development environment setup has been great so far. New team members have amazing onboarding experience. Developers have a blast whenever there is a need for updating the local development environment due project’s dependencies changes.

What is more, we use rocket on CI which prevents neglecting the tool and forces proper support and maintenance.

Rocket has definitely room for improvements like showing a progress indicator or displaying helpful messages when something went wrong.

Overall, we are extremely happy with the rocket and truly believe it was a worthwhile investment.

Daniel Jankowski