Difference between revisions of "Release Management"
From stoney cloud
| [unchecked revision] | [unchecked revision] |
(→Versions) |
(→Testing) |
||
| (20 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
Each release cycle should follow this pattern: | Each release cycle should follow this pattern: | ||
# '''Development''' (2 - 4 Weeks): During this phase, new functionalities are developed. | # '''Development''' (2 - 4 Weeks): During this phase, new functionalities are developed. | ||
| − | # ''' | + | # '''Testing and bug fixing''' (1 - 2 Weeks): This gives time for the users to test and the time bug fixing and a quick retest. |
| − | + | ||
= Versioning = | = Versioning = | ||
| Line 14: | Line 13: | ||
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. | Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. | ||
| − | * Scheme: major.minor.patch, example: <code>1.2.3</code>. | + | * <s>Scheme: major.minor.patch, example: <code>1.2.3</code>.</s> |
| − | * Odd minor version numbers denote development/unstable branches. For example, stoney cloud 0.8.x is considered stable, while stoney cloud 0.9.x is considered development/unstable. | + | * <s>Odd minor version numbers denote development/unstable branches. For example, stoney cloud 0.8.x is considered stable, while stoney cloud 0.9.x is considered development/unstable.</s> |
* New features are added to unstable/development versions only. | * New features are added to unstable/development versions only. | ||
* We have separate version numbers for the separate components (installer, online-backup, ldap-schemas, ...). | * We have separate version numbers for the separate components (installer, online-backup, ldap-schemas, ...). | ||
| − | + | We start with '''0.1.0''' for development and '''0.2.0''' for first stable release. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | = Development = | + | = Development Procedure = |
| − | + | We have a minimum of two branches: | |
| − | + | # Trunk (development): Master branch, normally without name tags, for testing reasons we set tags: v0.5.0_pre1 | |
| + | # Branch 1 to N (stable branch(es) for bug fixing): v0.2, the tag for a release would be: v0.2.1 to v0.2.N | ||
| + | # Branch 2 (second stable branch for bug fixing): v0.4, the tag for a release would be: v0.4.1 to v0.4.N | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | This results in the following development procedure: | |
| + | * 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 == | |
| − | + | All stoney cloud related source code is located on GitHub under https://github.com/stoney-cloud. To avoid clashes with over projects, every repository has the default prefix '''stoney-'''. | |
| − | + | Some operating system related examples: | |
| + | * https://github.com/stoney-cloud/stoney-gentoo-overlay | ||
| + | * https://github.com/stoney-cloud/stoney-gentoo-portage | ||
| − | + | The main framework called [[:Category:stoney core|stoney core]], which is responsible for shared functionality (like user management, rights and roles). | |
| + | * https://github.com/stoney-cloud/stoney-core | ||
| + | * https://github.com/stoney-cloud/stoney-core/api (REST API) | ||
| + | * https://github.com/stoney-cloud/stoney-core/cli (Command Line Interface) | ||
| + | * https://github.com/stoney-cloud/stoney-core/web (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/ | |
| − | |||
Each change-set in the git repository (and thus each commit) ideally contains only one concise and consistent change. | 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 | + | 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 == | ||
Testing is done in a clean test environment and '''not''' in a developer environment. | 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. | 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 == | == Bug-Reporting/-Workflow == | ||
Latest revision as of 08:26, 24 April 2014
Contents
Release Cycles
Each release cycle should follow this pattern:
- Development (2 - 4 Weeks): During this phase, new functionalities are developed.
- Testing and bug fixing (1 - 2 Weeks): This gives time for the users to test and the time bug fixing and a quick retest.
Versioning
Semantic Versioning: Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
-
Scheme: major.minor.patch, example:1.2.3. -
Odd minor version numbers denote development/unstable branches. For example, stoney cloud 0.8.x is considered stable, while stoney cloud 0.9.x is considered development/unstable. - New features are added to unstable/development versions only.
- We have separate version numbers for the separate components (installer, online-backup, ldap-schemas, ...).
We start with 0.1.0 for development and 0.2.0 for first stable release.
Development Procedure
We have a minimum of two branches:
- Trunk (development): Master branch, normally without name tags, for testing reasons we set tags: v0.5.0_pre1
- Branch 1 to N (stable branch(es) for bug fixing): v0.2, the tag for a release would be: v0.2.1 to v0.2.N
- Branch 2 (second stable branch for bug fixing): v0.4, the tag for a release would be: v0.4.1 to v0.4.N
This results in the following development procedure:
- Features are scheduled on the individual module 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
All stoney cloud related source code is located on GitHub under https://github.com/stoney-cloud. To avoid clashes with over projects, every repository has the default prefix stoney-.
Some operating system related examples:
- https://github.com/stoney-cloud/stoney-gentoo-overlay
- https://github.com/stoney-cloud/stoney-gentoo-portage
The main framework called stoney core, which is responsible for shared functionality (like user management, rights and roles).
- https://github.com/stoney-cloud/stoney-core
- https://github.com/stoney-cloud/stoney-core/api (REST API)
- https://github.com/stoney-cloud/stoney-core/cli (Command Line Interface)
- https://github.com/stoney-cloud/stoney-core/web (Ajax based web interface)
Then we have the Self-Service Modules with 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 application programming interface)
- https://github.com/stoney-cloud/stoney-backup/cli (command line interface)
- 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/
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 frisby.js
Bug-Reporting/-Workflow
Bugs are to be reported on the modules issue tracker on GitHub.
Ideally we have someone who acts as the Bug-Wrangler. His tasks are:
- go over unassigned bugs and properly assign them (since we can't expect users to properly assign bugs)
- discover and close duplicated, invalid or otherwise inappropriate bugs (so the Bug-Wrangler must have search-fu)
- request more information from the user if necessary (like the version of involved components, canned responses can be used/saved in the GitHub issue tracker for that purpose)
- request time estimates from developers
- kick developers and testers and make sure the issue-list stays short (therefore it would make sense if it's someone from stepping stone GmbH)
- manage the priority of bugs if necessary
