Tag: how-to-run-with-rails

How to Run with Rails: Setup subdomains in your routes

These days the use of subdomains are commonplace amongst businesses, they can be used to divide up public and private sections of an application or simply define an API structure. Therefore, when creating routes for a specific subdomain in your application, you need to ensure these routes are only accessible when hitting the predefined subdomain. It goes without saying this can help to improve security and control the user experience for your customers and administrators.

The first thing we need to do is decide which routes are going to belong to which subdomain and break them up respectively in your config/routes.rb configuration file. In the example below we have two collections of routes which will require access from a different subdomain.

Once we have decided which routes belong to which subdomain we can begin adding constraints to our route resources.; these constraints basically act as validations and/or conditions when a user tries to access a route. You can add a number of different constraints to a route such as IP address, HTTP verb, content type, format and more. We want to constrain a batch of routes for our example, so we decide to use a block constraint with an argument containing the constraint conditions.




In the above example I am passing the AdminSubdomain and AccountSubdomain library classes as a parameter in our route constraints. These library classes utilise the request object to validate whether the subdomain property matches the required subdomain value, thereby returning a true or false value. This class can be extended to include additional validations and/or conditions, which makes it a powerful and clean solution when defining block constraints in your routes.

But what If I just want to just assign a constraint to a single route?

This can also be achieved with little effort by just assigning the constraint directly to the route, for example:

If you’d like more information on how routing works in the Ruby on Rails platform, check out their detailed documentation: http://guides.rubyonrails.org/routing.html

16th March 2016

How to Run with Rails: Configure Travis CI to use multiple databases

When building any large application, a stable and efficient test suite is a must in order to maintain a reliable codebase. Thanks to tools such as RSpec and MiniTest, building your own test suite for your Ruby on Rails application can be a fairly painless endeavour. However, when building open source projects, you need to ensure your application has been tested in several different environments. Today we are going to look at how to test your application with several database softwares within the Travis CI cloud testing suite.

Once you have set up your account over at Travis CI and configured your application to begin running tests within the platform, we can start to build our configuration files. Our aim is to tell Travis CI to run tests for each of the commonly used database softwares: MySQL, PostgreSQL and SQLite. We can achieve this by passing environment variables within the .travis.yml configuration file. As you can see from the example below taken from the Trado github repository, we have defined 3 database types under the matrix subcategory; global environment variables are data values which are used globally across all builds whereas matrix environment variables trigger one build per item. For example:

When Travis CI receives the new commit, it will run a build for each database in the matrix environment variable list. You can view each individual build in the UI, as seen below:

Screen Shot 2016-03-09 at 14.01.31

If you would like more information, check out the Travis CI documentation: https://docs.travis-ci.com/user/environment-variables/#Global-Variables

Need help cleaning up your test database when running tests? Check out my post about using DatabaseCleaner: http://tomdallimore.com/blog/taking-the-test-trash-out-with-databasecleaner-and-rspec/

09th March 2016