Release Management

From stoney cloud
Revision as of 08:26, 24 April 2014 by Michael (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Jump to: navigation, search

Release Cycles

Each release cycle should follow this pattern:

  1. Development (2 - 4 Weeks): During this phase, new functionalities are developed.
  2. 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:

  1. Trunk (development): Master branch, normally without name tags, for testing reasons we set tags: v0.5.0_pre1
  2. 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
  3. 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:

The main framework called stoney core, which is responsible for shared functionality (like user management, rights and roles).

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.

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
Retrieved from "https://wiki.stoney-cloud.org/mediawiki/index.php?title=Release_Management&oldid=3280"