Defect management – what is it?
Basically it’s a bug, defect, issue tracking. Usually there’s plenty of different options for a tracker and also Release Management is using some bits of that. Usually tracker is used to categorize defects by product or application.
Sometimes (in my case) it may become quite complex. Once you have 10+ environments and somewhat 100 interfaces to/from your major apps, there’s no doubt it’s a challenging environment. Let’s say – challenge is not only to track everything but to actually manage this information. Luckily, it’s not Release Management activity; however, there is a point where we are touching this area.
Release Management activity is making sure all delivered packages are tested prior deployments to particular environment and after that connection of RM function to particular release is quite weak until it has to be promoted to another environment. What RM should take into account is the package has to be evaluated not only from application and/or infrastructure part but also on defect level (oh, BTW, did I mention change requests before? Those are also here, business is not always willing to have separate release for that purpose).
So, how do we do assessment on defect level? Defects may contain a lot of valuable information like
- release identifier (can be number, letter, etc. – depends on your environment)
- environment (where the defect was discovered)
- status (input pending, ready for deployment, closed, etc.)
- business input (this can be divided to priority, severity, deadlines)
- dependencies on other defects
It has to be decided what is the information you really need for Release Management activities.
So far quite easy, right? So, where’s the challenge here?
Challenges start when defect information is different from initial release package. Let’s do some list of what may happen to a defect:
- defect can be fixed (good) or even closed (perfect)
- defect can open another defect or new dependency is discovered
- defect can be re-opened
- defect can be rejected
- defect can be postponed
As you can see, there is “normal” defect life-cycle with standard open-analyze-build-test-close and not so normal life-cycle when the route of defect is not predictable.
What is pain for Release Manager?
It is very important to understand what to do with such release leftovers but firstly we need to discover them.
When receiving your first release package, make sure all information you need is there – defects, their origin, business inputs and dependencies. It will help you to perform analysis before promotion of the package to your next environment. Before each promotion, defects should be assessed on everything is important to you and your organization.
Challenge with broken fixes
One defect is re-opened – should you wait for new release package or promote package irrespective testing results? Perhaps building a new package or excluding fix from your package. Decision has to be taken based on your environment – what can you actually do? You can decide only if you have more than one option.
Challenge with showoffs
You have many releases planned and defects are linked accordingly. Future release is not that far and something is ready. Why not to include this into your current release? Here’s one of the risks – a new defect can be opened on particular functionality and testing can be performed only in future release (dependency on another app or interface). Here’s the thing – if you have few environments, easy way of excluding fixes out of the package and deployment can be performed within hours – you are absolutely safe. If you have challenging environment in terms of size, speed, decision making and other important variables, this may cause hardcore problems. You can forget your work-life balance at the very same moment!
Challenge with postponed fixes
Sometimes even postponed fixes can make your job difficult. Whenever defect fix is postponed, make sure that there is procedure for this activity. The defect should be routed through functional or technical architects to understand whether it can actually be postponed and has no dependencies. It would be a bad surprise to discover a blocking defect that is not included in any release package.
I could continue the list but I would like to concentrate on the lessons learned!
In parallel to standard defect information, I would suggest to keep in mind also parent-children relationship on defect level. Make sure parent defects of your release packages have all children included in the packages for your release.
If every application has it’s own releases, maintain “big” releases to make sure dependencies on other apps are assessed and are promoted all together to avoid failures.