Evaluate Changelogic without registration!
  

Change Planning

Why use release cycles?
A software project is developed and delivered in occasional releases. It is desirable to be able to support each release (either test or production) with critical bugfixes sooner than the next release would be ready, otherwise testing or production usage are in risk of being crippled for an unacceptably long period. For each change, a development manager or a release manager has to decide which macrochange or test release cycle the change will be integrated into. Based on this information, Changelogic chooses appropriate base version for the change. If the planning needs to be altered, the base version can be updated accordingly.

The purpose of a change is to provide a complete solution for a problem or a set of related problems, e.g. a bugfix or additional functionality. Unfortunately, changes also may introduce new bugs or inconsistencies in areas that did not seemed to be related at development time. Thus admission of changes must be more restricted and the changes more thoroughly tested as a release date approaches. Changes containing new features should be integrated into a later release cycle, only thoroughly tested bugfixes should be accepted in a nearby release cycle. In order to remind these principles, Changelogic does not allow you to plan development changes into test release cycles that are already accepted nor into production release cycles that are being stabilized or already in production.


How to?


A release manager can select which change goes into which release by selecting the desired test release cycle on the details page of the change. The planning of the change may be altered at any time until integration has begun. To change planning after integration has started, cancel the integration first.


Despite original planning, the change may be replanned into another test release cycle or into a macrochange. Note that in spite of altering planning, the base version of the change is altered only when the developer does a base version update.


Note that if a change has been planned into an older test release cycle, it will be integrated into multiple test release cycles. The older the planned test release cycle, the more labour-intensive will integration become. See branching model for more information. Therefore a release manager should strive to determine the earliest test release cycle that really needs the change.


The planning page


The planning page (in menu Change -> Planning) gives an overview of how changes have been planned and integrated into test release cycles:



The finished changes are listed in the order of integration time; unfinished ones are ordered by change ID. The versions with yellow background have reached test phase; versions with red background have reached production phase.


Automatic replanning


There are situations in which Changelogic adjusts the planning of changes automatically; even new production or test release cycles might be created, if they did not exist. Automatic replannings are triggered by releasing versions to testing or production. Such automation aids in advocating a branching model that provides a separate branch for supporting each test release cycle. The reasoning for automatic replanning goes like this: when a version has been released, it seems very likely that the other changes that were planned for the same release must have been postponed for the next release. After all, the release cycle is meant for supporting the release, and it is unlikely that a version would have been released with supporting changes already open.


When a version reaches test phase, all changes that have been planned into the test release cycle of the version are planned into next test release cycle within the same production release cycle to reserve the current test release cycle for supporting the released version.


When a version reaches production phase, all changes that have been planned into the same or newer test release cycles within the same production release cycle are replanned to the first non-abandoned test release cycle of the next production release cycle to reserve the current production release cycle for supporting the released version.


If a change has been replanned excessively, it should be manually replanned. Note that conformity between change reason and release cycle state are still validated, so it might be impossible to restore planning of development changes without altering the reason of the change first.