Skip to end of metadata
Go to start of metadata

This is the application compliance evaluation template which can be used to "grade" how well a web application follows the Rails best practices.  This template can be completed as part of an ART review and can be used as a tool in that over-arching process.  The goal is to provide as many objective data points as possible and use those data points to improve compliance and consistency going forward.  Clearly, the template and data points will evolve over time, but this should provide a solid basis for the discussions that trigger that evolution.  While scoring something like this can be somewhat subjective, the goal is to provide as objective and quantifiable of an assessment as possible.

 

 

CategoryS/UStandardExampleApplication ApproachScoreComment
Project Name

 

Agreed upon Project name or CodeName

ATLMaps

   
Project Organization 

When you create a new Rails app. All the necessary files (Gemfile, config.ru, REDME, etc) are generated by Rails.

The developer should add and manage the CHANGELOG and DEPLOYNOTES files.

<project>/
/app
..../controller
..../helpers
..../models
..../views
......../layouts
/components
/config
/db
/doc
/lib
/log
/public
/script
/test
/tmp
/vendor
README
CHANGELOG
DEPLOYNOTES
Rakefile
   

Environment settings

 

Settings that apply to all environments (Test, Dev, Staging, Prod) are set in `config/environment.rb`. Settings for specific environments are placed in seperate .rb files in `config/environment/` eg: `config/environment/development.rb`

    

Ruby Dependencies

 

List all Ruby gems required

Rails

Ruby version

   

Documentation

 

 

Using the markup language make sure all public classes, functions and variables are documented.

    

DEPLOYNOTES

 

Should be in MD format for use with RDoc

Should contain a section(s) describing the process for a first time install. If there are any differences between a dev or prod install, this should be noted here.

There should be an additional sections broken down by release describing what needs to be done to upgrade to that release.

The release sections should be ordered from most recent to oldest.

 

   

CHANGELOG

 

Should be in MD format for use with RDoc

Should contain sections broken down by release describing major features / bugs in the release

 


.

   

README

 

Should be in MD format for use with RDoc

Should contain general information about the project.

    

Logic distributed appropriately

 

Any non-response-related logic should go in the model, ideally in a nice, testable method. The controller is simply a nice interface between the view and model.

    
Build, Packaging and Deploy 

Add the Capistrano gem to your project and configure your environment files with the Git repo and the target server. The deploy user's ssh key will need to be added to the Git repo.

Capistrano takes care of the symlinks

    
Unit Testing 

75% of public (and appropriate private) methods should be covered by tests unless there are special circumstances. Use your best judgement as to how complex these need to be.

 

 

    
API Use ActiveModelSerializer for JSON responses. Responses are paginated, contain metadata, and comply with the JSON API specification.    
Use with Ember Use the Ember Data JSON API adapter to load data from the Rails API    
Total GradeS/U    % Rails Compliance Score

General Comments

This is where the evaluator can add general comments about the application that either add to comments made above or discuss other items that may not be covered in the categories above.

This section allows the reviewers to document action items and assign those tasks to an individual or group to be completed.

Action Item DescriptionAssigned ToDue DateDate CompleteComments
     
     
  • No labels