WebsitePanel Release Cycles

To provide structure to WebsitePanel product development cycle we would like to introduce a convention for release cycles. This document focusses on the below aspects:

  • A naming convention for releases
  • QA release cycles/plans
  • RTW release cycles/plans 

Terms:

Release To Web (RTW)

The Release to web is a PROD release done every 6 weeks. Code changes will be deployed to the trunk of the project. The bits will be production-ready and will be officially supported by Microsoft Paid Support.

Quality Assurance/Test (QA)

The QA releases are intermediate releases of the code. These are not merged with the trunk of the code until the RTW cycle. The QA releases consists of small bug fixes or feature additions that are made incrementally to a development branch until a RTW release cycle at which point it is merged into the trunk. The QA releases are builds that make the changes to code available for testers. This is to encourage feedback during the process of development against only final feedback after PROD deployment.

High level summary of the release cycles:

  • 6 weeks RTW release cycle
  • 4 weeks of feature additions
  • Weekly builds available for testing (Builds deployed to Dev/QA. Not for production environments)
  • 2 weeks of QA (integration and functional testing)
  • RTW post QA sign-off. Production ready stable release.

Release cycles diagram:

spacer

WebsitePanel Release cycle

Roles:

Contributor

The contributor participates in additions to the Dev branch of the code. The contributor typically works on a single feature and commits it to the current development branch. The contributor cannot work directly on the QA/RTW versions of the code. The contributor can make pull requests to the development branch and the core team has the authority to accept the pull request.

Core team Member

The core team members can work on the Dev code and push to QA as well as RTW branches. Though the core team has access to the QA/RTW branches, it is recommended that all code changes be made to the Dev code and ensures a clean Dev to QA and QA to RTW release. Access the QA/RTW code for release and final testing/update purposes. The core team is also responsible for reviewing and accepting/rejecting pull requests from contributors to the Dev branch.

Design:

  • Initial state
    • The project initially has the same copy on both the trunk and the QA/Dev branches.
    • The major feature additions to be added for a particular RTW are determined and fixed.
    • Based on the features the specs required are created and published on the website for public view and comment.
  • Code additions
    • As the project proceeds, the contributors make pull requests to the Dev branch and the core team reviews the changes before approving/declining the pull requests.
    • The changes are incrementally added to the Dev branch.
    • The developer is to make forks off the Dev branch and work on the newly available versions. It is the developers responsibility that their pull requests are always on the lastest version of code. If required, the core team is to resolve any conflicts and merge code.
  • Builds
    • Builds are to be done on the Dev branch on a weekly basis and made available in QA.
    • The naming convention for the build will be QA ’next RTW release version. W. Week number in current RTW cycle'. E.g. post RTW release 1.2.0 the first QA build will be QA1.2.1W1.
    • The latest build will be available for test as part of QAs. Bugs can be tracked for QA builds and changes can be made before an RTW release.
    • The feature additions to the QA branch are frozen after 4 weeks
  • Test
    • During the 6 weekly RTW release, after the changes to the QA branch are frozen, the test team is brought in to test the changes.
    • Once the changes clear QA they are committed to the Trunk. ~2 weeks
  • Release
    • This is then released and will be available on SCC and in the form of an installer.
    • The version number will be the next increment of the previous RTW release.
    • If this is a release in between the year, the version number would be 1.3.1...1.3.x. The annual releases can be named 1.4.0.... 1.x.0 and so on.

Scenario:

  • Initial setting
    • WebsitePanel 1.3.0 RTW release is available (09/29). Trunk and Dev branches have this code.
    • Major features to be released are finalized and specs created. Bugs from the previous release and features are assigned to developers in the first week.
  • Code changes (09/30 - 11/01)
    • Forks are created off the Dev branch corresponding to Issue tracker numbers (bugs/feature requests) and code is changed and committed back to the Dev branch.
    • Any developers that have code dependencies can always ensure they get the newest code on the Dev branch.
    • Pull requests are reviewed by the core team and added to the Dev branch.
  • Builds
    • The code is built on a weekly basis (10/6, 10/13, 10/20, 10/27)and the versions are numbered as QA1.3.1W1... QA1.3.1Wx.
    • Change sets in a particular build should be linked to Issue tracker numbers (bugs/feature requests).
    • The builds will be available for testing with a list of Issue tracker numbers
  • Test (10/28 – 11/09)
    • The code changes are frozen and the compiled list of all Issue Tracker numbers starting post the last RTW will be tested by the test team.
    • QA sign off is obtained.
  • Code integration and release (11/10)
    • Once QA sign off is obtained, code/documentation/website changes are moved to production, i.e. RTW.

If this is a release in between the year as in the above example the version number would be 1.3.1...1.3.x. The annual releases can be named 1.4.0.... 1.x.0 and so on.

Related searches:
release branch available feature version
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.