Repository structure
In this article we will show you how to get correct repository structures in the different environments.
Development Levels
Development of Easy8 is divided into four levels:
Redmine
This is the main Rails app on which our system is built. It's the forbidden zone, because if a new version of Redmine is released, we replace our Redmine with the new version and all changes are overwritten.
Client modifications
Changes for a specific client according to his needs. Coding takes place only in a generated folder /plugins/easyproject/easy_plugins/modification_*. Usage of own controllers and views is preferred. Modification of existing views is done by calling hooks.
Modification plugin can by generated using:
Changes in other plugins will be overwritten during update, so it's critical to only make changes in the folder mentioned above.
Changes in core folders are permitted in only exceptional cases after previous approval. Author takes sole responsibility in those cases.
Functionality is checked mostly by the client. Because of minimal changes to core files there is little or no code review.
Repos for client specific modifications
There are repositories for adjustments we made for some clients. It's usually a fork of some release state of platform, but with added customizations.
RYS repos
In RYS repositories there are always 2 protected branches - master and devel.
Our idea is that master branch contains stable version of the RYS, which is in production (clients application has ~> to this version).
Develis a branch for future features <- do merge-request againstdevel.
Versioning
All our RYSes are versioned using semantic versioning.
First level - MAJOR - changes are release specific:
- Whole new features
- Refactoring
- Breaking changes
Second level - MINOR - includes new small features:
- Migrations
- Minor changes of internal logic
Third level - PATCH (or BUG-FIX) - only for bug-fixing or harmless changes:
- Documentation
- Readme
Patch versions cannot include migrations and breaking changes!