Accueil À propos Contact / Devis
Back to all posts
October 2023 rails

Writing a tech audit for a Rails app

As soon as I come on a new project, I like to get a picture of a few things, tech wise.

Here is a checklist of things I look at, questions I’d like to have answers about. This is my cheat sheet, I hope it can be useful for you as well. Let’s dive in!

Stack description

Here, I try to list all the different pieces of tech that make up the app. Ruby on Rails applications are generally fairly standard, but they all differ a little bit. Some might use a bit of an exotic queueing system, or have a database that’s not Postgresql (yes, it’s still very much possible 😊 ).

I also try to list the main components and their version, noting down when is the end-of-life (EOL) for each of these, to get a sense of how up to date it is.

Doing that, I found a useful website to find these EOL dates.

Example

Gems

Here, I try to get a sense of which gems are used, are there some unknown (at least to me) gems that I can add to my toolbox ? I also want to know how many there are, as this is interesting in terms of maintenance, exposition to potential vulnerabilities, and complexity.

I also check out versions, to get a sense of how up-to-date those are. While I’m at it, I try to check for tools like dependabot, or bundle audit that help manage dependency updates and security in a bit more automated fashion.

I don’t have strict rules for the above questions, there isn’t a “right amount of dependencies” but it helps getting a better picture of the app, as well as discovering some features.

Example

Routes

Looking at the routes of an app is a good way to realise what the app does.

Does it have an admin interface, an API ?

Are there incoming webhooks?

How many controllers are there?

Most of these questions can be roughly answered by looking at config/routes.rb.

Example

What is the /v1 namespace, is it still in use ?

API, controllers

This is a continuation of the previous part, except you will get to look at some core functionality of the application. You’ll be able to see if the app is using form objects for example, or if it saves objects into the database directly from controllers. This is useful to know how to orient yourself when you’re going to contribute for the first time to this application.

Example

Frontend

Here is where I will list (in a very basic way) what technologies are used in the frontend, as well as detailing the tooling a bit, since these days, it might vary a lot, even for a Rails application.

Example

Data model

This could be an entire post in itself, as there are a lot of things that can be said. Sometimes, I’ll draw the main entities of a system, starting from what’s obvious. It’s usually what the app is about. Another good way to get started is to start from the user (or equivalent) model.

I am not exhausive when I do this, but I try to get the main entities that make the global picture, that will help me further understand the code.

I will also open a few model files, to get a sense of what is going on, for example, are the models very light, and business logic is handled somewhere else, or it more of a “heavy models” approach.

Good practises, DX

This is the part where I will try to gauge my overall experience during the first interactions with the project. Various things fall under this category. The onboarding speed is probably a very important criteria here, as well as the ease to release something new.

Example

Environments

I try to list the different environements, their names, where to access them, how the flow works, how to deploy the app to those various environments.

Example

Observability

In this section, I’ll list the tooling and any specificities around observability, that includes APM, exception monitoring, log collection, uptime monitoring etc.

Example

Infrastructure

Without going to much into details, I also try to get a sense of what solutions are used for the infrastructure, whether the app is hosted on a VPS, or in a PaaS for example, if there is infrastructure as code, who has SSH access…

Check project history, contributors

That’s a wrap

And, that’s it, pretty much! I hope this gives you ideas on how to structure a Rails app audit, whether you’re consulting on a Rails application, or being onboarded into a new team, I always find it useful to have a little tour of the app and the surroundings, to know what I’ll be working with.