|
|
# Altum Guidelines
|
|
|
|
|
|
Welcome to the Altum Software (Internal) Community Guidelines!
|
|
|
|
|
|
## Project Setup
|
|
|
|
|
|
All the projects should have a **README.MD** file. Ideally this file should be in english – you never know if and when a foreign third-party will join the project. The goal for the README.MD is to have a clear set of instructions that allows any developer to be able to run the project without requiring any other help.
|
|
|
|
|
|
### This file must contain updated instructions on:
|
|
|
* Required **OS packages** that must be installed in order to run the project
|
|
|
* Detailed instructions on how to **run the project for the first time**
|
|
|
* How to setup the **sample data**
|
|
|
* Documentation URL for the **Icon package**, if any
|
|
|
* Any different coding standards and Architectures being used on the project
|
|
|
* URL and User/Password info to access the software, if it makes sense for the project
|
|
|
* How to run the **Test Suite**
|
|
|
|
|
|
## Quality
|
|
|
|
|
|
### Environments
|
|
|
1. Have a working **dev** and **staging** environments. The staging must be as close as possible to the production env.
|
|
|
2. **Synchronize** the production database into the staging db **frequently**. With this you can track down bugs easier and better simulate real-world scenarios before something unexpected happens on production.
|
|
|
|
|
|
### Testing
|
|
|
1. **Do unit tests**. Seems kinda unnecessary at first, but when you have a lot of them it starts to become really useful.
|
|
|
2. **Do functional testing** as much as possible. It's perhaps the most guaranteed form of automatic testing available.
|
|
|
3. We recommend using **Capybara** and **Cucumber** for functional tests. A lot of our projects use it, so you'll have a lot of people internally that can help to speed up the development of the tests.
|
|
|
|
|
|
## Technology-specific guidelines
|
|
|
|
|
|
* [Ruby on Rails](ruby-on-rails) |
|
|
\ No newline at end of file |