You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Builds should be provided periodically during the course of a given Sprint. The rule of thumb has been to provide builds when major functionality/changes are completed. This has proven helpful, even giving QA builds early in the Sprint to get a jump on testing/feedback.

  1. All new functionality and changes should have an accompanying Jira issue.
  2. Developer should add notes to the issue detailing changes made (if not obvious) and fixed build.
  3. Release build engineer signed up to do the build Live should be the same one that creates builds on Test for the given Sprint.
    (Standard configuration management practice is that each build to Test has the intention of being able to move Live so the configuration management person should be able to repeat the build process to Test when they build to Live.)

Release notes should accompany each build noting resolved Jira issues. Release notes in the Wiki have worked out well and have been helpful for creating public release notes at the end of each Sprint.

  • No labels