Changes

Release Management

1,620 bytes added, 07:26, 24 April 2014
/* Testing */
* Features are scheduled on the individual module [[:Category:Roadmap|roadmap]] pages for implementation in specific future stable versions and are implemented (and tested) in development versions.
* A new major version will be released, when all features and goals specified for this version are implemented and tested.
 
TBD: Describe stable and unstable in more detail
= Development =
== Source Code Organization ==
We have the All stoney cloud related repositories like installer, nodesource code is located on GitHub under https://github.com/stoney-integration, cloud... These we keep as is (for To avoid clashes with over projects, every repository has the moment)default prefix '''stoney-'''.
The web interface consists a bunch of modulesSome operating system related examples:* https://github. Each module has a separate GitHub git repository containing the following subcom/stoney-structurecloud/stoney-gentoo-overlay* https://github.com/stoney-cloud/stoney-gentoo-portage
GitHubThe main framework called [[:* Form follows functionCategory: we choose the stoney core|stoney core]], which is responsible for shared functionality name (so we are backwards compatiblelike user management, rights and roles).* Modules are collected in one repository (create a skeleton module as an example)https://github.com/stoney-cloud/stoney-core** Data https://github.com/stoney-cloud/stoney-core/api (LDAPREST API)** API https://github.com/stoney-cloud/stoney-core/cli (PHP)** Web Command Line Interface (PHP, uses API)** Provisioning (Perl, https://github...)** Tests com/stoney-cloud/stoney-core/web (GUI, Unit-Tests, ...Ajax based web interface)
Then we have the [[:Category:Self-Service Modules|Self-Service Modules]] with [[:Category:stoney backup|stoney backup]] as an example. This Self-Service Module provides an on-line backup service for desktops, servers and virtual machines.* https://github.com/stoney-cloud/stoney-backup* https://github.com/stoney-cloud/stoney-backup/api (REST '''a'''pplication '''p'''rogramming '''i'''nterface)* https://github.com/stoney-cloud/stoney-backup/cli ('''c'''ommand '''l'''ine '''i'''nterface)* https://github.com/stoney-cloud/stoney-backup/helpers (helper scripts and programmes)* https://github.com/stoney-cloud/stoney-backup/provisioning (scripts and programmes to provision services)* https://github.com/stoney-cloud/stoney-backup/web (Ajax based web interface) See the [[Modularisation]] page for further details. == Committing / Git Workflow ==We follow the Git branching model according to: http://nvie.com/posts/a-successful-git-branching-model/
== Committing ==
Each change-set in the git repository (and thus each commit) ideally contains only one concise and consistent change.
The commit-message precisely describes the change. If the change is in respond to a bug-report or feature-request, the number of the bug-report or feature-request is included.
 
== Scrum Labels ==
* '''Not Started''': not yet assigned to or accepted by any member.
* '''Assigned''': being assigned to or accepted by a member.
* '''In Progress''': being implemented.
* '''To Verify''': implementation done and now it is time for testing/verifying.
* '''Done''': ticket is verified.
== Testing ==
Testing is done in a clean test environment and '''not''' in a developer environment.
This means: all changes have to be committed to the git repository first and checked out from there in the test environment for proper testing.
 
* tests can be run on different levels
** framework-level (symfony/php unit tests)
** API-level:
*** JSON Schema compliance
*** client-test via [http://frisbyjs.com/ frisby.js]
== Bug-Reporting/-Workflow ==
SLB, editor, reviewer
3,368
edits