Forem: hix.dev

Ruby Environment Management 101

hix.dev — Fri, 20 Mar 2020 12:40:17 +0000

An automated Ruby environment management is necessary for developers to easily work on multiple Ruby programs on the same machine.

You can read this whole article from our original blog post. It's a bit prettier.

In the Ruby community, there are two popular managers responsible for installing and maintaining multiple Ruby versions - RVM and Rbenv.

This tutorial will guide you on choosing the best one and configuring your own environment.

What is Ruby Environment Management?

If you are actively working on programs written in Ruby, at some point you are going to install multiple versions of the language on your system.

Ruby environment managers such as RVM and Rbenv allow you to do just that.

It is a generally accepted practice to include the .ruby-version file in the root of Ruby-written programs and applications, such as Ruby on Rails projects. The version file includes a specific Ruby version with which the program is supposed to work.

'.ruby-version'

2.6.5

Both RVM and Rbenv respect the aforementioned Ruby version, and upon navigating to the root of Ruby program that includes the file, they inform you that a particular Ruby version has to be installed in case it is missing on your system.

RVM vs Rbenv - which Ruby Version Manager should I use?

The short answer for developers is: it does not really matter, just pick one and be done with it - both RVM and Rbenv get the job done.

The long answer is: it depends.

One factor in favor of Rbenv over RVM is that it receives more love on Github. But let's get to the facts.

RVM pros over Rbenv:

RVM is easier to install than Rbenv,
RVM has more features than Rbenv,
RVM includes a built-in Ruby installation mechanism while Rbenv does not.

Rbenv pros over RVM:

Rbenv is lightweight, RVM is heavier,
Rbenv is more developer-friendly than RVM,
Rbenv has a dedicated plugin for Ruby installation mechanism, RVM has it built-in
Rbenv main sell point is that its lightweight in comparison with RVM, while still providing just enough functionality for the Ruby development.

Now that we definitely have not decided which one to use leaving this decision to you, follow the installation instructions of the Ruby environment manager of your choice.

RVM installation

Depending on your operating system, follow the instructions below in order to install the RVM Ruby Environment Manager.

Ubuntu

RVM has a dedicated package for Ubuntu. In order to use it, you are going to be able to add stuff to PPA.

sudo apt-get install software-properties-common
sudo apt-add-repository -y ppa:rael-gc/rvm
sudo apt-get update
sudo apt-get install rvm

The next step is configuring the terminal to always perform login in order to always load the RVM.

At the terminal window:

Navigate to Edit / Profile Preferences ,
Go to the Title and Command tab,
Check Run command as login shell

The last step is to reboot your machine.

Other operating systems

In order to install RVM, you are going to need the following packages: curl and gpg2. After confirming their presence, simply run

curl -sSL https://get.rvm.io | bash -s stable

Confirm your installation running the rvm install ruby command.

RVM overview

As stated before, RVM has more features built-in that Rbenv does.

In order to browse all the RVM commands, run either rvm --help or man rvm in your CLI.

Basic command-line RVM usage can be boiled down to this set of commonly used commands:

rvm install <version> installs given Ruby version on your system,
rvm remove <version> removes given Ruby version from your system,
rvm list lists all Ruby versions installed on your system,
rvm list known lists all available Ruby versions that you can install with rvm install command,
rvm current displays currently used Ruby version
rvm use <version> changes the currently used Ruby version to the given one
rvm use default <version> sets the Ruby version that your system uses by default

The last two commands are useful to remember whenever you start the development of a new Ruby-written program. In most cases, it's best to use the latest stable version, which is always installable via the rvm install ruby --latest command.

Rbenv installation

Based on your operating system, follow the instructions below in order to install the Rbenv Ruby Environment Manager.

macOS

Installing the Rbenv on macOS is really easy and can be done using Homebrew.

brew install rbenv
rbenv init

After running the commands, close and open your terminal for changes to take effect.

The Ruby installation plugin is included by default, so you can now install any Ruby version using the rbenv install X.Y.Z command.

Linux

In order to set up Rbenv on Debian based system, we are going to install all Ruby dependencies first.

sudo apt update
sudo apt install autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm5 libgdbm-dev

For OSs other than Debian, the same might be done using other system package managers.

Next, we are going to clone the official Rbenv repository into the home directory and add its binary to $PATH in order to use rbenv command line utility.

git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc

The next step is to add the following command to your shell configuration file in order to load Rbenv automatically when the CLI starts.

~/.zshrc or ~/.bashrc

eval "$(rbenv init -)"

The last step is installing Ruby installation Rbenv plugin by simply cloning its official Github repository into the correct path.

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

That's it, Rbenv is ready to use. You can install the latest stable Ruby version using the rbenv install -l command.

Rbenv overview

In order to use Rbenv via CLI, you need to have the aforementioned ruby-build command-line utility installed.

In order to browse all the Rbenv commands available, run the rbenv --help method.

There are basic Rbenv commands that you are going to use at some point of Ruby development:

rbenv install <version> installs given Ruby version,
rbenv global <version> sets the default system Ruby version,
rbenv version displays the currently used Ruby version of your system,
rbenv install --list option lists all available versions of Ruby.

Whenever you start to develop the new Ruby program, it is worth using the latest stable Ruby version, which you can easily install using the rbenv install -l command.

Conclusion

Ruby Environment Management is a must-have for every Ruby developer.

Ruby community provides two very popular Ruby environment managers, Rbenv and RVM. Both of them are pretty easy to install and get the job done.

If you have any questions, leave a comment!

Running your Rails projects with Redis - all you need to know

hix.dev — Thu, 20 Feb 2020 13:39:19 +0000

In this tutorial, we'll go step by step through Ruby on Rails Redis installation and configuration.

Redis is a key-value database, and it is very much worth using in multiple scenarios when working with Ruby on Rails.

This piece is a 1:1 copy of what you can find on our website, along with a bunch of other Rails tutorials.

Let's start this Ruby on Rails Redis guide.

What is Redis?

Redis is a BSD licensed, in-memory data structure store. It is one of the most popular NoSQL choices among open-source options available.

On top of that, Redis is the most popular key-value database, and it was voted the most loved database in the Developer Survey by Stack Overflow three years in a row: 2017, 2018 and 2019.

Redis supports various data structures:

strings,
hashes,
lists,
sets,
sorted sets with range queries,
bitmaps,
hyperloglogs,
geospatial indexes with radius queries,
streams,

and is used as a database, session cache, full page cache, and message broker, such as publish-subscribe messaging.

Why use Redis with Ruby on Rails?

There are multiple reasons to use Redis in Ruby on Rails application.

First of all, Redis offers the most popular in-memory data store. Data kept in the memory, as opposed to tools that write to disks, is going to be read and written faster.

Another reason to use Redis in Ruby on Rails is so obvious that it is even made official by the Ruby on Rails maintainers: using Redis as Ruby on Rails application cache-store.

Next, there are leaderboards: think anything that changes over time, like:

up and downvotes,
likes,
clasps

or internal application statistics, like:

active user sessions,
scheduled emails,
counting visitors

A good example of the leaderboard is the Sidekiq Dashboard - which itself is a great reason to Ruby on Rails Redis usage, as it offers the most popular community choice for asynchronous code execution - and uses Redis.

Last but not least is a commonly needed these days Publish-Subscribe feature, and Redis is truly crafted for the job.

Redis is officially the default production pub/sub queue for the built-in Ruby on Rails ActionCable library, dedicated to channeling data through WebSockets.

As you can see, there are a lot of scenarios when it's going to be worth using Ruby on Rails and Redis combination.

Redis installation

Now that we know what is Redis and what it is used for in Ruby on Rails, let's go through step by step guide to installing it for further usage with our Ruby on Rails application.

macOS

The most straightforward way to install Redis on the macOS is using Homebrew.

Follow these steps:

Install Homebrew, there's a single command to do so on the official website.
Install Redis via Homebrew: brew install redis.

For the development convenience, we are going to do one more thing, that's gonna save us a lot of trouble in the future.

Let's install and enable Brew Services, in order to run Redis in the background. This way, anytime you reboot your machine, it is going to launch Redis for you automatically.

Run the following commands in your CLI.

brew tap homebrew/services
brew services start redis

The first command installs the brew services and the second one launches Redis as a brew service. You can browse all services running at any point using the brew services list command.

Verify that Redis is running with redis-cli ping command - it should return PONG.

At this point, it is worth installing a Redis client for macOS - this way you will be able to easily browse all the data written to any Redis instance:

Medis from AppStore for $4.99 or install from Github,
Tableplus for $59,
RDM - Redis Desktop Manager for $14.99
FastoRedis for $249.

As scary as it sounds, paying for the Redis client is worth it in the long run, as it vastly improves Ruby on Rails development and debugging process.

Linux

Depending on your Linux distribution you are going to use a different package manager to install Redis.

If you use CentOS or RedHat, install Redis using yum package manager.

sudo yum install redis

Otherwise, if you use Debian based distro such as Ubuntu, use apt package manager.

sudo apt install redis

In both cases, in order to automatically start Redis on boot, run

sudo systemctl enable redis

This way you won't have to remember to launch Redis every time, it is very convenient for continuous development.

Verify that Redis is running with redis-cli ping command - it should return PONG.

At this point, it is also worth installing the Redis GUI client. It greatly improves the development and debugging experience, allowing you to easily browse all data written to Redis while working with your Ruby on Rails application.

We recommend using a Redis Desktop Manager, which is free for Linux distributions.

Ruby on Rails Redis installation

If you use Hix on Rails, then you can skip the rest of this tutorial - just run the installation wizard and all of the below is going to be preconfigured for you. Optionally you might jump to the Redis Sentinel production configuration part for better understanding and customization.

Otherwise, if you still did not automate this part of your life yet, read on.

With Redis up and running on our system, let us install the required Redis-related gems in order to use it with our Ruby on Rails application.

We are going to use a Ruby client recommended on the official Redis website.

On top of that, there are another two gems worth installing:

redis-rails gem that provides a full set of stores for Ruby on Rails - Cache, Session, and HTTP Cache,
redis-namespace gem, which is very useful when working with multiple Ruby on Rails projects.

In the Gemfile of your Ruby on Rails project, add the following, outside any of the specific groups. They need to be available to all of the Ruby on Rails environments.

Gemfile

gem 'redis'
gem 'redis-namespace'
gem 'redis-rails'

Now, run the bundle install command in order to generate the Gemfile.lock file.

In order to easily connect to Redis from our Ruby on Rails application, we are going to additionally use the environment variables management gem, dotenv-rails - install it and in your .env file add these three environment variables for development.

.env

REDIS_DB=0
REDIS_URL=redis://127.0.0.1
REDIS_PORT=6379

those are the default host and port of every Redis installation.

Next, we are going to tell our Ruby on Rails application to connect to Redis upon booting by creating the dedicated initializer.

config/initializers/redis.rb

# frozen_string_literal: true

Redis.current = Redis.new(url:  ENV['REDIS_URL'],
                          port: ENV['REDIS_PORT'],
                          db:   ENV['REDIS_DB'])

If you are going to use the aforementioned Action Cable, there's one little thing worth doing at this point.

As you can see, in our environment we have separated the Redis URL and DB variables. Concatenated, they result in the Redis host, and it is how Ruby on Rails Action Cable uses them. Open its configuration and change it to the following.

config/cable.yml

development:
  adapter: async

test:
  adapter: test

production:
  adapter: redis
  url: <%= ENV.fetch("REDIS_URL") %>/<%= ENV.fetch("REDIS_DB") %>
  channel_prefix: app_production

I personally like to keep the development environment as close to the production one as possible in order to catch any bugs at the earliest stage.

To do that, you might consider changing the development Action Cable configuration to the same as production one - this way while writing your Ruby on Rails application's code and running it locally, you will use Redis as well.

Ruby on Rails Redis production configuration with Sentinel

If you care about high Redis availability in the production environment of your Ruby on Rails application, you might consider using the Redis Sentinel.

Using Sentinel is the officially recommended way to automatically manage Redis failovers, it is also capable of monitoring and notifying on the Redis deployment.

The Redis client that we have previously installed in the Ruby on Rails application in order to connect to the Redis client is able to perform automatic failover using Redis Sentinel.

In order to do that, we are going to change the Ruby on Rails Redis configuration file. Open the previously created initializer and edit it with the following:

config/initializers/redis.rb

# frozen_string_literal: true

if Rails.env.production?
  SENTINELS = ENV['SENTINEL_HOSTS'].split(' ').map! do |host|
    { host: host, port: ENV['SENTINEL_PORT'] }
  end

  Redis.current = Redis.new(url: ENV['SENTINEL_URL'],
                            sentinels: SENTINELS,
                            role: :master)
