Many of the DLSS software projects are Ruby on Rails applications. Consistency across projects can aid developers and reduce the overall maintenance burden on teams. This guide should be used as an outline on common expectations in DLSS Ruby on Rails projects. Not only should our projects reflect consistency internally, but should also reflect larger community expectations. These are not rules, but guidelines aimed to help the team.
DLSS projects should be open source by default. See licensing. Developers should never check in api keys or private information. Use the config gem instead. If you have any questions, check with dev-ops first.
We use capistrano for deployment. More information
Use the config gem for configuration management. Use shared-configs to store senstive data.
Projects should have implemented continuous integration. The following services are used often:
- GitHub or CircleCI for running test suites
- CodeCov or CodeClimate for test coverage
See Monitoring.
Use the default database.yml from Rails unless there is a reason not to. Prefer to not tie your project to a specific SQL implementation unless necessary. You should use Rails migrations to specify and manage your database schema.
Rails projects in DLSS should use the RSpec Rails framework for Ruby testing. See the Testing chapter for more information.