Software and Release management
Combodo's customers only
- 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
-
iTop Professional 3.0+ or Essential 3.0+ with extension: Hyperlinks configurator and extension: Kanban Board
-
Recommended: iTop Professional 3.1.1+ with extension: Kanban Board
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
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
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.
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 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.
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
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
-
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.
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)
-
ensure that a test plan and a rollback plan are defined
-
based on the type of release, ensure that the components to release (Software versions or CIs) are identified
-
get an approval before releasing
-
propose an earlier life support to monitor the release with more reactivity
-
then move to production which close the release ticket
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 dashboard
Accessible from the menu Release Tickets get an overview of your Releases, and as any dashboard customize it to your need.
Release calendar
Accessible from the menu Release Calendar get an overview of your Projects, Sprints, User stories and Releases
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.
: Add default rules