else
  Redis.current = Redis.new(url: ENV['REDIS_URL'],
                            port: ENV['REDIS_PORT'],
                            db: ENV['REDIS_DB'])
end

This configuration file assumes the existence of three additional environment variables. In the environment configuration of your Ruby on Rails application, add the following.

.env

SENTINEL_URL=redis://sentinel-master/1
SENTINEL_HOSTS=sentinel-slave-1 sentinel-slave-2 sentinel-slave-3
SENTINEL_PORT=26379

Another assumption that might require additional tweaks is that all the slave Redis instances run on the default Sentinel port which is 26379. If that is not a case, adjust the initializer file accordingly.

If you are using Sidekiq and want it to respect your Sentinel production configuration, you'll need to adjust its configuration pretty much the same way - by conditionally connecting your Ruby on Rails to the Redis Sentinel in the production environment.

In order to additionally improve Ruby on Rails Redis performance, you might want to take a look on hiredis and its dedicated Ruby wrapper hiredis-rb.

Conclusion

Ruby on Rails Redis installation and configuration is a pretty straightforward thanks to the awesome official and community support.

All it takes is installing a few well maintained Ruby gems, and your Ruby on Rails application is ready to read and write to Redis key-value store.

All of this config comes ready with Ruby on Rails application initialized with Hix on Rails Application Template.

Using RSpec testing framework in your next Ruby on Rails project - cover-to-cover guide.

hix.dev — Wed, 12 Feb 2020 15:12:41 +0000

This post was originally created on our official website. You are more than welcome to read it there!

Now, let's get your code tested!

What is RSpec?

RSpec is the most popular Ruby on Rails testing framework according to Ruby on Rails community. It is also perfectly capable to test any Ruby-written code. RSpec organization repository is neatly organized into smaller parts, such as:

rspec, the main RSpec package,
rspec-core, the gem providing structure for writing executable examples and a customizable rspec command,
rspec-rails, RSpec package dedicated to testing Ruby on Rails applications,
rspec-mocks, RSpec gem that provides support for stubbing and mocking requests,
rspec-expectations, RSpec package that exposes a readable API to express expected outcomes of code examples.

and then some more. It all builds up into a comprehensive, fully-featured Ruby and Ruby on Rails testing framework.

One can easily see that the RSpec for Ruby on Rails is the most frequently developed of all the gems.

As stated on the official RSpec informative website, RSpec provides a Behavior-Driven Development, BDD for Ruby, and it makes Test-Driven Development, TDD, fun and productive.

Thorough documentation of the RSpec framework and all of its gems with executable examples is available thanks to Relish on their official website dedicated to RSpec.

Altogether it seems an awful lot, but it's definitely worth to use RSpec in Ruby on Rails applications, as it is the most advanced Rails testing framework of all.

Why use Ruby on Rails with RSpec over alternatives?

Now that we review what is the RSpec testing framework, let's take a look at why it should be your choice when it comes to Ruby on Rails testing.

As stated at the beginning, RSpec is the most popular choice for Ruby on Rails projects testing. However, it does not come with the default Ruby on Rails application setup, it needs to be installed manually.

The default framework for Ruby on Rails applications testing is a MiniTest. It is a built-in mechanism with the official Ruby on Rails documentation on how to write unit, functional, integration and system tests, and all of its terminologies explained.

Another noteworthy testing framework widely used with Ruby and Ruby on Rails - as with Java, Electron and many others - is a Cucumber framework.

So what does make RSpec the best choice for testing Ruby on Rails applications?

First of all, RSpec has the best documentation, which provides a ton of helpful examples and real-life scenarios that are commonly needed to be covered by developers. This is crucial for using anything that provides its own Domain-Specific Language - DSL- as the RSpec does.

On top of that, RSpec out of the box has all the features that developers need, and all of them are highly maintained.

MiniTest on the other hand, along with its claim that everything done by RSpec might be accomplished using dedicated plugins, does not maintain them successfully, and a lot of them are broken and have not been updated in a long time.

At last, RSpec is an application, while MiniTest and Cucumber are simply frameworks. I cannot stress enough how important it is for daily usage. It does not require anything else to run the test suite, providing an end to end solution for Ruby testing.

RSpec provides a mature, well maintained and documented command-line interface program. It works exactly as one would expect it to, with the CLI help available via the --help option.

Summing it all up, RSpec is the most popular community choice for testing Ruby on Rails applications. Thanks to that, as it's open-sourced, it is highly maintained, a lot of solutions to the common problems are easily googleable and it grows in power rapidly.

What is code coverage?

Code coverage, also known as test coverage, is a measure responsible for calculating the percentage of code used while running the program's test suite.

On its own, a 100% code coverage does not guarantee that the code does not contain any bugs, as a simple code execution does not guarantee its accuracy.

However, it gives a nice overview of the program's test suite as a whole, telling the developers which parts are safe to edit, and which are yet to be tested.

Rspec code coverage with SimpleCov

Using RSpec in Ruby on Rails, the most popular choice for calculating the project's code coverage reports is SimpleCov.

By default, it provides a simple total percentage of the project's test suite code coverage.

On top of that, SimpleCov allows grouping the reports by meaningful categories such as Ruby on Rails Controllers, Models, Views and Mailers, Sidekiq Workers and anything else that comes to mind for the given Ruby on Rails application, such as Service, Query, and Form Objects.

Using the SimpleCov gem, one can set it up to fail - which means returning a non-zero value CLI-wise - for a minimum (and maximum) test code coverage limits, enforcing developers to meet the established limitations.

It is a super helpful way to make people write tests when implemented in the Continuous Integration suite.

RSpec code coverage overview with Coveralls

If you are serious about the code coverage, we recommend using Coveralls.

It is a SaaS that provides a comprehensive dashboard showing the test coverage history and statistics for the selected projects and can be easily integrated with any of the most used git repository hosting providers such as Github, Gitlab and Bitbucket.

You might have met it already, as it provides a very popular coverage badge, commonly included in the README files of Open Source projects, as Coveralls is free to use with any open-sourced code, forever.

Coveralls is an overall great tool to ensure a better Ruby on Rails application maintenance, providing both the simple and sophisticated overviews of the projects testing suite code coverage.

Configure RSpec in a Ruby on Rails project

If you use Hix on Rails, you don't need to do any of the following - simply go through the setup wizard and be done with it, anytime you start a new project.

Otherwise, if you sadly did not automate this part of your life yet, read on.

Let us now configure the RSpec testing framework in the Ruby on Rails project, following a simple step by step guide.

Raw RSpec config in Ruby on Rails

In order to use RSpec with your Ruby on Rails application, you need to install the dedicated rspec-rails gem. Open your project's Gemfile and add it to the test and development groups.

Gemfile

group :development, :test do
  gem 'rspec-rails'
end

Next, run the bundle install command in your CLI after navigating to your project's root path, in order to include the gem in your Ruby on Rails project's Gemfile.lock file.

bundle install

RSpec is equipped with the rspec command, that comes with an initialization option. However, in Ruby on Rails, there's a dedicated generator to do just that. In your CLI, run the following command.

rails generate rspec:install

It generates three files: .rspec, spec/spec_helper.rb and spec/rails_helper.rb. The first file is loaded every time the rspec command runs via CLI, passing the RSpec options to it. By default, it only tells RSpec to include the other helper files that are responsible for defining the gem's configuration.

A full list of options available resides under the rspec --help command.

By default, there are three options defined in the second generated file, all of which are going to be the defaults in the next major version of the RSpec framework, the RSpec 4. It is recommended by the framework authors to leave them this way. Options are:

Including the chained methods in the output messages
Preventing from mocking or stubbing a method that does not exist on a real object
Causing shared contexts metadata to be inherited by the metadata hash of host groups and examples, rather than triggering implicit auto-inclusion in groups with matching metadata

On top of that, there are some commented-out configuration options:

Limiting a spec run to individual examples or groups you care about by providing custom tag
Persisting tests state between runs in order to support failure-related CLI options
Limiting the available syntax to the non-monkey patched, which is recommended
Enabling warnings
Custom formatting based on a number of spec files in the test run
Profiling, that for a given number of tests tells us which of them are the slowest to run
Ordering of the tests in the test run

The last generated file, spec/rails_helper.rb, is responsible for defining the Ruby on Rails specific configuration. Those two are separated for performance reasons, as explained in this rspec-rails dispute.

The third file does a multitude of helpful things:

Prevents tests run in the production environment
Sets Rails environment to the TEST if nothing else is set
Prevents tests run if Rails migrations are not up to date with the schema
Defines fixtures path and tells RSpec to use transactional fixtures
Tells RSpec to "figure out" the test type from its location in the project - defaults available are Controllers, Models, and Views
Filters out the Ruby on Rails output from the backtrace

From now on, whenever adding anything related to Ruby on Rails to the RSpec configuration, we are going to do so in the spec/rails_helper.rb file.

Let us do just that by adding a few helpful gems that make testing easier and more predictable.

DatabaseCleaner gem set up with RSpec in Ruby on Rails

In order to keep our Ruby on Rails project's test database clean between test runs, we are going to install an additional gem dedicated to doing just that, the DatabaseCleaner.

First of all, select and install one of the gems dedicated to specific Ruby on Rails ORMs supported by DatabaseCleaner. The most popular choice is going to be the Active Record gem. In your Gemfile file, add the gem of your choice to the test group.

Gemfile

group :test do
  gem 'database_cleaner-active_record'
end

and run the bundle install command from the root path of your Ruby on Rails project.

Next, let us tell RSpec to clean the Ruby on Rails project tests database in between the test suite runs. Open the spec/rails_helper.rb and add the following.

spec/rails_helper.rb

RSpec.configure do |config|
  # some
  # other
  # configuration
  config.before(:suite) do
    DatabaseCleaner.strategy = :truncation
    DatabaseCleaner.clean_with(:truncation)
  end

  config.before do
    DatabaseCleaner.strategy = :transaction
    DatabaseCleaner.start
  end

  config.append_after do
    DatabaseCleaner.clean
  end
end

This set of configuration hooks tells RSpec to do the following:

truncate the database before test suite run
rollback database changes between tests
clean the database after the tests suite run

Cleaning the Ruby on Rails tests database on all of these stages prevents the test's failures caused by any rubbish data leftovers generated between the RSpec tests run.

ShouldaMatchers gem set up with RSpec in Ruby on Rails

One of the most popular gems that support testing Ruby on Rails applications with RSpec is ShouldaMatchers. It provides a great toolkit for testing the methods commonly used in the classes provided in Ruby on Rails framework, such as ActiveModel, ActiveRecord and ActionController.

In order to use ShouldaMatchers in your Ruby on Rails project with RSpec, we need to install the shoulda-matchers gem first. Open the Gemfile file and add it to the tests group.

Gemfile

group :test do
  gem 'shoulda-matchers'
end

Run the bundle install command in your Ruby on Rails project's root directory, and edit the spec/rails_helper.rb with the following.

spec/rails_helper.rb

Shoulda::Matchers.configure do |config|
  config.integrate do |with|
    with.test_framework :rspec
    with.library :rails
  end
end

That's it - your Ruby on Rails project is ready to use all the matchers provided by the ShouldaMatchers in the RSpec tests.

FactoryBot gem set up with RSpec in Ruby on Rails

FactoryBot is the most popular fixtures replacement for Ruby on Rails projects. It provides a straightforward definition syntax and supports both multiple build strategies and factories for the same class, including inheritance.

In order to use FactoryBot in the Ruby on Rails project with RSpec, install the dedicated FactoryBotRails gem. Open the Gemfile file and add the following to the development and test groups.

Gemfile

group :development, :test do
  gem 'factory_bot_rails'
end

Adding the gem to the development group results in modifying the default Ruby on Rails generators to produce related factories - from now on, whenever you generate the new model via command line, the corresponding factory will be generated as well.

In order to include the FactoryBot in the RSpec configuration, add the following to the spec/rails_helper.rb.

spec/rails_helper.rb

RSpec.configure do |config|
  # some other configuration
  config.include FactoryBot::Syntax::Methods
end

You can take the full advantage of the FactoryBot gem whenever writing RSpec tests in your Ruby on Rails project.

TimeCop gem set up with RSpec in Ruby on Rails

As stated in the RSpec Ruby Styleguide, the best way to deal with time when testing Ruby on Rails applications with RSpec is to use the TimeCop gem.

TimeCop provides time freezing, travel, and acceleration capabilities, giving developers oneliners to deal with the time, instead of stubbing anything on Date, Time and DateTime classes.

