The Relationship Between Version Control, DefectIssue Management, Build Management,

1
The Relationship Between Version Control,
Defect/Issue Management, Build Management,
Release Management
2
A Little History VC

• Version Control (VC) has a mixed origin
• Development created the tools to version source
  code and later designs and documentation
  
• Quality developed the manual process to allow
  auditing of changes to first physical and later
  software items
  
• They continue to argue over who owns VC
• Infrastructure Support (IT) assumes they own the
  severs and tool installations

3
A Little History DIET

• Defect, Issue and Enhancement (DIET) tools and
  processes have evolved
  
• Tools were first created to report to
  Development
  
• Development was required to respond to items
  reported
  
• Management learned to capitalize on data and
  trends

4
A Little More History DIET

• Increased need for management decision support
  and a need for traceability caused tools to
  evolve to support a linkage between versions of
  items changed to individual DIET records
• Management desires for process and workflow
  management have led to the continued evolution of
  DIET tools
  
• Confusion over rolls, requirements and ownership
  of DIET tools and processes continues to grow

5
A Little History BM

• Build Management (BM) was created by Development
• Still considered a Development activity
• Quality realized this does not promote
  consistency for production builds
  
• No one wants to own, but also does not want
  someone else to own

6
And a Last Bit of History RM

• Release Management (RM) evolved from Production
  Control
  
• Barely recognized as separate from BM
• Often not even performed as a formal activity
• Considered by many beyond the bounds of classical
  Quality, especially in the realm of software

7
SCM Components
8
Visibility of SCM ComponentsViewed By Engineering
VC
DIET
RM
BM
9
Visibility of SCM ComponentsViewed By End User
RM
DIET
BM
VC
10
SCM Component Relationships
11
Functional View
12
Data Flow View
13
So Why Should Ownership Reside with SCM?

• Quality cares that things work, SCM cares only
  that they are reproducible
  
• Development cares about going forward, SCM cares
  about preserving the past
  
• Classical Production Control is concerned with
  Release Management, but rarely has the software
  skills necessary

14
So Why Should Ownership Reside with SCM?

• Controlled Items need to live beyond a project,
  beyond a product, beyond project management
  regardless of success or failure
  
• Data Warehousing and Metrics are easier to
  produce if a single entity is responsible

15
So Why Should Ownership Reside with SCM?

• Each component is necessary for reproducible
  product delivery
  
• Each component is active for a smaller portion of
  the SDLC

VC
DIET
BM
RM
16
So Why Should Ownership Reside with SCM?

• Version Control
• Needs to live beyond project development
• Development often does not version often enough
  or at the proper milestone points
  
• Development often does not see the need for
  downstream data and metrics Quality and
  Management needs
  
• Quality often not able to participate early enough

17
So Why Should Ownership Reside with SCM?

• Build Management
• Development does, but how varies from project to
  project and developer to developer
  
• Quality wants controlled, consistent builds for
  test purposes, but does not generally know how to
  produce them without Development support
  
• Someone needs to worry about being able to
  rebuild past instances

18
So Why Should Ownership Reside with SCM?

• Defect, Issue and Enhancement Tracking
• Quality creates defect records and uses them to
  retest
  
• Development uses defect and enhancement records
  to know what to fix/implement
  
• Management uses all records to decide what needs
  to be done and in what order
  
• Someone needs to own and preserve all records

19
So Why Should Ownership Reside with SCM?

• Release Management
• Production Control needs a certified, controlled
  set of deliverables, but can rarely produce them
  
• Development can produce them, but not certify or
  control them
  
• Quality can control and certify them, but rarely
  produce them
  
• SCM can provide both the resources and control

20
So Who Should Own SCM?

• Development is too focused on the future to want
  to waste time on the past
  
• Quality wants what they need to be reproducible
  and tend to want to impose the same needs and
  goals on development
  
• Project Management wants the job done with
  minimum risk and maximum profit and overhead
  reduces profit

21
So Who Should Own SCM?

• SCM Process
• Integrated into Development, Test and Deployment
  processes
  
• Contains portions that are unique to SCM and not
  part of other processes
  
• Hardware, Systems Software Tools
• Co-owned by IT if they are willing
• Owned by SCM if they are not

22
So Who Should Own SCM?

• Repository
• Physical repository owned by SCM
• VC contents owned by SCM
• BM artifacts versioned and owned by SCM
• DIET contents owned by Quality
• RM contents owned by Production Control
• Audited by Quality and external authorities

23
So Who Should Own SCM?

• SCM should own itself if at all possible
• If not, Quality should own SCM
• Posesses a longer term vision
• More paranoid and requiring of traceability
• If not Quality, then Development
• At least VC and BM will be performed
• Management will force DIET on Development

24

• Questions?

25
Contact Information

• Cell Phone [phone]
• E-mail bweath_at_attglobal.net

26
Definitions

• (If there is time)

27
Definitions

• Builds
• A consistent method of transforming Configuration
  Items into deliverable Derived Items
  
• Generally automated using some form of scripting
  language or tool
  
• Build related scripts should be treated a
  Configuration Items

28
Definitions

• Build Artefacts
• Derived Items resulting from a build process
• Generally one or more logs that describe what
  happened during a build
  
• Should be treated as Configuration Records

29
Definitions

• Build Management
• Design and construction of Build Infrastructure
• Design and construction of Build scripts, etc.
• Performance of controlled builds
• Capture and control of Build Artefacts

30
Definitions

• Configuration Items
• Also called Controlled Items
• Items that are needed to either produce the
  desired end product, are used to aid in its
  production, or are included in it unchanged
  
• Examples include source code, project plans,
  requirement specifications, and database seed data

31
Definitions

• Configuration Records
• Items that describe one or more aspect of a
  controlled environment
  
• Examples include

32
Definitions

• Defect
• A fault in a Configuration Item
• May related to code, design, requirement, etc.
• Generally require a rapid response

33
Definitions

• Defect/Issue Management
• A consistent mechanism for tracking,
  communicating, and disposing of Defects, Issues,
  and Enhancement Requests

34
Definitions

• Derived Items
• Items derived from Configuration Items
• Examples include object and executable files,
  Programmers Reference Manuals, and Installation
  packages

35
Definitions

• Enhancement Request
• A requested change in behavior or appearance
• Often greater in scope than Defects
• Can generally be scheduled
• Generally treated as a minor form of Defect

36
Definitions

• Issue
• A problem not directly related to Configuration
  Items
  
• Generally require Management involvement
• Generally larger in scope, cost and risk

37
Definitions

• Release Management
• Builds convert Configuration Items into
  Deliverables Releases package those Deliverables
  for distribution
  
• May use the same tools as build, or may use
  different ones
  
• Functionally different

38
Definitions

• Version Control
• A mechanism to track changes to each
  Configuration Item (who, what, when, why, and
  what)
  
• Allows the identification of aggregate sets of
  Configuration Items by individual version
  numbers
  
• Normally allows parallel development to occur