subscriptions-coordinator v1.0.0
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 |
10 months ago