In order to use the TimeCop gem in your Ruby on Rails project, simply add it to the test group of your Gemfile file.

Gemfile

group :test do
  gem 'timecop'
end

It does not require any configuration specific to RSpec in the Ruby on Rails project.

In order to take the quality of your RSpec Ruby tests to the next level, visit the Ruby on Rails RuboCop configuration guide - it provides the way to validate your RSpec tests suite in the Ruby on Rails project against aforementioned RSpec Style Guide automatically.

SimpleCov configuration in Ruby on Rails with RSpec

In order to generate the coverage reports in the Ruby on Rails application tested with RSpec, we are going to install the aforementioned SimpleCov gem. In your project's Gemfile, add the required gem to the test group.

Gemfile

group :test do
  gem 'simplecov'
end

and next, navigate to your projects root path and run the bundle install command.

By default, SimpleCov is going to generate all of its reports into the coverage directory of our project. Let's add it to the project's .gitignore file in order to avoid a massive amount of changes accompanying every test run.

.gitignore

coverage/

Next, we are going to follow the gem instructions in order to turn on the SimpleCov code coverage gem every time the test suite runs. Open the spec/spec_helper.rb file and add the following at the beginning of it.

spec/spec_helper.rb

require 'simplecov'

SimpleCov.start 'rails'

In the simplest manner possible, you're done - every test run is going to result in the code coverage report generation.

Coveralls account setup and configuration in Ruby on Rails

Now that we are generating the code coverage reports, let us track their history along the Ruby on Rails application development via Coveralls.

Follow the step by step guide in order to set up your Coveralls account and adding your Ruby on Rails project to it.

Be aware that you are going to subscribe to the Corveralls PRO in order to set up private repositories here.

1.Sign up on the official Coveralls website.

2.After logging in, authorize Coveralls to access your repository hosting provider account.

3.Hover the left-hand side sidebar and click the "Add Repos" link.

4.Search for your Ruby on Rails project repository in Coveralls and turn it on.

5.Click the "Details" button and copy your Coveralls repository key.

After obtaining the Coveralls repository key and enabling it in the tool's interface, we are going to set it up in our Ruby on Rails project.

First, let's install the provided gem. Open the Gemfile file and add the coveralls to the test group.

Gemfile

group :test do
  gem 'coveralls'
end

Run the bundle install command and open the spec/spec_helper.rb file, in order to tell RSpec to use the provided formatter.

spec/spec_helper.rb

# frozen_string_literal: true

require 'coveralls'
require 'simplecov'

SimpleCov.formatter = SimpleCov::Formatter::MultiFormatter.new([SimpleCov::Formatter::HTMLFormatter,
                                                                Coveralls::SimpleCov::Formatter])
SimpleCov.start 'rails'

The last step is to create a dedicated Coveralls configuration file with our previously generated repository key.

.coveralls.yml

service_name: service-name
repo_token: YOUR_COVERALLS_REPOSITORY_KEY

Depending on the Continuous Integration service that you use, update the service name accordingly. If in doubt, browse the full list of services supported by Coveralls.

My advice is to take another five minutes to figure out how to skip using the .coveralls.yml file completely, as keeping secrets checked into your remote repository might not be the best idea

It is better to define them as environment variables, and most of the Continuous Integration providers enable that option. Coveralls documentation gives you guidelines on how to do just that for their supported services.

The main goal here is to generate your code coverage reports via your RSpec tests run on the Continuous Integration whenever you merge the new feature to develop and master branches. This way your Coveralls history and statistics will not clutter with endless reports of identical feature branches code coverage data.

Conclusion

As stated multiple times in this guide, RSpec is the most popular choice for testing the Ruby on Rails applications, and for a number of good reasons.

If you care about Ruby on Rails tests, setting up the code coverage reporting is recommended - it gives developers a nice overview of the project's maintenance quality.

The SimpleCov gem is a simple to use solution to do just that in your Ruby on Rails projects that use RSpec - all it takes are two extra lines of code and the dedicated gem installed.

For those who want more control, enforcing the minimal code coverage in the Ruby on Rails application takes only the single line of code in the RSpec configuration file.

If you're looking for a professional overview of the code coverage statistics and history for your Ruby on Rails projects, use Coveralls - it aggregates your code coverage data and exposes it via sophisticated web UI.

As you can see, there's a lot of configuration related to the RSpec testing framework set up in the Ruby on Rails project -fortunately, you can skip most of it by using the Hix on Rails, the Ruby on Rails project generator.

Setting up your next Rails project with RuboCop - a 101 guide

hix.dev — Fri, 07 Feb 2020 14:44:46 +0000

RuboCop is the most popular Ruby static code analyzer and code formatter, code linter in short. Linting is the process of running a program that analyzes the code for programmatic and stylistic errors.

Using it translates to a better code quality, clean code, and better experience for the readers.

In this tutorial I will explain how you can implement it in your next Rails project.

It's also available in a 1:1 format on our original site if you prefer to read from the source.

Let's get started.

What is RuboCop and Ruby Style Guide?

Out of the box, Rubocop enforces most of the guidelines outlined in the Ruby Style Guide maintained by the Ruby community. The guide groups its guidelines by related sections, which corresponds to RuboCop gems departments.

There are nine departments in the base RuboCop gem. Numbers might change in time and are given here only for the rough overview of what the gem offers.

Layout - 87 cops
Linting - 81 cops
Metrics - 10 cops
Migration - 1 cop
Naming - 16 cops
Security - 5 cops
Style Cops - 170 cops
Bundler - 4 cops
Gemspec - 4 cops

In total, there is a little less than 400 rules applicable to anything written in Ruby, if we choose so.

But, it does not end here - let us take a quick look at accelerating the Ruby code by following extended RuboCop guidelines.

RuboCop Performance

There's an extension wisely encapsulated in its own Ruby gem called RuboCop Performance. Its job is pointing out Ruby code optimization opportunities.

All 25 rules of the RuboCop Performance gem are grouped in the single RuboCop department, called Performance.

It is a relatively young project and some of the cops included were originally placed in the main RuboCop gem.

If your Ruby program is really performance-dependent, you might want to additionally look at the fasterer gem, based on the open-sourced Github repository called Fast Ruby - the biggest collection of Ruby benchmarks.

Let us now take a look into other, framework-specific RuboCop extensions.

RuboCop Rails and Rails Style Guide

When RuboCop is a code linter of your choice, RuboCop Rails extension is the must-have for your Ruby on Rails projects.

RuboCop Rails is a RuboCop extension focused on enforcing Ruby on Rails coding conventions and best practices, neatly described in the Ruby on Rails Style Guide.

The style guide itself is split into 16 sections, covering things such as Ruby on Rails configuration, dealing with time, Models, Controllers, Mailers and more.

Whenever in doubt on how to approach Ruby on Rails related problem, try browsing the relevant style guide section, or go one step further and let your projects Continuous Integration point it out for you, by configuring RuboCop gem with all its extension on either GitlabCI or CircleCI.

RuboCop RSpec and RSpec Style Guide

If RSpec is your weapon of choice unit-testing-wise, setting up the RuboCop RSpec extension will help you a lot.

RuboCop RSpec is a RuboCop extension that provides RSpec, RSpec for Rails, FactoryBot and Capybara analysis for Ruby projects, which in total gives us another 76 rules to follow, for the sake of neat codebase.

All of the RuboCop RSpec cops - and then some - are extensively described in the RSpec Ruby Style Guide, providing examples of the code that follows the guideline paired with the one that does not.

It is my personal favorite style guide of all provided by the RubCop HeadQuarters, and I rely on it a lot during Code Reviews - my Github account saved replies are linking to it heavily.

Next to the gem itself, the guide gives an extremely useful overview of how to write unit tests of Ruby on Rails related parts, such as the MVC Models, Views, Controllers and also Mailers.

Unfortunately, some of the Rails related rules are not possible to enforce via the gem itself, hence the Github saved replies linking to the relevant guide sections.

It is still a great tool whenever you use RSpec in your Ruby and Ruby on Rails projects.

RuboCop MiniTest and MiniTest Style Guide

If you use MiniTest, the second most popular choice for testing the Ruby written programs, there's a RuboCop extension dedicated to it, called RuboCop MiniTest.

It enforces best practices outlined in the MiniTest Style Guide, yet another great read provided by RuboCop HeadQuarters.

It's a relatively young project comparing to the more popular RSpec choice. It describes a total of 15 rules for writing unit tests using the MiniTest framework.

RuboCop set up in a single Ruby on Rails project

Now that we went through most of the RuboCop extensions - there are two more, for Rake and Markdown - let us take a look at how to hook it all up in the Ruby on Rails application.

RuboCop and its extension configuration files are written in YAML. They are all placed in the same config directory, in each of the repositories respectively, assisted with a great RubyDoc documentations, which altogether makes it very easy to find and understand every rule.

When working on the Ruby on Rails project that uses either RSpec or MiniTest, we are going to install 4 RuboCop gems:

RuboCop
RuboCop Performance
RuboCop Rails
RuboCop RSpec or RuboCop MiniTest

Go ahead and edit your Gemfile, adding the following to the development and test group.

group :development, :test do
  gem 'rubocop'
  gem 'rubocop-performance'
  gem 'rubocop-rails'
  gem 'rubocop-rspec' # or gem 'rubocop-minitest'
end

Next in your CLI, navigate to the directory path of your Ruby on Rails project and run the bundle install command in order to update your Gemfile.lock.

Now that all the gems are installed, let us prepare our custom RuboCop configuration file, called .rubocop.yml.

It is responsible for two things:

Importing installed extensions
Defining which cops we do and do not want to enforce

By default, it uses the predefined RuboCop configuration with no other extensions installed, as it is designed to work with any Ruby language codebase.

In order to include the installed extensions, create the following RuboCop configuration file.

require: 
  - rubocop-performance
  - rubocop-rails
  - rubocop-rspec # or rubocop-minitest

Next, we are going to follow the example configuration for Ruby on Rails project presented in the RuboCop documentation - but in order to use the aforementioned extensions, we are going to skip some of it.

Add the following to your configuration file.

AllCops:
  Exclude:
    - 'db/**/*'
    - 'script/**/*'
    - 'bin/**/*'

It tells RuboCop to exclude given directories while analyzing the codebase - the readability does not matter there too much and is not worth bothering for the pleasing Ruby on Rails development.

Next, let us cut some additional slack while working with RuboCop. Those are the sane RuboCop rules to use with Ruby on Rails project.

Below the previous configuration, add the following.

Metrics/LineLength:
  Max: 100

Metrics/BlockLength:
  Exclude:
    - config/**/*
    - spec/**/*

Lint/AmbiguousBlockAssociation:
  Exclude:
    - spec/**/*

Style/Documentation:
  Enabled: false

Most of those are pretty self-descriptive, but let's go through them quickly:

Line length cop - that's the one you might want to change to your liking - it enforces a maximum amount of characters per single line of the code
Block length cop is told to ignore the config and spec directories, as those blocks of code tend to grow like mad, and we don't want to discourage our contributors to write fewer tests, right?
Ambiguous block association is turned off for the tests directory, as encouraged by the RuboCop HeadQuarters rockstar, bbatsov
Documentation cop is turned off, as there are better ways to document the Ruby on Rails code

It is important to remember that nothing here is written in stone - if you ever feel like you waste more time than its worth fixing some "stupid RuboCop rules", you can always disable them in this file.

At this point, assuming that you've recently created your brand new Ruby on Rails project the RuboCop analysis will give you some headache, as Ruby on Rails does not follow its default guidelines.

But worry not - most of it can be easily fixed using the RuboCop command with the --safe-auto-correct flag.

Let's not be naive, everything can crash, no matter if its name contains "safe" - create a backup of your recent changes to git first.

Then, navigate to your project directory and run the following.

bundle exec rubocop --safe-auto-correct

It will fix all RuboCop violations that are marked as auto-fixable in the default configuration file. Browse the changes and if it seems ok, add it to git.

There's also a big chance that you work on some much older Ruby on Rails codebase, and the quick-fix presented above might not be that effective, nor the best idea - some stuff might actually break.

Thankfully to the awesome RuboCop maintainers, there's a solution for legacy code implementations, the --auto-gen-config command-line flag.

In the root directory of your legacy Ruby on Rails project after installing all the gems and creating the configuration file, run the following.

bundle exec rubocop --auto-gen-config

It does two things:

Analyzes the codebase for RuboCop violations, writing the exclusions into the .rubocop_todo.yml file,
Updates the .rubocop.yml file with an import of the exclusions.

