Skip to content

GitLab

Guidelines
Guidelines
Commit 45cf7f77 authored by Ondřej Moravčík's avatar Ondřej Moravčík
Browse files
Options

ryses

parent cb177dbd
Hide whitespace changes
Inline Side-by-side
Showing with 43 additions and 57 deletions
DEV/4_CORE_IMPLEMENTATIONS.md
View file @ 45cf7f77
......@@ -34,16 +34,16 @@ Purpose must be clear from description or linked issue. In case of ambiguity MR
#### 3. Code check
1. CI tests passes?
- Check the reason why some tests failed. One random test failure is not a problem.
- Feature test on Poltergeist are sometimes unstable.
- Check the reason why some tests failed. One random test failure is not a problem.
- Feature test on Poltergeist are sometimes unstable.
2. Manual testing.
- Manual test of usage on localhost or prepared deployment.
- This test are quick and only scratching surface (e.g. localisations), QA tester is responsible for functionality.
- Manual test of usage on localhost or prepared deployment.
- This test are quick and only scratching surface (e.g. localisations), QA tester is responsible for functionality.
3. Style check.
- Done according [code style](./CODE_STYLE.md).
- Done according [code style](./CODE_STYLE.md).
4. Assessment.
- Every MR gets :+1: or :-1:.
- According result one of following happens:
1. MR is merged to target branch
2. MR is assigned to other reviewer for consultation
3. MR is returned to resolve issues
- Every MR gets :+1: or :-1:.
- According result one of following happens:
1. MR is merged to target branch
2. MR is assigned to other reviewer for consultation
3. MR is returned to resolve issues
DEV/README.md
View file @ 45cf7f77
......@@ -6,7 +6,7 @@
3. [Separate new plugin](#3-separate-new-plugin)
4. [Core implementations](#4-core-implementations)
2. [Development](#development)
1. [RYS engines](./RYS.md)
1. [RYS engines/gems](./RYS.md)
3. [Code style](./CODE_STYLE.md)
4. [Common errors](./COMMON_ERRORS.md)
5. [Repositories](./REPOSITORIES.md)
......@@ -56,7 +56,7 @@ Development of new plugin for Easy Project. Plugin is created from the scratch a
#### 4. Core implementations
Implementation of internal plugins and core features of Easy Project. The most reviewed level with highest expectation on style and quality.
Implementation of internal plugins and core features of Easy Project. The most reviewed level with highest expectation on style and quality.
Keeping of rules is required for acceptance.
......@@ -180,7 +180,7 @@ All text **must use** I18n and must be translated at least to EN, this includes
##### Active record migration
In Easy Project we recognize 2 types of migrations, data and schema.
In Easy Project we recognize 2 types of migrations, data and schema.
Schema migrations handle only changes to schema of database.
......@@ -203,29 +203,3 @@ Check for it with `ruby -wc PATH_TO_FILE`. In orders to check all files :
```
find . -name "*.rb" -type f -exec ruby -wc {} \; | grep -v OK
```
### RYSy
This topic explain some RYS specific dev requirements. What is RYS you can see in full documentation - can be found [on project's wiki](https://github.com/easysoftware/rys/wiki).
#### Versioning
All our RYSy are versioned by semantic versioning. For details please see [https://semver.org/#semantic-versioning-200](https://semver.org/#semantic-versioning-200)
3. level - MAJOR - includes changes which are release specific - lots of changes, refactoring and whole new features, migrations and etc.
4. level - MINOR - includes new small features, migrations, minor change of internal logic
5. level - PATCH (or bug-fix) - its only for bug-fixing or harmless changes, such as documentation, readme, etc. ! This version must not include migrations and breaking chagnes !
#### Release cycle
In RYS repositories there are always 2 protected branches - `master` and `devel`.
Our idea is that `master` branch contains stable version of RYS, which is in production (clients application have `~>` for this version). `devel` instead is branch for future features.
Distribution of RYS engines is done by our gems server ([http://gems.easysoftware.com](http://gems.easysoftware.com)). You can push to this server new version of RYS only by following rules:
2. production release is merged to `master` branch, there is properly CHANGELOG and version of RYS is increased.
3. when you need pre-release feature branch, you always need to use `beta`version + its a MAJOR version change
DEV/RYS.md
View file @ 45cf7f77
......@@ -8,29 +8,41 @@ RYS engines are separated to few gems, and source code is on github. So for full
https://github.com/easysoftware/rys
You can see what is a RYS in documentation at [on project's wiki](https://github.com/easysoftware/rys/wiki).
## DEV guide of RYS
#### Versioning
All our RYSy are versioned by semantic versioning. For details please see [https://semver.org/#semantic-versioning-200](https://semver.org/#semantic-versioning-200)
3. level - MAJOR - includes changes which are release specific - lots of changes, refactoring and whole new features, migrations and etc.
1. level - MAJOR - includes changes which are release specific
- lots of changes, refactoring and whole new features, migrations and etc.
4. level - MINOR - includes new small features, migrations, minor change of internal logic
2. level - MINOR - includes new small features
- migrations, minor change of internal logic
5. level - PATCH (or bug-fix) - its only for bug-fixing or harmless changes, such as documentation, readme, etc. ! This version must not include migrations and breaking chagnes !
3. level - PATCH (or bug-fix) - its only for bug-fixing or harmless changes
- documentation, readme, etc.
- **!!! This version cannot include migrations and breaking changes !!!**
#### Release cycle
In RYS repositories there are always 2 protected branches - `master` and `devel`.
Our idea is that `master` branch contains stable version of RYS, which is in production (clients application have `~>` for this version). `devel` instead is branch for future features.
Our idea is that `master` branch contains stable version of RYS, which is in production (clients application have `~>` for this version).
`devel` is a branch for future features.
Distribution of RYS engines is done by our gems server ([http://gems.easysoftware.com](http://gems.easysoftware.com)). You can push to this server new version of RYS only by following rules:
Distribution of RYS gems are done by our gems server ([http://gems.easysoftware.com](http://gems.easysoftware.com)). You can push to this server new version of RYS only by following rules:
2. production release is merged to `master` branch, there is properly CHANGELOG and version of RYS is increased.
1. production-ready release is merged into `master` branch
- there is a proper CHANGELOG.md
- version of the RYS is increased
3. when you need pre-release feature branch, you always need to use `beta`version + its a MAJOR version change
2. when you need pre-release feature branch,
- you always need to use `beta`version + its a MAJOR version change
- for example `2.0.0.beta`
# Lukas's personal workflow
......@@ -48,7 +60,7 @@ We have prepared simple generator of RYS engines
1. Add in your Redmine gem "rys"
2. Run rails generate of RYS
rails generate rys:plugin NAME
### Move generated code to work directory
......@@ -77,19 +89,19 @@ This dummy I have symlinked to `test/dummy` in RYS engine.
How I do this... (working example)
1. Get Easy Redmine
git clone devel -b devel devel
2. Setup Easy Redmine (database.yml)
bundle install --without rmagick xapian
3. Generate RYS
rails g rys:plugin ruzovy_jednorozec --path ../
4. Prepare dummy
git clone devel -b devel dummy
cd dummy/plugins
rm -r * && git checkout easyproject easy_job
......@@ -99,16 +111,16 @@ How I do this... (working example)
vim config/database.yml
5. Link dummy to RYS
cd ../ruzovy_jednorozec
mkdir test
test folder is in `.gitignore` by default
ln -s [~/projects/ or absolute path]dummy test/dummy
6. Make it together
bundle install --without rmagick xapian
rake app:db:create app:db:migrate
rake app:easyproject:install # this work from ER 05.00
......@@ -139,12 +151,12 @@ Finished in 0.50731 seconds (files took 2.92 seconds to load)
### Conclusion
When code is pushed to gitlab, CI will run test with whole devel repository (by default).
This is guide based my experience with RYS development, it may not be for everyone ok...
This is guide based my experience with RYS development, it may not be for everyone ok...
#### Cons
* Test only part of application - other plugins can change behaviour and in this way you missed it...
* Another window with whole ER is needed.
* Another window with whole ER is needed.
#### Pros
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment