Main Menu

Project Life Cycle

Releasing procedure

Simplified version

Each cNIS release should cover the following procedure:

  1. FEATURE DEVELOPMENT
    1. Team implements features.
    2. Team prepares data migration tool.
    3. Team updates documentation according to implemented features.
      1. Release Manager creates new documentation space on forge for big releases (i.e. version number changed at X or Y position in X.Y.Z pattern).
      2. Team puts new screenshots for implemented features if it is needed, e.g. new good looking feature was added. (do it)
  2. BINARIES BUILDING
    1. Release Manager invokes the automatic release function to build and put artifacts into first (QA) stage.
    2. Release Manager tests the installers - checks whether installation process is not broken.
    3. Release Manager deploys demo instance for internal testing (cnis-sprint machine).
    4. Team tests the build internally.
  3. VERSION RELEASE
    1. Release Manager updates the Forge sites:
      1. update Documentation section with a link to the recent documents (do it)
      2. add a new entry to the 'downloads' table - links to "Final stage" artifacts (do it)
    2. Release Manager upgrades demo instances (official demo).
    3. Release Manager notifies the community.
    4. Release Manager marks version as released in JIRA.

Full version

Each cNIS release should cover the following procedure:

  1. FEATURE DEVELOPMENT
    1. Scrum Master arranges Release/Sprint planning meeting.
    2. Team elects a new Release Manager.
    3. Team implements features.
    4. Team verifies implemented features (tested-by field).
    5. Team prepares data migration tool.
    6. Team updates documentation according to implemented features.
      1. Release Manager creates new documentation space on forge for big releases (i.e. version number changed at X or Y position in X.Y.Z pattern).
      2. Team puts new screenshots for implemented features if it is needed, e.g. new good looking feature was added. (do it)
  2. BINARIES BUILDING
    1. Release Manager tests the automatic release function on last Monday of the sprint.
    2. Release Manager makes release branch on SVN when all developers report end of work.
    3. Branch is used in further steps
      1. Team uses branch only to fix important bugs in release version
      2. Team uses trunk to develop new functionality
    4. Staging phase starts. We distinguish the following stages:
      1. The "QA" stage - build is ready for internal tests.
      2. The "Final" stage - build is accepted (has production quality) to be published to the community.
    5. Release Manager invokes the automatic release function to build and put artifacts into first (QA) stage.
    6. Release Manager tests the installers - checks whether installation process is not broken.
    7. Release Manager deploys demo instance for internal testing (cnis-sprint machine).
    8. Team tests the build internally.
    9. Team fixes bugs and staging phase is started again when bugs are found during internal tests.
    10. Release Manager promotes the build to next stage (Final) when internal tests are passed.
    11. Staging phase ends.
  3. VERSION RELEASE
    1. Release Manager updates the Forge sites:
      1. update Documentation section with a link to the recent documents (do it)
      2. add a new entry to the 'downloads' table - links to "Final stage" artifacts (do it)
    2. Release Manager upgrades demo instances (official demo).
    3. Release Manager notifies the community.
    4. Release Manager marks version as released in JIRA.
    5. Testers Team (Milan) tests released version.
    6. Scrum Master arranges the review and retrospection meeting.
Skip to end of metadata
Go to start of metadata
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.