Now, if you run the bare bundle exec rubocop command again, it will show 0 offenses.

This is a great way for improving legacy Ruby on Rails applications code: just tell your team, that whenever anybody works on it, they should:

Look it up and comment-out a path to it in the TODO file,
Fix what's possible,
Delete the commented-out paths exclusions for good.

That way the Ruby on Rails codebase quality is going to improve vastly over time, eventually allowing developers to remove the TODO list completely.

Sharing RuboCop configuration in multiple Ruby on Rails projects

It is easy to set the RuboCop up for a single Ruby on Rails project, although, following the current microservices trend, that's hardly enough. There's a big chance that wherever you work at, your team either:

creates multiple Ruby on Rails projects monthly (like Software Houses do),
maintains multiple Ruby on Rails projects

RuboCop evolves, all its extensions do too, and developers' preferences change. Maintenance of all those moving parts along with keeping sane is not a trivial task. Imagine that company you work for has 15 microservices, all written in Ruby on Rails, and consider one of the following:

Your team decides that they don't like Department/Cop anymore
RuboCop releases a newer version
RuboCop Rails releases a newer version
RuboCop RSpec releases a newer version
RuboCop Performance releases a newer version

It's quite a copypaste task to keep it all up to date.

Percy, the QA SaaS, and Google APIs propose (and use themselves) a solution to that - creating your own gem with all the required extensions installed, a single source of the RuboCop configuration.

With your own gem, the "only" thing you need to do is updating it (and either backward-fixing or ignoring the "new" violations after the update) in every single project. There's automatically less room for error, as the single configuration per project would require you to update the core, every single extension and on top of that, the configuration file.

There's another option available, although I'm not a big fan of it, as in my opinion it is not controlled enough and might actually do some damage - with RuboCop, you might include the configuration from an URL address, so theoretically you would not need to manually update it in every single project.

What I don't like about it: if you lint the code in your Continuous Integration suite, it might suddenly cause your jobs to stop passing if new rules won't be backward compatible with the old code - and as a result, stop the development just to fix them.

Summing up, if your team maintains and/or creates a lot of Ruby on Rails applications, consider encapsulating your RuboCop configuration in the separated, shared gem.

Advanced RuboCop configuration

For all the standards nazis like myself, I'm going to mention yet another detail that I've recently discovered about RuboCop: it does not enable all its options by default.

See it for yourself.

Browse the config/default.yml file in the core RuboCop gem repository,
Search CTRL + F for the "Enabled: false" phrase.

At the time of writing this guide, there are 35 occurrences of the searched phrase, two of which are some explanatory comments.

It seems that there are 33 additional rules that one can potentially follow, improving the Ruby on Rails codebase even further!

Those are:

Bundler/GemComment: Add a comment describing each gem.
Layout/ClassStructure: Enforces a configured order of definitions within a class body.
Layout/FirstArrayElementLineBreak: Checks for a line break before the first element in a multi-line array.
Layout/FirstHashElementLineBreak: Checks for a line break before the first element in a multi-line hash.
Layout/FirstMethodArgumentLineBreak: Checks for a line break before the first argument in a multi-line method call.
Layout/FirstMethodParameterLineBreak: Checks for a line break before the first parameter in a multi-line method parameter definition.
Layout/HeredocArgumentClosingParenthesis: Checks for the placement of the closing parenthesis in a method call that passes a HEREDOC string as an argument.
Layout/MultilineArrayLineBreaks: Checks that each item in a multi-line array literal starts on a separate line.
Layout/MultilineAssignmentLayout: Check for a newline after the assignment operator in multi-line assignments.
Layout/MultilineHashKeyLineBreaks: Checks that each item in a multi-line hash literal starts on a separate line.
Layout/MultilineMethodArgumentLineBreaks: Checks that each argument in a multi-line method call starts on a separate line.
Lint/HeredocMethodCallPosition: Checks for the ordering of a method call where the receiver of the call is a HEREDOC.
Lint/NumberConversion: Checks unsafe usage of number conversion methods.
Migration/DepartmentName: Check that cop names in rubocop:disable (etc) comments are given with department name.
Style/AutoResourceCleanup: Suggests the usage of an auto resource cleanup version of a method (if available).
Style/CollectionMethods: Preferred collection methods: map, find, select, reduce, size by default.
Style/ConstantVisibility: Check that class and module constants have visibility declarations.
Style/Copyright: Include a copyright notice in each file before any code.
Style/DateTime: Use Time over DateTime.
Style/DocumentationMethod: Checks for missing documentation comments for public methods.
Style/ImplicitRuntimeError: Use raise or fail with an explicit exception class and message, rather than just a message.
Style/InlineComment: Avoid trailing inline comments.
Style/IpAddresses: Don't include literal IP addresses in code.
Style/MethodCallWithArgsParentheses: Use parentheses for method calls with arguments.
Style/MethodCalledOnDoEndBlock: Avoid chaining a method call on a do...end block.
Style/MissingElse: Require if/case expressions to have an else branches.
Style/MultilineMethodSignature: Avoid multi-line method signatures.
Style/OptionHash: Don't use option hashes when you can use keyword arguments.
Style/ReturnNil: Use return instead of return nil.
Style/Send: Prefer Object#send or Object#public_send to send, as send may overlap with existing methods.
Style/SingleLineBlockParams: Enforces the names of some block params.
Style/StringHashKeys: Prefer symbols instead of strings as hash keys.

Let's check out one that I personally like the most, the ClassStructure cop residing in the Layout department.

As its description states, Layout/ClassStructure enforces a configured order of definitions within a class body. There are multiple things that can be included in the Ruby class, and thanks to this cop we can make sure that all the classes written in the codebase define them in the custom or default order:

include
prepend
constants
initializer
public, private and protected methods

Next to those, there are multiple other Layout, Lint and Style cops, that put together remind me of some very wise words that I've read a long time ago.

Any codebase should look like it is written by a single person.

"Clean Code" by Robert Cecil Martin

That is the effect you might accomplish via the disabled by default RuboCop configuration.

Conclusion

RuboCop is a very powerful and the most popular code linting tool for the Ruby language.

Its configuration is not rocket science, so the amount of community knowledge on writing a clean, easily maintainable code comes with a very low price - all it takes is installing a few gems and writing a simple YAML file.

The only justification of not using it is knowing all those rules by heart - and I seriously doubt that there's a lot of people who do.

Using RuboCop when developing Ruby on Rails applications helps developers to avoid common mistakes, guards from the code formatting discrepancies and allows them to create a codebase that is well maintained and easy to understand.

Use RuboCop in your Ruby on Rails projects, period.

Quick guide on Ruby on Rails Continuous Integration with GitlabCI - why it's worth and how to get it running.

hix.dev — Thu, 30 Jan 2020 13:42:18 +0000

This is the ultimate guide for your next Ruby on Rails project setup on Gitlab with GitlabCI for continuous integration in 2020.

You can find original, 1:1 version on our website - feel invited!

Let's get started.

What is Gitlab?

Gitlab is, among all the other DevOps related features, one of the top git remote hosting cloud providers, next to Microsoft's Github and Atlassian's Bitbucket.

It can be both self-hosted or used via provided web UI on an official website. Like the other two giants, it offers an unlimited amount of public and private repositories, with limited users access extendable with a paid plan.

Fun fact is that both Ruby and Ruby on Rails are a big part of the Gitlab's tech stack.

Gitlab allows its users to integrate various pipelines into the code lifecycle, providing powerful GitlabCI, which should be rather called GitlabCD, for Continuous Delivery, as it equips developers with everything that's necessary to deliver code from their workstations straight to the production servers.

Why use Gitlab for Ruby on Rails app?

Creating constant backups of your code without using git or any other version control system would be true horror. Gitlab's biggest advantage for Ruby on Rails and projects written with any other frameworks is that on top of checkpoints in your codebase saved locally, you can host them in the cloud.

An ability to roll back to the older version of the code in case of introducing bugs in newer releases is yet another life-saving feature of Gitlab and other git remote hosting providers.

Another advantage is that with its massive usage as a self-hosted remote git repository solution there's a big chance that anybody that is going to collaborate with your code is going to know how to use Gitlab, so statistically, a learning curve is gone.

Thanks to its intuitive UI, Merge Requests, Code Review and Forks, Gitlab allows developers to easily work together.

On top of all that, it introduces its own, very advanced git branching strategy called GitLab flow.

Continuous Integration for Ruby on Rails

Continuous Integration (CI) in a programming world is a widely accepted practice that requires developers to push their work to the shared codebase continuously, ideally several times a day.

On top of general usages such as building programs and running the test suite against new features, new code might be verified against static code analysis tools knowledge base, pinpointing security vulnerabilities, common stylistic mistakes and all different kinds of inaccuracies.

Continuous Integration pipelines are a great place to ensure high code quality, well, continuously, which is good for both programmers and software itself.

There are multiple open-source static code analysis tools available for both Ruby and Ruby on Rails.

Most of them can be set up on the CI server to audit the code of Ruby on Rails project every time it's pushed, or nightly.

Why use GitlabCI for Ruby on Rails app?

GitlabCI is Gitlab's own solution for Continuous Integration and Delivery, hosted in its cloud.

It is tightly integrated with Gitlab repository hosting, turned on by default, so every time you create a new repository on Gitlab all you need to do in order to turn on its Continuous Integration solution for your project is providing a correct configuration file, .gitlab-ci.yml.

There are several shared runners available, so there's no need for your custom CI server maintenance (hello Jenkins), just one YAML file and you're all set.

No credit card information required, a perfect combination to start small with your project and pay for what you use as you grow.

GitlabCI provides an intuitive, well-organized UI with all the information required to establish the problem that occurs when the new code was integrated into the Gitlab hosted codebase.

It is crucial to set up the Continuous Integration system for any project, let alone Ruby on Rails, from the first day of the development.

This is a great way to avoid a lot of technical debt, protect yourself from common mistakes and enforce certain standards that make working with Ruby on Rails codebase pleasing and its maintenance much, much easier.

Create Ruby on Rails project on Gitlab

Follow the instructions below to create your Gitlab account and set up the Ruby on Rails project.

1.Sign up on the official Gitlab website.

2.Verify your email and complete the simple account creation wizard.
3.When successfully logged in, select "Create project".

4.Provide a project name and click "Create project".

5.Copy your new project's URL to the clipboard.

6.If you are using Hix on Rails, that's all you are going to need for now, just paste the address into the CLI when asked for it.
7.Navigate to the Ruby on Rails project root directory in the command line and enter git remote add origin YOUR_REPOSITORY_URL

Ruby on Rails project with GitlabCI pipelines

If you are using Hix on Rails - that's it. Your pipeline will run with all the code quality checks selected in the installation wizard upon the first push the remote. Beware that it will initially fail unless you create any database migration, as it is necessary for the database to be created.

Otherwise, if you still on the copy/paste duty instead of automating that part of your life, follow the steps below for Ruby on Rails project configuration on the GitlabCI.

In your project root, create the required GitlabCI configuration file.

cd path/to/your/project/root
touch .gitlab-ci.yml

Open the GitlabCI configuration file with a text editor of your choice and paste the basic code required, depending on which database you use.

Ruby on Rails with PostgreSQL on GitlabCI

PostgreSQL is the most popular choice for Ruby on Rails projects.

For the GitlabCI to test your application along with PostgreSQL you are going to need a specific setup in the config/database.yml file. We use the dotenv-rails gem.

config/database.yml

default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV['DB_POOL'] %>
  username: <%= ENV['DB_USERNAME'] %>
  password: <%= ENV['DB_PASSWORD'] %>
  host: <%= ENV['DB_HOST'] %>
  port: 5432

development:
  <<: *default
  database: hix_postgresql_development

test:
  <<: *default
  database: hix_postgresql_test

production:
  <<: *default
  database: hix_postgresql_development

If you decided to go with it, here's the basic GitlabCI configuration for the Ruby on Rails project build with the PostgreSQL database.

.gitlab-ci.yml

stages:
  - build
  - test

.build:
  image: ruby:2.6.5
  cache:
    key: rat-app-name
    paths:
      - apt-cache/
      - vendor/ruby
      - node_modules/
    policy: pull
  before_script:
    - gem install bundler --no-document
    - bundle install --jobs $(nproc) "${FLAGS[@]}" --path=vendor

