Sidebar

Combodo

iTop Extensions

Software and Release management

m( m( m( Combodo's customers only 8-) 8-) 8-)

name:
Software and Release management
description:
Develop your software (bug, enhancement) with sprints and manage your releases
version:
1.0.0
release:
2024-03-12
itop-version-min:
3.0
state:
Stable

Features

Software development

  • Manage the Software products and versions which you are developing.
  • Managing Development projects through Sprints and User stories (Features and Bugs).
  • Handling Backlog review, Sprint Review and user story life cycle based on Agile developments
  • Supporting your software, by tracking your customer requests down to each User story, so their prioritization and scheduling can maximize your customers satisfaction.

Release management

  • Use Release Ticket when you want
    • to publish as a software editor a new version
    • to move to production a new product version on your environment or one of your customers
    • to deploy a process or an infrastructure on a customer environment
  • Use Template tasks for each category of release that your company run through. Those tasks will be automatically cloned on each Release Ticket of this category. Thus ensuring that no tasks are forgotten, owner are defined and tasks progress are tracked.

Revision History

Version Release Date Comments
1.0.0 2024-01-12 First public version

Limitations

Not compatible with iTop versions below 3.0.0

Requirements

Installation

Use the Standard installation process for this extension.

  • If you have modified the UserRequest, Incident or Problem presentation, you might need to add the field releasetickets_list to the presentation/details either with an extension in XML or with the ITSM Designer

What is installed?

This extension brings a few data which are loaded during the first installation. The data will be in French or German if it is the default language of your iTop, otherwise in English.

  • User story categories, a Typology sub-class, with entries like: Bug, Enhancement, Regression,…
  • User story domains, which define tagset values, to tag your user stories by domains.
  • Release categories, a dedicated class, to prepare template tasks for the Release Ticket. A few examples are loaded, one with a some template tasks
Those data are loaded in English unless your iTop default language is French or German. Those are data and not DataModel with dictionary entries, so they exists only in a single language. Don't hesitate to rename, modify or delete them as you wish.

It also brinks new profiles named Release Agent, Product Owner and Release Manager to be used in addition of the standard iTop profiles

Configuration

The extension has just one configuration parameter, handling the default duration of a Sprint

Configuration
    'combodo-release-mgmt' => array(
        'default_sprint_duration' => 14, //days
    ),

The extension is adding, at installation time, entries to the list of rules defined for the User actions configurator extension and for the Hyperlink Configurator extension if you have installed them. Those entries are available to users based on profiles brought by this extension.

Check your configuration for the new entries and adapt them if required. Q&A section contains default rules

Add Profiles to Users

New profiles are brought by the extension. You need to give them to your users according to the role they must play in the Release management process

  • Release Agent can:
    • Create User stories and handle their lifecycle for the transitions under a developer responsibility (all but “Close”, “Re-open” and both “Rework…”)
    • Create Sprints and manage them throughout their life cycle
    • Handle Release Tasks throughout their lifecycle
  • Product Owner can:
    • Create Product and Version
    • Create User stories and handle their lifecycle for the transitions under a product owner responsibility (all transitions but “Start work” and “Request acceptance test”)
    • Create release project and Sprints and manage them throughout their life cycle
    • Handle Release Tasks throughout their lifecycle
  • Release Manager can:
    • Create Release Categories and Template Tasks
    • Create Release Tickets and manage them throughout their life cycle
    • Create Release Tasks and manage them throughout their lifecycle

Usage

This extension can be used for two different processes: developing software products and releasing them. You can use them together or independently.

  • In all cases, you will have to define Release Products and Product Versions.
  • For Software development process, you can organize your development through Development Projects that are broken down into Sprints then into User stories which will be coded.
  • For Release management, you identify the different sort of releases you do, and for each Release Category identify the Release Tasks that must be performed, who need to do them and so on… Then for each requested release, create a Release Ticket and handle it throughout the different steps of its life cycle.

The entry point for handling those 2 processes and their associated objects is a new group Menu: Development and Release

Release Management Menu

Define Products

Unless you just want to release infrastructure or processes, you will have to identify and create the Software products and versions that you develop and/or deploy. For this, use the menu dashboard “Products and projects”. At this stage, you don't need to create projects yet.

Release Management Menu

Product

A Product allow you to specify the different teams which contribute to this product:

  • PO team and Product Owner: the Product Owner(s), who are defining the acceptance criteria of each User stories and testing them based on those criteria. The proposed Product owners are the members of the PO team.
  • R&D team: contains the release agents, those who will code the user stories
  • Support team: contains the persons supporting the customers using that product

Product

Product Version

Define the product versions of your products

  • This object is simple, it has no lifecycle and no automation
  • You can track manually the version status: Planned → Under development → Delivered → Obsolete
  • You may define the previous version, when the development starts, when the build was made and even the build file.
  • You can specify product that are bundle of other products, with the Sub-products tab.

Product version

Tip1: Get aligned in your organization on the status meaning, especially “Obsolete”, is it:

  • “no customer running this version can call you”,
  • “no fix will be provided, but you will assist them”
  • “No new deployment must be planned with those obsolete versions”
  • or any other mix…

Tip2: You may create manually some of your product versions and automate the creation of others directly from your building tool. This is the strategy used by Combodo, iTop futures versions are manually created while extensions versions are automatically synchronized once built by their factory.

Tip3: Combodo uses the Sub-products to specify which extension versions are included in an iTop product, such as the iTop Professional 3.1.1.

Software development

If you maintain / develop software products, this extension allows you to organize your development in Project, Sprint and User stories.

Project

Release project allows to group together a set of shorter development cycles called Sprints.

  • It can cover a single product version or several, but there is no formal relationship as the product version(s) may not yet exist.
  • Give it a name that makes sense and cover this aspect.
  • It is a simple object without any lifecycle nor automation.

On Kanban tab, you have a overview of related user stories and sprints by status and you can act on them.

Sprint

A Sprint is a defined period of time during which a set of User stories are expected to be coded.

  • During Sprint preparation, User stories from the Backlog are added to be done within that Sprint. Ensure that your development capacity named “Sprint velocity” exceed the “Required velocity” which is the estimated capacity to code all the user stories of this Sprint.
  • While the Sprint is Running, developers code the different User stories.
  • At the end of the period, during the Sprint review, User stories which have not been completed and tested successfully are either moved to the next Sprint or returned to the Backlog
  • Then the sprint is closed.

Field Purpose
Name Used for identifying a Sprint, combined with the project name and the iteration
Status A sprint goes through different status in sequence: new, running, reviewed, closed
Scrum master The scrum master is the person who manage this sprint, it can be a PO or a developer
Context
Release project A sprint can be outside of any project, but it may help to segment them by project
Previous sprint Previous sprint (is filled automatically if you created sprint through an action on the previous sprint)
When set, iteration and dates are recomputed automatically
Iteration This number is automatically computed based on its position in the chain of sprints.
It's empty if the sprint has neither a previous nor a next sprint defined
Start date If there is a previous sprint defined, it's automatically set to the end date of the previous sprint, otherwise it can be set freely.
It's not representing the date when the sprint was moved to running state
End date Date when the sprint should end, computed automatically if not set using the sprint default duration of the configuration.
Can be changed manually, in which case if there is a next sprint, its dates will be recomputed automatically, keeping its original duration.
This dates modification are cascaded till the last sprint of the chain
Next sprint Define next sprint (usually set automatically by action performed at sprint closure
Velocity
Sprint velocity Manual entry, specify the development team capacity in points during the sprint period
Maybe not all developers are available
Required velocity Computed automatically, as the sum of user stories points.
It's the needed development capacity in order to treat all user stories attached to this sprint.
As soon as the points of an attached user story is modified, this field is updated
Consumed velocity As soon as an attached user story is closed, real points spent on it are added to this read-only counter
Review
Work progress Optional manual information about the work progress, are we on track or not
Sprint review At sprint's closure, write down the learning of the sprint review

An action is proposed on the sprint to create the next one, within the same project, organization, using the same velocity and scrum master, starting from the end of this one, with the default sprint duration and proposing you to change any field before creation.

During the sprint review, if there remain some user stories still open, then a message will warn you that those user stories should be moved into the next sprint (they can also manually be sent back to the backlog). If the next sprint is not created yet, that would be done automatically during the closing. The closing transition will tell you in its label, if a next sprint will be created or not and if user stories will be moved or not. If user stories are moved, this information is added to the sprint log.

lifecycle

Sprint lifecycle

User Story

A User story is the object to track every idea, issue and feedback about a product.

It's the most important object for the software development process with a rich lifecycle:

  • Sandbox: After creation, user stories are in the sandbox, they are not yet qualified.
  • Backlog: During the qualification, the owner specifies what is expected and how he will test that the results meet the expectations,
  • To-Do: During the backlog review, the team identifies stories to do, for each estimates the development effort required and put them in a Sprint for development.
  • In-progress: A developer will implement the user story in the code, specify the product versions in which it is included and move it to the test team
  • Acceptance tests and Assigned to tester: A tester will then take it and act based on the result of that test
    • re-open because specifications need to be reworked → Backlog
    • re-open because acceptance criteria aren't met → To-do
    • close → Closed
User story lifecyle Qualificationbacklog
Product owner fills the “definition of done” to describes what he is expecting to be available before the user story can be moved to “Acceptance tests”.

Planningtodo
During meeting with dev team, the user story is analyzed, quoted and attached to a sprint.

Developmentwip
In addition of all prompted fields, Developer must fill “Fixed in versions” tab, before asking for tests to indicate tester what to test.

Testsacceptance_test & assigned
After applying tests, feature will be closed or re-opened due to code incorrect or specifications to rework.
Field Purpose
Requestor Person who report this user story
Status Possible values: Sandbox → Backlog → To-do → In-progress → Acceptance test → Assigned to tester → Closed
Product Product concerned by the User story. This help to prefill team fields (dev, po, tester)
Seen in version Hidden - Version in which the user story was seen
Reference URL to another system, such as a SourceForge discussion, a GitHub pull-request,…
Creation date Read-only computed: creation date of the user story
Last Update Read-only computed: last time the User story was modified
Description Describe the case from the user perspective
Qualify
Owner Person who will test and ensure that the user story is completed
Added value Possible values: minor(1), medium(2), high(3), critical(4)
Category Does your user story relates to a bug, an enhancement,… It's a typology so can be
Parent User story Needed only when a story is part of a larger one
Plan
Project This field restrict the possible sprints to those without project or belonging to the selected project
Sprint User story will be treated within this Sprint
Definition of done What needs to be done to consider that the user story is closed (application behavior, test, documentation,…)
Priority Priority of the User story in the Sprint. Developer are expected to code the highest priority first
Points Estimation of the development workload in points, to complete this user story
Development
Developer Developer who will manage this user story
Commits If possible direct urls to the commits in tools such as GitHub, helps to understand and retrieve what has been done
Real Points Points really consumed to achieve this user story
Dev start date Hidden computed: time when the user story was moved to “In progress”
Dev end date Hidden computed: time when the user story left the “In progress” state
Affected versions Versions containing this user story
What has be done What has be done by developer to complete the User story
Test and close
Product/Test Team Team who will manage tests
Test start date Hidden computed: time when the user story was moved to “Assigned to tester”
Counter for change of specifications Read-only computed: how many times the user story went through transition “Rework specification”
Counter for coding issue Read-only computed: how many times the user story went through transition “Rework code”
Close date Read-only computed: time when the user story was moved to “Closed” state
Closing code Possible values: Fixed, Duplicate, Not a bug, Not reproduced, Won't fix
Tab Description
Related tickets Root User Request, Incident or Problem which end up in creating this User story or are waiting for its resolution
Product versions Product Versions in which this User story must be fixed / implemented
Sub-stories Used for large User story which are split in little pieces, as sub user stories

Tip: For eg. you could define new Categories Epic, Feature and create Epic user stories as parent of Feature user stories, themselves parent of Enhancement user stories.

User stories in Sprint

Velocity

On each sprint, we measure different velocities:

  • Required velocity which automatically computed as the sum of points of all user stories of the sprint. If you update the points of a user story or you move a user story from one sprint to another, the required velocity will be automatically recalculated. This allows to know the resources needed on the sprint to developed all the planned user stories. If you don't have enough resources, either get some, remove some stories from the sprint or extend the sprint duration, but this last option is against agile logic.
  • Sprint velocity is your capacity of development during the full sprint period, knowing the ressource available for that sprint. If you don't fill this field, the velocity of the product's development team will be used.
  • Consumed velocity is automatically filled when a user story is closed and only then.

Sprint review

When the sprint reach its end date, it is expected to be closed regardless of its user stories status. All user stories which aren't closed yet must be transferred to another Sprint or send back to the Backlog.

You can move non closed user stories from one sprint to another, using one of the following options:

  • When you close the sprint, specify the next sprint, and iTop will automatically move user stories not already closed from the current sprint into the next sprint.
  • Or from the details screen of a Sprint, you can click on the menu Close this sprint, create new one, and move non closed user stories which does what's is name says, it create a new sprint, defines it as the next sprint of the current one, moves the non closed user stories from the current sprint to the new one and close the current sprint.

User stories overview

Get clients feedback

If you support and develop your product versions, then you will manage User request and User stories to track customers feedback,

  • Clients will come back to you sometimes reporting application bugs or suggestion for enhancement. We will assume that they do this using iTop User Request, because that's the most efficient.
  • Your Support Agent, from that User Request will create a User story object, in one action menu, copying the title and description.
  • He will complete the User story with information such as the impacted Product and save it in the Sandbox, for Product Owner to handle it further.

Release Management

The release management process can be used for different purpose:

  • Deploying a new infrastructure, a new process or a new software version or even a combination of all those aspects.
  • As an organization, you may handle different type of deployment, for your own benefit or the one of a customer.
  • Each type of deployment requires a different set of tasks to be performed.

To address the above described situations and needs, the extension brings different objects:

  • Release category: a typology to categorize the different type of deployment release that your organization manage
  • Template task: represent tasks which must be performed for a given Release category.
  • Release Ticket: a type of Ticket to manage a particular release, with a start date, an end date, different tasks and different states to go through
  • Release task: the tasks of a Release ticket, automatically created based on the release category template tasks.

Category

Start by defining the categories of deployment release that your company performs. The extension comes with a few categories, but feel free to rename them to match your business.

Template task

On each Release category, define the tasks to perform to achieve this type of release. The fields specified in the template tasks, will automatically feed the tasks which are created on true release ticket of this category. Information which can be prepared are:

  • Name
  • Description
  • Parent task: which can be used to specify sub-tasks or to handle dependency: parent task needing to be completed before starting this one
  • Team: who is in charge of doing the task
  • Owner: member of the team in charge of doing the task
  • Lead time (in days): this represent how many days before the release deployment date, this task must be started
  • Duration: how many days the task will take to be completed

Release Ticket

To handle a release, you will create a Release ticket.

  • As most iTop tickets, you have an organization, a requestor, a status, a title, a description and a few release specific fields
  • It can be used to publish product versions which have been build during a release project. Specifying a project, allows to automatically retrieve all the product versions impacted by the project, as well as all the tickets from customers (User requests, Incidents, Problems,…) which have lead to creation of User story, stories which were closed within this project.

Release Ticket

Field Purpose
Organization Organization requesting the release
Requestor Person of the above organization, who made the request
Status Possible values: Built , Waiting for deployment approval , Closed , Deployed , Early life support , new , Planned , Moved to production , User acceptance test done
Release project Useful when a release ticket correspond to a development project
Release team Team usually responsible of managing releases
Release manager Person responsible for driving the release through process
Approval Team Team approving release's move to production
Support team Team supporting new release
Move to production Possible values: Not done , MTP done , Training done , Training to be planned. Did you do MTOP fully or partially
Start date Start date of release request- automatically set
Last update Last update of release ticket- automatically set
Resolution date Resolution date of release request- automatically set
Close date Close date of release request- automatically set
Deployment date Planned deployment date for the release. It drives the dates of all associated tasks in reverse planing
Approbation release date Approbation date of release request- automatically set
Release plan Plan that will be followed during release.
Test plan Describe what must be done to test and approve release.
Test result Describe results of tests.
End early life support summary Conclusion by support team after early life support
Rollback plan Rollback plan to apply in case of failure which cannot be fixed
UAT rejection reason Reason of rejection by test team
Approval rejection reason Reason of the rejection by the approval team
Deployment reject reason Reason why deployment failed
Support reject reason Reason of rejection by Support team
RFC Summary Request For Change (RFC) summary for approval

Lifecycle

Lifecycle will handle (among others)

  1. ensure that a test plan and a rollback plan are defined
  2. based on the type of release, ensure that the components to release (Software versions or CIs) are identified
  3. get an approval before releasing
  4. propose an earlier life support to monitor the release with more reactivity
  5. then move to production which close the release ticket

Release Ticket Lifecycle

Release task

You can define on each Release ticket, tasks which must be performed to achieve this particular release.

  • Name
  • Description
  • Parent task: which can be used to specify sub-tasks or to handle dependency: parent task needing to be completed before starting this one
  • Team: who is in charge of doing the task
  • Owner: member of the team in charge of doing the task
  • Reverse planing: this flag, let you decide if the task must keep fixed dates, or floating dates linked to the ticket deployment date
    • Yes: Start date and End date are automatically computed, don't change them, it's useless in that case, but set Lead time and Duration
    • No: Specify Start date and Duration but don't change Lead time and as it won't have any effect
  • Lead time (in days): this represent how many days before the release deployment date, this task must be started
  • Duration: how many days the task will take to be completed

Rather than creating each time all your tasks from scratch, if your process is mature and your tasks well identified, then document then as Template tasks of a Release Category and select this particular category when creating your Release Ticket. Then as soon as you plan your ticket, all the template tasks defined on the associated category, will be copied as Release Tasks on the Ticket. Their start and end dates will be automatically computed based on the Deployment date of the Ticket.

Release Tasks on a Ticket

Release dashboard

Accessible from the menu Release Tickets get an overview of your Releases, and as any dashboard customize it to your need.

Release dashboard

Release calendar

Accessible from the menu Release Calendar get an overview of your Projects, Sprints, User stories and Releases

Release calendar

Questions & Answers

Q: In my company, the team which performs the tests is not the same as the team who specifies the User stories, how can I do?
A: On the ReleaseProduct class, add a new 1:n relation to the class Team, called test_team_id, add it to the Product presentation details.
Then modify the filter of the UserStory tester_id field, so it proposes members of that new team instead of po_team_id members:

SELECT Person AS p 
  JOIN lnkPersonToTeam AS l ON l.person_id=p.id 
  JOIN Team AS t  ON l.team_id=t.id 
  JOIN ReleaseProduct AS pd ON pd.test_team_id=t.id 
  WHERE pd.id =:this->product_id

Q: I want to be able to manage the Product version composition from the Bundle side, how can I do?
A: On the ProductVersion class, modify the presentation details: add the field parentversions_list

This is the second side of this reflexive relationship:

  • productversions_list are the sub-versions
  • parentversions_list are the aggregated-version.

Q: When a new sprint is created automatically at previous sprint closure, the new sprint has the same name, it's confusing, how can I do?
A: In the Designer, change the Sprint naming to add the number within the name, so they automatically become different and unique after a clone, as the number (iteration) is automatically incremented in a sprints chain.

Q: I have imported massively sprints and user stories from another tool, but my sprints required and consumed velocity are wrong, what can I do?
A: Ask an iTop administrator either to change the access write to an existing hyperlink configuration rule or to perform the action on the sprint

Q: Can I change the proposed action menus on Sprint, User story and Release Ticket?
A: Yes, by editing the configuration file. Those actions are defined in the hyperlinks-configurator and object-copier modules.

FIXME: Add default rules

extensions/combodo-release-mgmt.txt · Last modified: 2024/09/06 17:16 (external edit)
Back to top
Contact us