Creating a Rails App

The following command is pretty powerful. It immediately creates a ready-to-go Rails application but doesn’t completely set us up for sustainable development.

rails new

We know a few things about our app right now:

• Other developers will work on it and need to be able to set it up, run its tests, and run it locally.

• It will eventually have security vulnerabilities (in our code and in our dependencies).

• It will be deployed into production via a continuous integration pipeline and require operational observability.

Given the assumptions we listed in the first chapter, we are also quite confident that the app will get more complex over time, and more and more developers will work on it.

Before we start writing code, we will take a few minutes to consider how developers will set up a Rails app and work with it and how we’ll manage it in production. In other words, we need to consider developer workflow, which starts with setup and ends with maintaining the app in production. The developer workflow figure below shows this workflow and the parts of it that we’ll create in this chapter.

The diagram shows:

• bin/setup: This will set up our app after we’ve pulled it down from version control.

• bin/run: This will be used to run our app locally, with the dotenv gem providing runtime configuration for development and testing.

• bin/ci: This will run all of our quality checks, suitable for running in CI, which will include both tests and security analysis via Brakeman and bundle audit.

• In production, we’ll get all runtime configurations from the Unix environment and use the lograge gem to configure more production-friendly log output.

This won’t take a lot of code or configuration, and we’ll end up with automation, which is far more effective and easier to maintain than documentation. Before any of this, however, we need an app to work in.

Setting up a Ruby on Rails app

The example we’ll create in this chapter will be called widgets because it will manage the sale of widgets.

We’ll talk about sustainably creating many Rails apps from a template using the following command:

rails new

We recommend tailoring the above command as little as possible. It can be hard to add back parts of Rails that we initially skipped, and for the most part, the parts of Rails we don’t use can sit there, inert, not bothering anyone.

That said, if we use a version of Rails earlier than Rails 7, we recommend omitting Spring and Listen. These libraries work together to make reloading and restarting our app faster. However, they invariably create a situation where old code runs when it shouldn’t. These gems were eliminated as dependencies in Rails 7, so there’s no need to worry about that any longer.

Because we’ll use Postgres as our database, we can specify that to rails new to have the right gems and configuration. This gives the following invocation to create our app:

rails new --database=postgresql widgets
//lots of output

The following commands are post requisites to run our app or its tests. As of Ruby 3, we must add the rexml gem to the Gemfile.

The other reason we can’t run our app or its tests is that Rails needs to know how to connect to Postgres. This leads us nicely to our next topic on managing runtime configuration.