.db:
  extends: .build
  services:
    - postgres:12.0
  variables:
    POSTGRES_USER: hix_postgresql
    POSTGRES_PASSWORD: hixonrails
    DB_USERNAME: hix_postgresql
    DB_PASSWORD: hixonrails
    DB_HOST: postgres
    RAILS_ENV: test
    DISABLE_SPRING: 1
    BUNDLE_PATH: vendor/bundle
  before_script:
    - export APT_CACHE_DIR=`pwd`/apt-cache && mkdir -pv $APT_CACHE_DIR
    - apt update -qq && apt -o dir::cache::archives="$APT_CACHE_DIR" install -yqq nodejs
    - gem install bundler --no-document
    - bundle install --jobs $(nproc) "${FLAGS[@]}" --path=vendor
    - bundle exec rails db:create db:schema:load --trace

As is, this file will fail the pipeline, it is only a strong foundation for further jobs presented in the guide.

Adjust the configuration file for this code to work with your project:

In the build Ruby image, line 6, adjust your Ruby version. At the time of writing this article the last stable version is used, 2.6.5.
In the database PostgreSQL image, line 20, adjust your PostgreSQL version. At the time of writing this article, the last stable version is used, 12.0.
You can freely change corresponding user and password values, respectively in lines 22 - 24 and 23 - 25, however it's not mandatory.
Replace all occurrences of the "hix_postgresql" with your Ruby on Rails project name.

It is important for the Continuous Integration suite to run on an environment as close to your production as possible.

To check your local PostgreSQL version, run the following command in the CLI.

psql -V

If you are developing some serious Ruby on Rails project, it is the best moment to install the latest stable version of the PostgreSQL database. If not, find the Docker PostgreSQL image corresponding to your local database version and adjust the GitlabCI configuration file accordingly.

Follow the next steps to actually use defined images in your continuous integration workflow.

Ruby on Rails with MySQL on GitlabCI

MySQL is the second most popular choice for Ruby on Rails applications, just behind the PostgreSQL.

For the MySQL to work you, same as with PostgreSQL, you are going to need a setup in the config/database.yml file adjusted to the one configuring the GitlabCI.

default: &default
  adapter: mysql2
  encoding: utf8
  pool: <%= ENV['DB_POOL'] %>
  username: <%= ENV['DB_USERNAME'] %>
  password: <%= ENV['DB_PASSWORD'] %>
  host: <%= ENV['DB_HOST'] %>
  port: 3306

development:
  <<: *default
  database: hix_mysql_development

test:
  <<: *default
  database: hix_mysql_test

production:
  <<: *default
  database: hix_mysql_production

If that's your choice, here's the basic GitlabCI configuration for the Ruby on Rails project build with the MySQL database.

stages:
  - build
  - test

.build:
  image: ruby:2.6.5
  cache:
    key: rat-app-name
    paths:
      - apt-cache/
      - vendor/ruby
      - node_modules/
    policy: pull
  before_script:
    - gem install bundler --no-document
    - bundle install --jobs $(nproc) "${FLAGS[@]}" --path=vendor

.db:
  extends: .build
  services:
    - name: mysql:8.0.18
      command: ['--default-authentication-plugin=mysql_native_password']
  variables:
    MYSQL_ROOT_PASSWORD: hixonrails
    DB_USERNAME: root
    DB_PASSWORD: hixonrails
    DB_HOST: mysql
    RAILS_ENV: test
    DISABLE_SPRING: 1
    BUNDLE_PATH: vendor/bundle
  before_script:
    - export APT_CACHE_DIR=`pwd`/apt-cache && mkdir -pv $APT_CACHE_DIR
    - apt update -qq && apt -o dir::cache::archives="$APT_CACHE_DIR" install -yqq nodejs
    - gem install bundler --no-document
    - bundle install --jobs $(nproc) "${FLAGS[@]}" --path=vendor
    - bundle exec rails db:create db:schema:load --trace

It needs a few tweaks in order to work with your particular project. Do the following:

In the build Ruby image, line 6, adjust your Ruby version. At the time of writing this article the last stable version is used, 2.6.5.
In the database MySQL image, line 21, adjust your MySQL version. At the time of writing this article, the last stable version is used, 12.0.
You can freely change corresponding root password values, respectively in lines 24 - 26, however, it's not mandatory.
Replace all occurrences of the "hix_postgresql" with your Ruby on Rails project name.

Be aware that those are only images to extend in order to use them for the jobs to follow and they do nothing by themselves, as they do not belong to any of the stages defined at the beginning of the GitlabCI configuration file.

I am going to state that again, in case you skipped the PostgreSQL section: it is important for the Continuous Integration suite to run on an environment as close to your production as possible.

Take a moment now to check your local MySQL version. In your local CLI, type:

mysql -V

and do one of the following:

