Designing your CMDB
If you are designing your CMDB and wondering what you need to do to include software development, an easy first phase is look at the information about which crosses the software development boundary.
All successful software development has some form of change, configuration and release management systems in place. It will include defect tracking (both for defects and changes typically) and version control tools. So we classify the software development repositories as a physical CMDB, part of the overall federated CMDB or CMS.
A change or problem can be manually linked (via copy and pasted unique ID) to an issue in your defect tracking system. There would then be some traceability from actual code changes through to associated issues, then through to a change or problem.
Obviously manual approaches to such linking are more effort to maintain and error prone, so less reliable. However, vendors are increasingly providing automated links between such systems to give more seamless operation.
Maintaining your Development and Test Environments
Another area of interaction between software development operations is that of managing development and test environments. These may or may not feature as CIs in your CMDB (so some organizations only consider production environments to be CIs).
It is important that new releases are tested in environments that most closely resemble the production environment. There are many potential issues in this area (enough for a future article on its own), so we will just highlight some:
· Who is responsible for managing which environment?
· How easy is it to audit and track changes to environments?
· How do you ensure that changes in production are included, as well as the changes that the new release requires?
· How do you manage parallel releases with incompatible requirements competing for the same environments?
· What is the minimum number of environments you need? Allowing appropriate parallelism and yet not being too expensive in terms of licenses, hardware, resources to maintain, etc.?
While in the past software development has mainly been seen as being independent from ITIL, with the release of ITIL V3, we believe all organizations benefit from reviewing what they do and taking a higher level, service oriented view.