What's this?

Springboard is Amaze's internal developer tooling suite. Currently it's just service scaffolding (provisioning + updating based on your needs), but we're planning to expand it to handle much more.

The core goal of this project is to enable engineers across the organization to focus on what they do best and keep the head-banging to a minimum.

It sucks

Tell us all about it over in #springboard! To make sure we can move quickly we're taking an incremental approach. Nothing will be perfect out of the gate, but with your help we're hoping to build tooling that you love to use.

Getting Started

Install Dependencies

Consult the Springboard repo for dependencies needed

Docker

Simply grab and run the installer

Developing against scaffolded projects

Running the application

The core development flow is centered around Docker and Docker Compose. When you enter your repo you can simply run docker-compose up -d to start your containers. To view application logs you can run docker-compose logs <service_name>. You can see what services you have available to you in docker-compose.yml under the services section.

Applying changes

For the most part your changes are picked up for you. You'll have to wait for the server to restart (you can run docker-compose logs <service_name> to check on this).

Some changes are not picked up automatically -- for instance, when you add a new node dependency. In this case you just need to restart the container with docker-compose restart <service_name>.

Running commands

Most commands you run against the service should be run through docker as well. For example, you'd want to run yarn and buf from within the continer. The idea behind this is that our container is our build artifact used in production and in our ci/cd pipeline. Running commands within the container allow us to make sure that the versions of the software we're running won't lead to any works-on-my-machine type issues. Your code directory is also mounted into the container, so any changes in the repo will be reflected locally on your machine as well.

Running these commands can be done manually with docker-compose run --rm <service_name> <command>, but that's a mouthful. Some convenience commands exist in the bin/ directory to make it feel like you're running the command locally. If you have direnv set up the bin/ directory is automatically added to your path so you can directly run those scripts as if they were commands on your system.

Docker Compose cheat sheet

For those allergic to the command line, GUI options exist for managing Docker Compose environments. If anyone has any recommendations, please create a PR adding them to this section.

Since our development flow is centered around Docker Compose, here are some common operations you will likely be performing. Also it is highly recommended to create an alias for docker-compose.

| Action | Command | Notes | | -- | -- | -- | | Start containers | docker-compose up -d | The -d flag will start the containers in the background | | Stop containers | docker-compose stop | | | Restart your containers | docker-compose restart | | Run a command in a new container | docker-compose run --rm <service name> <command> | The --rm flag will delete the container from your system after exiting | | Run a command in an existing container | docker-compose exec --it <service name> <command> | The --it flag will run the command interactively so you can answer prompts |