Best: Update your local MySQL version to the latest stable one.
Good: Update your GitlabCI docker image to the one matching your local version - check an official Docker MySQL images
Bad: Do nothing (in case versions differ, because if they don't your technically in point 2).

If you went with the local update alternative, your future self is smiling at you right now. The second point is probably the most common choice, as all it takes is editing the configuration file.

The third option is plain wrong and it will cost you more time than it's worth it, eventually - go back to point 2.

Now that we have the installed bundle with our Ruby on Rails applications database ready to use, let's see what we can use them to run.

Ruby on Rails with RSpec on GitlabCI

RSpec is the favorite choice of the Ruby and Ruby on Rails community for writing tests.

It is important to check if newly developed features did not break older parts of the codebase and the Continuous Integration flow is a great place to do it. If you enforce the full test suite run from the Ruby on Rails application day one and agree with your team on some rational test coverage you will not regret it.

Speaking of the code coverage, there are great tools like SimpleCov, the Ruby gem for generating test coverage reports that hooked up with a Coveralls always tell you what's codebase code coverage at a glance, from the README.md badge level.

The Continuous Integration part of checking Ruby on Rails application tests health is really easy, all it takes is to store the results in the CI environment after the suite run. Reporting part comes in the RSpec configuration, you can read about it in the Ruby on Rails tested with RSpec article.

Overall, running the test suite of the Ruby on Rails project is the perfect job for the GitlabCI, so let's get to it.

Edit your GitlabCI configuration file with the following.

rspec:
  extends: .db
  stage: test
  cache:
    policy: pull-push
  artifacts:
    name: coverage
    paths:
      - coverage/
  script:
    - bundle exec rspec --profile 10 --format progress

You can skip the artifacts part of the job if you did not bother with SimpleCov configuration, but you don't have to. It is always possible to browse the coverage results from the GitlabCI level.

Another thing that's happening here is the profiling flag of our RSpec script - given the integer 10, it will show us the ten slowest unit tests in the whole suite.

Ruby on Rails with RuboCop on GitlabCI

RuboCop is the Ruby and Ruby on Rails community favorite linting tool. It checks the code against almost four hundred rules in its default configuration.

Along with the default gem corresponding to a Ruby Styleguide website, there are RuboCop extensions encapsulated in the separated gems for some of the most popular Ruby frameworks, including Ruby on Rails and RSpec.

On top of that, there's another gem authored by RuboCop Headquarters specifically checking the Ruby code performance, called, you guessed it, rubocop-performance.

If you decided to use the RuboCop in your Ruby on Rails project, the GitlabCI continuous integration suite is the place to do it - this way you can always be sure that your code is kept up to the RuboCop standard.

Edit the GitlabCI configuration file of your Ruby on Rails project with the following code.

rubocop:
  extends: .build
  stage: build
  cache:
    policy: pull-push
  script:
    - bundle exec rubocop

The RuboCop job does not require a Docker database image. We simply extend bare build, in which the gems bundle is installed - this way your CI runs faster every time.

For the complete RuboCop setup for Ruby on Rails applications using RSpec, please read the Ruby on Rails project RuboCop setup with RSpec.

Ruby on Rails with Brakeman on GitlabCI

If you keep the security of the Ruby on Rails project in mind, Brakeman is the way to go.

It is a simple command-line tool that checks the Ruby on Rails codebase against known security vulnerabilities, including SQL Injection and Cross-Site Scripting.

The GitlabCI Continuous Integration suite is the best place to check your code against Brakeman's knowledge of breaking Ruby on Rails stuff. If you decided to use it, edit your configuration file with the following.

brakeman:
  extends: .build
  stage: build
  cache:
    policy: pull-push
  script:
    - bundle exec brakeman --rails6 -A

Same as the RuboCop job, Brakeman does not need the Docker database image in order to run, so we save ourselves a few seconds every time and extend the bare build one.

Remember, that using any security audit tool does not guarantee that your Ruby on Rails application is 100% safe. Please read the Open Web Application Security Project Top 10 Project and on top of other things, audit your website regularly with tools like Mozilla Observatory.

Ruby on Rails with Fasterer on GitlabCI

Fasterer is a static Ruby code analysis command-line tool that corresponds to the open-source project called Fast Ruby.

It is the single biggest website with up-to-date benchmarks of various Ruby methods that are able to achieve the same goal, which allows programmers to find the fastest tool for a lot of stuff done with Ruby.

If you decide to use the Fasterer in your Ruby on Rails project, here's the GitlabCI Continuous Integration configuration for running the static performance analysis against the codebase.

fasterer:
  extends: .build
  stage: build
  cache:
    policy: pull-push
  script:
    - bundle exec fasterer

One configuration tweak worth pointing out and included in the example fasterer repository configuration file is to turn off each.with_index vs a while loop comparison when using with Ruby on Rails applications.

Ruby on Rails with Rails Best Practices on GitlabCI

Rails Best Practices is a Ruby on Rails blog by Xinmin Labs, with its last article written in 2014. Do not give up on it though, as most of its wisdom is still applicable now, and it is safe to say that it will be for a long time.

Next to the old but gold read, there's a static code analysis tool with the same "Rails Best Practices" name. It reports all the code violating the guidelines thoroughly explained on the website.

If you decide to follow the Rails Best Practices, your GitlabCI Continuous Integration suite for the Ruby on Rails project is the best place to do so.

rails_best_practices:
  extends: .build
  stage: build
  cache:
    policy: pull-push
  script:
    - bundle exec rails_best_practices

With this small additional GitlabCI configuration comes a lot of good stuff that will keep your Ruby on Rails codebase safe and sound, pointing out common mistakes that are otherwise easy to forget.

Conclusion

Gitlab is a very popular choice for Ruby on Rails applications remote version control and it comes with many benefits, one of which is its tremendous help in the DevOps world.

GitlabCI is a powerful yet very easy to set up cloud suite for Continuous Integration and Delivery, and it comes built-in and ready to use with every new Gitlab repository, for free.

A lot of Ruby on Rails community knowledge about how to do things correctly was forged into static code analysis tools.

Enforcing the standardized style guide for your Ruby on Rails application via GitlabCI jobs and pipelines is a great way to both learn the framework better and save yourself some trouble in the future.

Again, if you wish to help us in growing our tutorial base, please share this article to your dev friends! Kudos!

You can also take a look at Hix which we've made with love for Rails developers.

Why you should use Rollbar logger in your Rails project and how to configure it

hix.dev — Fri, 17 Jan 2020 13:27:58 +0000

This is the step by step guide to install and configure Rollbar logger in the Ruby on Rails project in 2020.

You can find the original, 1:1 piece on Rails + Rollbar configuration on our website.

Let's jump right into it, you'll see how easy it is to have error-free Rails application!

What is Rollbar?

Rollbar is a realtime application monitoring and error tracking software which one can visit anytime via a web browser.

Applications can communicate with Rollbar via the HTTP protocol, sending data about their crashes and exceptions.

Developers subscribe to Rollbar's notifications and can almost instantly react to production problems by easily pinpointing them via sophisticated UI, which provides a complete set of data necessary for the job.

Why use Rollbar with Ruby on Rails?

It is free to use up to 5000 API requests per month.
It gathers more data than the default Ruby on Rails logger.
It provides an intuitive UI, which is more comfortable to work with than primitive log files.

Ruby on Rails is provided with a basic logger that writes to the selected file, or files. Reading a single file with the constantly appended massive stack traces is a primitive way to monitor the application.

Rollbar collects and aggregates Ruby on Rails application crashes and exceptions data, with an additional context, such as a suspected release that started to cause the problem.

Via a sophisticated Rollbar web UI developer can browse errors by the latest, most occurrent and multiple additional pieces of information provided.

I cannot stress enough how crucial it is that your Ruby on Rails application is hooked up with an advanced logging and monitoring system such as Rollbar from its day one on production.

Rollbar account and project setup

Follow the instructions below to create your Rollbar account and set up Ruby on Rails project for further monitoring.

1.Sign up on the official Rollbar website. By default, every email from your email domain will be allowed to join.

2.Verify your email and set up your user credentials.

3.You'll be taken to the Quick Setup Overview. The first step is to create your project.

4.Enter your project name and press "Continue".

5.In the next step, select "Rails" for your project SDK.

6.Copy your Rollbar Access Token from the last step.

Rollbar allows you to set up multiple organization's projects and monitor them all via single web UI, which comes very handy especially for multiple services monitored daily.

Rollbar installation in Ruby on Rails project

If you use Hix on Rails, your job is done here, all you gonna do is paste your Rollbar Access Key into the first step of the Hix on Rails project initialization wizard.

Otherwise, if you sadly did not automate that part of your life yet, follow steps below for Ruby on Rails Rollbar configuration.

Open your projects Gemfile and paste the gem 'rollbar' so it's available for every environment.
In a command-line navigate to the project's directory, enter bundle install and while it runs go to the next step.
Create the config/rollbar.rb file and paste the minimal configuration required, replacing the value with previously copied Rollbar Access Key.
Create the config/initializers/rollbar.rb file to wrap a default Rails.logger so whenever you use it, the results are visible in the Rollbar UI.
To report exceptions occurring in the Ruby on Rails booting process add the code to the config/environment.rb file, as Rails does not provide a way to hook into it.

config/rollbar.rb

# frozen_string_literal: true

Rollbar.configure do |config|
  config.access_token = 'YOUR_ROLLBAR_ACCESS_TOKEN_GOES_HERE'
end

config/rollbar.rb

# frozen_string_literal: true

Rails.logger.extend(ActiveSupport::Logger.broadcast(Rollbar::Logger.new))

config/environment.rb

# frozen_string_literal: true

require_relative 'application'
require_relative 'rollbar'

notify = -> (e) do
  begin
    Rollbar.with_config(use_async: false) do
      Rollbar.error(e)
    end
  rescue
    Rails.logger.error 'Synchronous Rollbar notification failed.  Sending async to preserve info'
    Rollbar.error(e)
  end
end

begin
  Rails.application.initialize!
rescue Exception => e
  notify.call(e)
  raise
end

This is a minimal setup required to hook up your Ruby on Rails application with your newly created Rollbar account, via the dedicated rollbar gem.

It is overall a better idea to not store credentials in your project repository and use dedicated environmental management instead. For example, if you use a dotenv-rails gem, it is a better idea to provide your DSN via the .env file.

.env

ROLLBAR_ACCESS_KEY=YOUR_ROLLBAR_ACCESS_TOKEN_GOES_HERE

config/rollbar.rb

# frozen_string_literal: true

Rollbar.configure do |config|
  config.access_token = ENV['ROLLBAR_ACCESS_TOKEN']
end

Let's see what other configuration options are worth tweaking while monitoring Ruby on Rails project with Rollbar.

Ruby on Rails Rollbar configuration

With the minimalistic setup, we started to report Ruby on Rails application exceptions to the Rollbar.

Rollbar default configuration with the access key passed at this point is:

Rollbar.configure do |config|
  config.access_token = ENV['ROLLBAR_ACCESS_TOKEN']
  config.async_handler = nil
  config.before_process = []
  config.capture_uncaught = nil
  config.code_version = nil
  config.custom_data_method = nil
  config.default_logger = lambda { ::Logger.new(STDERR) }
  config.logger_level = :info
  config.delayed_job_enabled = true
  config.disable_monkey_patch = false
  config.disable_core_monkey_patch = false
  config.disable_rack_monkey_patch = false
  config.dj_threshold = 0
  config.enabled = nil # set to true when configure is called
  config.endpoint = DEFAULT_ENDPOINT
  config.environment = nil
  config.exception_level_filters = {
    'ActiveRecord::RecordNotFound' => 'warning',
    'AbstractController::ActionNotFound' => 'warning',
    'ActionController::RoutingError' => 'warning'
  }
  config.failover_handlers = []
  config.framework = 'Plain'
  config.ignored_person_ids = []
  config.payload_options = {}
  config.person_method = 'current_user'
  config.person_id_method = 'id'
  config.person_username_method = nil
  config.person_email_method = nil
  config.project_gems = []
  config.populate_empty_backtraces = false
  config.report_dj_data = true
  config.open_timeout = 3
  config.request_timeout = 3
  config.net_retries = 3
  config.js_enabled = false
  config.js_options = {}
  config.locals = {}
  config.scrub_fields = [:passwd, :password, :password_confirmation, :secret,
                        :confirm_password, :password_confirmation, :secret_token,
                        :api_key, :access_token, :accessToken, :session_id]
  config.scrub_user = true
  config.scrub_password = true
  config.randomize_scrub_length = false
  config.scrub_whitelist = []
  config.uncaught_exception_level = 'error'
  config.scrub_headers = ['Authorization']
  config.sidekiq_threshold = 0
  config.safely = false
  config.transform = []
  config.use_async = false
  config.use_eventmachine = false
  config.verify_ssl_peer = true
  config.web_base = DEFAULT_WEB_BASE
  config.write_to_file = false
  config.send_extra_frame_data = :none
  config.project_gem_paths = []
  config.use_exception_level_filters_default = false
  config.proxy = nil
  config.raise_on_error = false
  config.transmit = true
  config.log_payload = false
  config.collect_user_ip = true
  config.anonymize_user_ip = false
  config.backtrace_cleaner = nil
  config.hooks = {
    :on_error_response => nil, # params: response
    :on_report_internal_error => nil # params: exception
  }

  config.configured_options = ConfiguredOptions.new(self)
end

Environments setup

Using Rollbar reporting in the test and development environments is an overkill. You can set up when it's enabled via the configuration.

Rollbar.configure do |config|
  config.enabled = %w[production staging].include?(Rails.env)
end

If you want to give your custom name to the environment, you can do that by yet another environment-related configuration option.

Rollbar.configure do |config|
  config.environment = 'your_custom_environment_name'
end

Asynchronous reporting

Error logging is not the primary task of most of the web applications, including Ruby on Rails. It is good to keep it asynchronous, and Rollbar allows users to do so by exposing the asynchronous configuration for the most popular choices of asynchronous code execution in Ruby.

Sidekiq integration with Rollbar.

Rollbar.configure do |config|
  config.use_sidekiq, queue: :rollbar
end

SuckerPunch integration with Rollbar.

Rollbar.configure do |config|
  config.use_sucker_punch
end

GirlFriday integration with Rollbar.

Rollbar.configure do |config|
  config.use_async = true
end

DelayedJob integration with Rollbar.

Rollbar.configure do |config|
  config.delayed_job_enabled = true
  config.use_delayed_job, queue: 'rollbar'
  config.report_dj_data = true
  config.dj_threshold = 0
end

Data sanitization

As we can see in the Rollbar defaults above, the logger scrubs some of the data from its reports.

Rollbar.configure do |config|
  config.collect_user_ip = false
  config.anonymize_user_ip = true
  config.user_ip_obfuscator_secret = "a-private-secret-here"
  config.scrub_fields = [:passwd, :password, :password_confirmation, :secret,
                        :confirm_password, :password_confirmation, :secret_token,
                        :api_key, :access_token, :accessToken, :session_id]
  config.scrub_user = true
  config.scrub_password = true
  config.scrub_headers = ['Authorization']
end

We can further configure that by adding the custom fields that we want to remove from the reports or even whitelist some that we don't.

Users data

Whenever your Ruby on Rails application provides any kind of authentication for the visitors, you can report user data for an additional context.

Rollbar.configure do |config|
  config.person_method = "my_current_user"
  config.person_id_method = "id"
  config.person_username_method = "name"
  config.person_email_method = "email"
end

Pinpoint guilty release

For an easier way to estimate what caused the reported exception to occur it is useful to report some release context to Rollbar, ideally extracted from your code version control.

Rollbar.configure do |config|
  config.code_version = `git describe --abbrev=0`
end

The following will give you the most recent annotated git tag. If you follow the Semantic Versioning, it will be for example 3.17.2.

Proxy and Secure Sockets Layer

It is possible to report the Ruby on Rails exception occurrences to Rollbar via a proxy.

Rollbar.configure do |config|
  config.proxy = {
    host: 'http://some.proxy.server',
    port: 80,
    user: 'username_if_auth_required',
    password: 'password_if_auth_required'
  }
end

An exported environment variable https_proxy will be respected as well.

export https_proxy='http://username:password@example.com:5000'

On top of that, you can disable SSL verification with a configuration flag, as it's enabled by default.

Rollbar.configure do |config|
  config.verify_ssl_peer = false
end

Custom reports modifications

Every Ruby on Rails application exception reported to Rollbar is expandable. It accepts lambda as an argument and has to return a Hash later merged to the original exception.

Rollbar.configure do |config|
  conifg.custom_data_method = lambda {
    { android_version: 6, dimensions: { width: 320, height: 540 } }
  }
end

Once sent, it appears in the Occurrences tab of the exception reported.

If there's some really important functionality in our Ruby on Rails application, it is a good practice to prepare for the worst with custom exceptions and to set their severity to critical with configuration options.

Rollbar.configure do |config|
  config.exception_level_filters.merge!({
    'PaymentException': 'critical'
  })
end

The same configuration option comes to help if we want to ignore reporting a chosen exception.

Rollbar.configure do |config|
  config.exception_level_filters.merge!({
    'ActionController::RoutingError': 'ignore'
  })
end

However, it's not the most developer-friendly to always remember to add the critical error severity to the configuration. My advice is to define your own critical exception class and inherit from it further down the code whenever.

Conclusion

Rollbar is a powerful tool that helps you to keep the Ruby on Rails application well-maintained and is definitely worth using if you want to monitor every newly developed feature seriously.

With Hix on Rails, all you need to do in order to have a fully configured Rollbar logger is creating your account and copy-pasting the Rollbar Access Key into the project initialization wizard.

If you found the tutorial helpful, please spread the knowledge by sharing it! Thanks!

Also, if you wish us to cover something else, let us know in the comment.

Tracking your Ruby on Rails app errors with Sentry logger

hix.dev — Mon, 13 Jan 2020 13:38:34 +0000

This is the step by step guide to install and configure Sentry Raven logger in the Ruby on Rails project in 2020.

You can find the original, 1:1 piece on our blog.

Let's get started.

What is Sentry?

Sentry is a realtime application monitoring and error tracking software which one can visit anytime via a web browser.

Applications can communicate with Sentry via the HTTP protocol, sending data about their crashes and exceptions.

Developers subscribe to Sentry's notifications and can almost instantly react to production problems by easily pinpointing them via sophisticated UI, which provides a complete set of data necessary for the job.

Why use Sentry Raven with Ruby on Rails?

It is free to use up to 5000 API requests per month.
It gathers more data than the default Ruby on Rails logger.
It provides an intuitive UI, which is more comfortable to work with than primitive log files.

Sentry collects and aggregates Ruby on Rails application crashes and exceptions data, with an additional context, such as a suspected release that started to cause the problem.

Via a sophisticated Sentry web UI developer can browse errors by the latest, most occurrent and multiple additional pieces of information provided.

I cannot stress enough how crucial it is that your Ruby on Rails application is hooked up with an advanced logging and monitoring system such as Sentry from its day one on production.

Sentry account and project setup

Follow the instructions below to create your Sentry account and set up the Ruby on Rails project for further monitoring.

1.Sign up on the official Sentry website.

2.In the second onboarding step, select "Rails" platform.

3.From the third onboarding step copy your Sentry DSN

The DSN abbreviation stands for Data Source Name and is autogenerated for every project that you are going to hook into your Sentry account.

It allows you to keep all the logs in one place, which comes very handy especially for multiple services monitored daily.

Sentry Raven installation in Ruby on Rails project

If you use Hix on Rails, your job is done here, all you gonna do is paste your Sentry DSN into the second step of the Hix on Rails project initialization wizard.

Otherwise, if you sadly did not automate that part of your life yet, follow steps below for Ruby on Rails Sentry configuration.

Open your projects Gemfile and paste the gem 'sentry-raven' so it's available for every environment.
In a command-line navigate to the project's directory, enter bundle install and while it runs go to the next step.
Create the config/initializers/sentry.rb file and paste the minimal configuration required, replacing the value with previously copied Sentry DSN.

config/initializers/sentry.rb

# frozen_string_literal: true

Raven.configure do |config|
  config.dsn = 'YOUR_SENTRY_DSN_GOES_HERE'
end

This is a minimal setup required to hook up your Ruby on Rails application with your newly created Sentry account, via the dedicated sentry-raven gem.

.env

SENTRY_DSN=YOUR_SENTRY_DSN_GOES_HERE

config/initializers/sentry.rb

# frozen_string_literal: true

Raven.configure do |config|
  config.dsn = ENV['SENTRY_DSN']
end

Let's see what other configuration options are worth tweaking while monitoring Ruby on Rails project with Sentry.

Ruby on Rails Sentry configuration

With the minimalistic setup, we started to report Ruby on Rails application exceptions to the Sentry.

Raven default configuration with the DSN passed at this point is:

Raven.configure do |config|
  config.dsn = ENV['SENTRY_DSN']
  config.async = false
  config.context_lines = 3
  config.current_environment = current_environment_from_env
  config.encoding = 'gzip'
  config.environments = []
  config.exclude_loggers = []
  config.excluded_exceptions = IGNORE_DEFAULT.dup
  config.inspect_exception_causes_for_exclusion = false
  config.linecache = ::Raven::LineCache.new
  config.logger = ::Raven::Logger.new(STDOUT)
  config.open_timeout = 1
  config.processors = DEFAULT_PROCESSORS.dup
  config.project_root = detect_project_root
  config.rails_activesupport_breadcrumbs = false
  config.rails_report_rescued_exceptions = true
  config.release = detect_release
  config.sample_rate = 1.0
  config.sanitize_credit_cards = true
  config.sanitize_fields = []
  config.sanitize_fields_excluded = []
  config.sanitize_http_headers = []
  config.send_modules = true
  config.server = ENV['SENTRY_DSN']
  config.server_name = server_name_from_env
  config.should_capture = false
  config.ssl_verification = true
  config.tags = {}
  config.timeout = 2
  config.transport_failure_callback = false
  config.before_send = false
end

Environments setup

By default, whenever provided a valid DSN, Sentry Raven will work automatically in every Ruby on Rails environment, where the defaults are test, development, and production.

That's overkill for the development environment, so my advice is to further configure it after checking if it works.

Raven.configure do |config|
  config.environments = %[production]
end

This way an automated test suite and development of new features won't eat up your quota.

Another closely related option that is wisely deduced by Raven is current environment detection.

First, Sentry tries to get ENV['RAILS_ENV']
Next, if first is absent, it tries ENV['RACK_ENV']

You can customize it via the current environment configuration flag.

Raven.configure do |config|
  config.current_environment = 'staging'
end

Whatever you'll set here, will be visible in the Sentry environments dropdown.

Asynchronous reporting

Error logging is not the primary task of most of the web applications, including Ruby on Rails. It is good to keep it asynchronous, and Sentry allows users to do so by exposing the asynchronous configuration flag.

Raven.configure do |config|
  config.async = lambda { |event| SentryJob.perform_later(event) }
end

app/jobs/sentry_job.rb

class SentryJob < ActiveJob::Base
  queue_as :sentry

  def perform(event)
    Raven.send_event(event)
  end
end

If the async callback raises an exception, Raven will attempt to send synchronously.

Data sanitization

Sentry for Ruby on Rails provides two configuration options for data sanitization.

Raven.configure do |config|
  config.sanitize_fields = ["my_field", "foo(.*)?bar"]
  config.sanitize_http_headers = %w[Referer User-Agent Server From]
end

The field sanitization accepts a raw string and regex-like strings for striping the data from the requests sent to Sentry.

The second one allows you to filter out HTTP headers from the payload. A full list of potentially sensitive HTTP headers can be found in the RFC 2616.

Data processing

The default Sentry data processors are:

# Note the order - we have to remove circular references and bad characters
# before passing to other processors.
DEFAULT_PROCESSORS = [
  Raven::Processor::RemoveCircularReferences,
  Raven::Processor::UTF8Conversion,
  Raven::Processor::SanitizeData,
  Raven::Processor::Cookies,
  Raven::Processor::PostData,
  Raven::Processor::HTTPHeaders
].freeze

which we can modify via yet another configuration flag by adding new and removing existing processors from the array.

require 'raven/processor/removestacktrace'

Raven.configure do |config|
  config.processors << Raven::Processor::RemoveStacktrace
  config.processors -= [Raven::Processor::PostData]
  config.processors -= [Raven::Processor::Cookies]
end

You might want to remove cookies and post data processors via the configuration, as by default Sentry does not send POST data or cookies if present, and it may improve your further debugging experience.

A full list of the Raven processors belonging to the Raven::Processor module.

├── processor
│   ├── cookies.rb
│   ├── http_headers.rb
│   ├── post_data.rb
│   ├── removecircularreferences.rb
│   ├── removestacktrace.rb
│   ├── sanitizedata.rb
│   └── utf8conversion.rb

On top of all that, Sentry allows filtering out selected exceptions by appending them to the excluded exceptions array.

Raven.configure do |config|
  config.excluded_exceptions += ['ActionController::RoutingError']
end

On an even deeper level, Sentry allows you to prevent exceptions from being sent via providing your custom logic.

Raven.configure do |config|
  config.should_capture = Proc.new do |exception|
    exception.super != 'WillinglyUnreportedException'
  end
end

It is especially useful when you want to filter out a whole bunch of exceptions without always remembering to put them into the excluded exceptions array.

class WillinglyUnreportedException < StandardError; end
class DontCareTooMuchException < WillinglyUnreportedExceptions; end
class NevermindException < WillinglyUnreportedExceptions; end

Another option that might be especially useful for large applications is data sampling.

Raven.configure do |config|
  config.sample_rate = 0.5
end

A value of 0 will deny sending any events, and value of 1 will send every single event, which is the default behavior.

Pinpoint guilty release

Sentry is clever in deducing which release causes an exception. It takes the following in the given order of precedence.

Commit SHA of the last git commit
Last line of the application root REVISION file
For Heroku, dyno metadata enabled via Heroku Labs

It can be customized if you have some kind of custom release tracking system.

Raven.configure do |config|
  config.release = 'custom release string'
end

The default settings may be configured smoothly with popular git remote providers such as Github and Gitlab for convenient linking to the guilty git commits and tags via Sentry UI.

Proxy and Secure Sockets Layer

Sentry gives its user an option to configure a proxy connection.

Raven.configure do |config|
  config.proxy = 'http://example.com'
end

It accepts a simple string representing the URL to your proxy server.

SSL verification might be disabled in the configuration file, as it's enabled by default.

Raven.configure do |config|
  config.ssl_verification = false
end

Custom reports modifications

In your configuration file, you can use two options provided for globally customizing Sentry reports.

Raven.configure do |config|
  config.tags = { hostname: `hostname` }
  config.before_send = lambda do |event, hint|
    event.fingerprint = ['fingerprint']
    event
  end
end

A first of them, the tagging option, allows you to send an additional context with your events for further filtering. For example, if you have a load balancer set up in front of your Ruby on Rails application, you might want to send some info identifying a specific instance on which the exception occurred.

The second one helps you to modify every single occurrence on the fly, accessing it before is send. Be aware that if you won't return the event from this method, it will be dropped.

Conclusion

Sentry is a powerful tool that helps you to keep the Ruby on Rails application well-maintained and is definitely worth using if you want to monitor every newly developed feature seriously.

With Hix on Rails, all you need to do in order to have a fully configured Sentry logger is creating your account and copy-pasting the Sentry DSN into the project initialization wizard.

If you enjoyed reading through, please share this article or follow us for more!

Ruby on Rails set up on Github with CircleCI

hix.dev — Fri, 10 Jan 2020 11:47:54 +0000

This is the ultimate guide for your next Ruby on Rails project setup on Github with CircleCI for continuous integration in 2020.

So let's start with some basic knowledge.

Note: A full 1:1 "Ruby on Rails set up on Github with CircleCI" article was originally posted on our website. You can also find more tutorials already there.

What is Github?

Github is one of the top 100 websites on the Internet, with ~310M monthly visits. It holds the biggest OpenSource codebase in the world.

One can safely say that it's a proven tool in a programmers' toolbox.

Fun fact is that Ruby, with Ruby on Rails, is a big part of the Github's tech stack.

Among all the other features, Github is a remote repository hosting for the git version control system. When developers create their code, they make constant changes, additions, improvements and deletions to the codebase.

The version control system stores these code revisions in a central repository, which allows programmers to easily collaborate, as they can download the new version of the software, add their changes and upload them.

Why use Github for Ruby on Rails app?

The biggest advantage of using Github for Ruby on Rails project, as well as any other remote repository hosting provider, is that you can create constant backups of your code

Git provides a full history of changes and an ability to roll back to the older version of the code in case of introducing changes that causes errors.

With Github, it is available at any point in time, online. You are not limited to the single machine on which code was written.

Another advantage is that with its massive Open Source codebase there is a big chance that anybody that is going to collaborate with your code is going to know how to use Github, so statistically, a learning curve is the smallest possible.

Github provides an intuitive UI that allows developers to easily collaborate, with its Pull Requests, Code Review and Forks.

It even introduces its own git branching strategy, called GitHub flow.

Continuous integration for Ruby on Rails

Continuous Integration (CI) is a development practice that requires collaborators to upload their code to the shared repository continuously, ideally several times a day.

Every time they do, the code is verified by an automated build, the test suite runs and dedicated static code analysis tools check it for security vulnerabilities, errors, and all kinds of inaccuracies.

It is good for both developers and software to automatically check the code quality and CI a great place to do it.

There are multiple open-source static code analysis tools available for both Ruby and Ruby on Rails.

Most of them can be set up on the CI server to audit the code of Ruby on Rails project every time it's pushed or nightly.

Why use CircleCI for Ruby on Rails app?

CircleCI is a Continous Integration and Delivery cloud provider.

It integrates with Github, so using both of them together is as simple as creating your accounts and setting up the Ruby on Rails project.

No custom servers maintenance, just going through some web forms and you are all set.

No credit card information required, a perfect combination to start small with your project and pay for what you use as you grow.

CircleCI provides an intuitive, well-organized UI with all the information required to establish the problem that occurs when the new code was integrated into the Github hosted codebase.

It is crucial to set up the Continuous Integration system for any project, let alone Ruby on Rails, from the first day of the development.

Create Github account and Ruby on Rails project

Follow the instructions below to create your Github account and set up the Ruby on Rails project.

1.Sign up on the official Github website.

2.Verify your email.
3.You will be redirected to the new Github repository creation page.
4.Provide the repository name and click the "Create repository" button.

5.On the new repository page, get your remote repository HTTPS or SSH link.

6.If you are using Hix on Rails, that's all you are going to need for now, just paste the address into the CLI when asked for it.

7.Navigate to the Ruby on Rails project root directory in the command line and enter git remote add origin YOUR_REPOSITORY_URL

Create CircleCI account linked to Github

Follow the instructions below to create your CircleCI account linked to your Github account, and to set up the Ruby on Rails project continuous integration.

1.Click "Sign up with Github" on the official CircleCI website.

2.On the authorization page, click "Authorize circleci".

3.You will be redirected to the CircleCI dashboard. From the left-side sidebar, select "Add Projects".

4.In the projects tab, click "Set up project" next to the newly created Github project.

Ruby on Rails project on CircleCI

If you are using Hix on Rails, that's it, all you need to do is click "Start building" after pushing the code with your first database migration, as the database creation is a part of the Ruby on Rails application build process and it will fail if no tables are present.

Otherwise, if you sadly did not automate that part of your life yet, follow steps below for Ruby on Rails project configuration on the CircleCI.

In your project root, create the required CircleCI configuration file.

cd path/to/your/project/root
mkdir .circleci
touch .circleci/config.yml
~~~{% endraw %}

Open the CircleCI configuration file with a text editor of your choice and paste the basic code required, depending on your database choice.

##Ruby on Rails with PostgreSQL on CircleCI

PostgreSQL is the most popular choice for Ruby on Rails applications.

For the CircleCI to work you are going to need a specific setup in the {% raw %}`config/database.yml`{% endraw %} file. Notice that the [dotenv-rails](https://github.com/bkeepers/dotenv) gem is used.

{% raw %}`config/database.yml`{% endraw %}{% raw %}

~~~yaml
default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV['DB_POOL'] %>
  username: <%= ENV['DB_USERNAME'] %>
  password: <%= ENV['DB_PASSWORD'] %>
  host: <%= ENV['DB_HOST'] %>
  port: 5432

development:
  <<: *default
  database: hix_postgresql_development

test:
  <<: *default
  database: hix_postgresql_test

production:
  <<: *default
  database: hix_postgresql_production
~~~{% endraw %}

If you decided to go with it, here's the basic CircleCI configuration for the Ruby on Rails project build with the PostgreSQL database.{% raw %}

~~~yaml
version: 2.1

executors:
  default:
    working_directory: ~/hix_postgresql
    docker:
      - image: circleci/ruby:2.6.5
        environment:
          BUNDLE_JOBS: 3
          BUNDLE_PATH: vendor/bundle
          BUNDLE_RETRY: 3
          BUNDLER_VERSION: 2.0.1
          RAILS_ENV: test
          DB_HOST: 127.0.0.1
          PG_HOST: 127.0.0.1
          PGUSER: hixonrails
      - image: circleci/postgres:12.0
        environment:
          POSTGRES_DB: hix_postgresql_test
          POSTGRES_USER: hixonrails

commands:
  configure_bundler:
    description: Configure bundler
    steps:
      - run:
          name: Configure bundler
          command: |
            echo 'export BUNDLER_VERSION=$(cat Gemfile.lock | tail -1 | tr -d " ")' >> $BASH_ENV
            source $BASH_ENV
            gem install bundler

jobs:
  build:
    executor: default
    steps:
      - checkout
      - restore_cache:
          keys:
            - hix_postgresql-`{{ .Branch }}`-`{{ checksum "Gemfile.lock" }}`
            - hix_postgresql-
      - configure_bundler
      - run:
          name: Install bundle
          command: bundle install
      - run:
          name: Wait for DB
          command: dockerize -wait tcp://127.0.0.1:5432 -timeout 1m
      - run:
          name: Setup DB
          command: bundle exec rails db:create db:schema:load --trace
      - save_cache:
          key: hix_postgresql-`{{ .Branch }}`-`{{ checksum "Gemfile.lock" }}`
          paths:
            - vendor/bundle
      - persist_to_workspace:
          root: ~/
          paths:
            - ./hix_postgresql

workflows:
  version: 2
  integration:
    jobs:
      - build
~~~

There are multiple adjustments necessary for this code to work with a particular project.

1. In the Docker Ruby image, line 7, adjust your Ruby version. At the time of writing this article the last stable version is used, 2.6.5
2. In the Docker PostgreSQL image, line 17, adjust your PostgreSQL version. At the time of writing this article the last stable version is used, 12.0.
3. In lines 16 and 20, you can adjust the PostgreSQL user name, however, it's not mandatory.
4. Replace all occurrences of the "hix_postgresql" with your Ruby on Rails project name.

For the workflow to pass on the CircleCI, you need to have {% raw %}`db/schema.rb`{% endraw %} file checked into the repository, which means that you need to create at least one database migration.

##Ruby on Rails with MySQL on CircleCI

MySQL is the second most popular choice for Ruby on Rails applications, just behind the PostgreSQL.

For the CircleCI to work you are going to need a specific setup in the {% raw %}`config/database.yml`{% endraw %} file. Notice that the [dotenv-rails](https://github.com/bkeepers/dotenv) gem is used.

{% raw %}`config/database.yml`{% endraw %}{% raw %}

~~~yaml
default: &default
  adapter: mysql2
  encoding: utf8
  pool: <%= ENV['DB_POOL'] %>
  username: <%= ENV['DB_USERNAME'] %>
  password: <%= ENV['DB_PASSWORD'] %>
  host: <%= ENV['DB_HOST'] %>
  port: 3306

development:
  <<: *default
  database: hix_mysql_development

test:
  <<: *default
  database: hix_mysql_test

production:
  <<: *default
  database: hix_mysql_production
~~~{% endraw %}

If you decided to go with it, here's the basic CircleCI configuration for the Ruby on Rails project build with the PostgreSQL database.

~~~yaml
version: 2.1

executors:
  default:
    working_directory: ~/hix_mysql
    docker:
      - image: circleci/ruby:2.6.5
        environment:
          BUNDLE_JOBS: 3
          BUNDLE_PATH: vendor/bundle
          BUNDLE_RETRY: 3
          BUNDLER_VERSION: 2.0.1
          RAILS_ENV: test
          DB_HOST: 127.0.0.1
          DB_USERNAME: root
          DB_PASSWORD: ''
      - image: circleci/mysql:8.0.18
        command: [--default-authentication-plugin=mysql_native_password]
        environment:
          MYSQL_ALLOW_EMPTY_PASSWORD: 'true'
          MYSQL_ROOT_HOST: '%'

commands:
  configure_bundler:
    description: Configure bundler
    steps:
      - run:
          name: Configure bundler
          command: |
            echo 'export BUNDLER_VERSION=$(cat Gemfile.lock | tail -1 | tr -d " ")' >> $BASH_ENV
            source $BASH_ENV
            gem install bundler

jobs:
  build:
    executor: default
    steps:
      - checkout
      - restore_cache:
          keys:
            - hix_mysql-`{{ .Branch }}`-`{{ checksum "Gemfile.lock" }}`
            - hix_mysql-
      - configure_bundler
      - run:
          name: Install bundle
          command: bundle install
      - run:
          name: Wait for DB
          command: dockerize -wait tcp://127.0.0.1:3306 -timeout 1m
      - run:
          name: Setup DB
          command: bundle exec rails db:create db:schema:load --trace
      - save_cache:
          key: hix_mysql-`{{ .Branch }}`-`{{ checksum "Gemfile.lock" }}`
          paths:
            - vendor/bundle
      - persist_to_workspace:
          root: ~/
          paths:
            - ./hix_mysql

workflows:
  version: 2
  integration:
    jobs:
      - build
~~~

There are multiple adjustments necessary for this code to work with a particular project.

1. In the Docker Ruby image, line 7, adjust your Ruby version. At the time of writing this article the last stable version is used, 2.6.5
2. In the Docker MySQL image, line 17, adjust your MySQL version. At the time of writing this article the last stable version is used, 8.0.18.
3. Replace all occurrences of the "hix_mysql" with your Ruby on Rails project name.

For the workflow to pass on the CircleCI, you need to have `db/schema.rb` file checked into the repository, which means that you need to create at least one database migration.

##Ruby on Rails with RSpec on CircleCI

[RSpec](https://rspec.info/) is the most popular Ruby testing framework, hence the tool of our choice.

In the continuous integration flow, running the test suite is one of the most common jobs, to ensure that new features do not break other well-tested parts of a Ruby on Rails application.

On top of that, RSpec can be easily configured with [SimpleCov, the ruby gem for generating test coverage reports](https://github.com/colszowka/simplecov). Generating those reports gives developers a nice overview on how the Ruby on Rails application is maintained.

This is the perfect job for the CircleCI, so if you have decided to go with it, edit the previously created configuration file, adding the RSpec job and running it in the defined workflow.

~~~yaml
jobs:
  build:
    executor: default
    steps:
      - checkout
      - restore_cache:
          keys:
            - hix-`{{ .Branch }}`-`{{ checksum "Gemfile.lock" }}`
            - hix-
      - configure_bundler
      - run:
          name: Install bundle
          command: bundle install
      - run:
          name: Wait for DB
          command: dockerize -wait tcp://127.0.0.1:3306 -timeout 1m
      - run:
          name: Setup DB
          command: bundle exec rails db:create db:schema:load --trace
      - run:
          name: RSpec
          command: |
            bundle exec rspec --profile 10 \
                              --format progress
      - store_artifacts:
          path: coverage
      - save_cache:
          key: hix-`{{ .Branch }}`-`{{ checksum "Gemfile.lock" }}`
          paths:
            - vendor/bundle
      - persist_to_workspace:
          root: ~/
          paths:
            - ./hix

workflows:
  version: 2
  integration:
    jobs:
      - build
~~~

For the RSpec to work it needs the Ruby on Rails project to be built and the database to be set up.

You can skip the part that stores the artifacts if you did not bother with the SimpleCov setup.

The profiling flag is another thing that's nice to have in the CI workflow - it tells you which tests are the slowest to run.

[Hix on Rails](https://hixonrails.com) comes additionally configured to use [Coveralls](https://coveralls.io/), which gives a nice test coverage percentage badge for your Ruby on Rails project's README.md.

##Ruby on Rails with RuboCop on CircleCI

[RuboCop](https://github.com/rubocop-hq/rubocop) is the most popular Ruby code linting tool available, with almost 400 rules checked in the default configuration.

Next to the default gem, there are plugins that check the Ruby on Rails, RSpec and Ruby code performance rules, which combined gives as the total of almost 500 rules checked, every time new code is contributed to the codebase.

If you decided to use the RuboCop in your Ruby on Rails project here's the CircleCI configuration required.{% raw %}

~~~yaml
  rubocop:
    executor: default
    steps:
      - attach_workspace:
          at: ~/
      - configure_bundler
      - run:
          name: Rubocop
          command: bundle exec rubocop

workflows:
  version: 2
  integration:
    jobs:
      - build
      - rubocop:
          requires:
            - build
~~~{% endraw %}

For the complete RuboCop setup for Ruby on Rails applications using RSpec, please read the [Ruby on Rails project RuboCop setup with RSpec](https://hixonrails.com/ruby-on-rails-tutorials/ruby-on-rails-project-rubocop-setup-with-rspec/).

##Ruby on Rails with Brakeman on CircleCI

[Brakeman](https://brakemanscanner.org/) is the most popular ruby gem for Ruby on Rails applications security vulnerabilities audit.

It provides a simple command-line tool that among the total 29 warnings, checks your Ruby on Rails application code for possible [SQL Injection](https://rails-sqli.org/) or [Cross-Site Scripting](https://excess-xss.com/) attacks.

The CircleCI continuous integration suite is the perfect place to check your code for security, so if you decided to use Brakeman in your Ruby on Rails application, here's the required CircleCI configuration.

~~~yaml
brakeman:
    executor: default
    steps:
      - attach_workspace:
          at: ~/
      - configure_bundler
      - run:
          name: Brakeman
          command: bundle exec brakeman

workflows:
  version: 2
  integration:
    jobs:
      - build
      - brakeman:
          requires:
            - build
~~~

Remember, that using any security audit tool does not guarantee that your Ruby on Rails application is 100% safe. Please read the [Open Web Application Security Project Top 10 Project](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) and on top of other things, audit your website regularly with tools like Mozilla Observatory.

##Ruby on Rails with Fasterer on CircleCI


[Fast Ruby](https://github.com/JuanitoFatas/fast-ruby) is the open-source project with a multitude of various benchmarks between different Ruby methods able to achieve the same goal.

[Fasterer](https://github.com/DamirSvrtan/fasterer) is a ruby gem, a static code analysis command-line tool that's able to check your code for potentially faster solutions, based on the Fast Ruby benchmarks.

If you decide to use the Fasterer, your continuous integration flow on CircleCI is a perfect place to do so.{% raw %}

~~~yaml
  fasterer:
    executor: default
    steps:
      - attach_workspace:
          at: ~/
      - configure_bundler
      - run:
          name: Fasterer
          command: bundle exec fasterer

workflows:
  version: 2
  integration:
    jobs:
      - build
      - fasterer:
          requires:
            - build
~~~{% endraw %}

One option that is recommended to be turned off for Ruby on Rails project using Fasterer is the {% raw %}`each.with_index`{% endraw %} versus the while {% raw %}`loop`{% endraw %}, all the rest of a default configuration is good to go.

##Ruby on Rails with Rails Best Practices on CircleCI

[Rails Best Practices](https://rails-bestpractices.com/) is an old but gold blog about Ruby on Rails applications development. It explains with a great detail common Ruby on Rails (and other) patterns, like "Law of Demeter" and "Tell, don't ask".

Next to the great read, there's another static code analysis tool, called… [Rails Best Practices](https://github.com/flyerhzm/rails_best_practices). It makes sure to report any Ruby on Rails application code that does not apply to the guides written on the blog.

If you decide to use it, your continuous integration suite on CircleCI is the perfect place to do so.

~~~yaml
  rails_best_practices:
    executor: default
    steps:
      - attach_workspace:
          at: ~/
      - configure_bundler
      - run:
          name: Rails Best Practices
          command: bundle exec rails_best_practices

workflows:
  version: 2
  integration:
    jobs:
      - build
      - rails_best_practices:
          requires:
            - build
~~~

I strongly recommend against giving up on the tool only because the blog's last update was in 2014. All of the rules, as well as all the code quality checks, are still applicable in the latest Ruby on Rails version.

##Conclusion

Ruby on Rails is a very popular choice for web application development and it comes with many benefits, one of which is the well-established community knowledge on how to do things correctly.

A lot of this knowledge was forged into static code analysis tools that let developers find their mistakes easily.

CircleCI is trivial to use yet very powerful Continous Integration provider that lets you build, test and audit your Ruby on Rails application code with minimal setup, for free.

If you care about the Ruby on Rails application code quality and easy maintenance, that's the perfect combination for you.



Hope you like the tutorial! If you wish to learn more, follow us on dev.to or visit [our blog](https://hixonrails.com/ruby-on-rails-tutorials/). Thanks!