Software Configuration Management

Software Configuration Management (SCM) &
Software Build and Release Management

Prepared by: Roberto De Palma
Version 1.0 – April 17th , 2007
Version 1.1 – April 24th , 2007

Aeroplan and IBM Confidential

Objectives

  Understand the concept of Software Configuration Management
  Highlights the problems that we have
  The advantage of process automation through the adoption of suitable tools

2

Agenda

  Definitions
  Challenges in Building and Releasing Software
  Tools
  Estimation
  Conclusion

3

Build Pattern

  Private Build: A build that is created by a developer in his or her own
workspace. This type of build is usually created for the purpose of checking
the ongoing status of the developer’s changes, such as to assess whether his
or her source code compiles.
  Integration Build: A build that is carried out by an assigned integrator or
central function. This build is created to assess the effect of integrating a set of
changes across a development team.
  Release Build: A build that is carried out by a central function, usually a
member of the build team. This build is created with the express intention of
being delivered to a customer, either internal or external.

Three explicit patterns are defined and it does not mean that each type
of build should be constructed in an entirely different manner.

4

Rational Unified Process defines a release as follows

...a stable, executable version of product, together with any artifacts necessary
to use this release, such as release notes or installation instructions.

A release can be internal or external. An internal release is used only by the
development organization, as part of a milestone, or for a demonstration to
users or customers. An external release (or delivery) is delivered to end users.

A release is not necessarily a complete product, but can just be one step along
the way, with its usefulness measured only from an engineering perspective.

5

Important aspect of the release definition

  A release is constructed and handed over for evaluation or installation by a
third party
  the quality assurance (QA) team
  the test team
  the external customer

  A release needs
  to be packaged and made ready for installation
  to be possible to identify exactly what is in the release in terms of new features,
enhancements, or defects that have been addressed

What all this means is that a release is a special type of build for which
there is a significant investment in effort and additional processes that
need to be carried out.

6

Process that generates Software Build and Release Management

Typical iterative software development life cycle (from the Rational Unified Process)

7

What aspects of SCM support a tool can offer
  Version Control
  Enables the secure and controlled storage, retrieval, and versioning of all project
assets (source code, documentation, test results, and so on).
  Build Management
  Enables the consistent and reliable construction of software applications in as short a
time as possible.
  Workspace Management
  Enables the creation of workspaces to give project members access to a project’s
shared versions of assets and consequently support for parallel development and
controlled integration.
  Change Control
  Lets you capture, track, and manage all types of project changes (requests for
change, enhancements, and defects). It also lets you compare these changes to the
versions of the project assets used to implement them.
  Process Control
  Lets you report actions, history, and milestones, as well as customize or enforce
development work flow and procedures.

8

Software Build Management process is

  To make sure that every build is complete, consistent, and reproducible

  You should always know
  what you’re building
  why you’re building it

  You should be able
  to build it again at any future point in time

9

Several distinct stages for Build Management process

  Build Identification (What to build)
  Build Identification can be either an informal process, in which you build just the
latest changes, or a formal process, in which you build only agreed-on and complete
changes.
  Build Definition (How to build it)
  Scripts (makefiles, Ant build files, etc.) that define how the different parts of the
application should be compiled and/or linked to produce a complete system or
application.
  Build Execution (Invocation and running of the build)
  Where the build scripts identified in the Build Definition phase are executed.
  Build Reporting (The results of the build)
  Build Reporting is where the results of the build (success or failure) are reported.
  Reporting include basic compilation reports, unit test reports, and release reports.
Anyone can throw together a few scripts to build some software. What is
difficult is knowing how best to do this so that the build run better,
faster, and right.

10

Software Release Management

  A release is constructed with the intention of being made available to a
customer.

  They expect
  to be able to know exactly what is being given to them
  to be complete and easily installable

  They might
  want to see some evidence that what is being given to them actually works

  This means
Software Release Management process is often more controlled
and rigorous

11

Several distinct stages for Release Management process

  Release Packaging
  Takes the output of a Release Build and bundles it to make it complete and
installable. (a JAR or EAR file )

  Release Approval (or Authorization)
  An additional checkpoint that is required before the release is deployed
  Deployed internally
  Informal checkpoint
  Deployed externally
  More formal. Potentially involving multiple stakeholders and a list of rigorous sign-off criteria

  Release Deployment
  After approval has been given, the release can be deployed

12

Software Build and Release Management is

  The process of ensuring that builds and releases
  Can be reliably constructed
  Their content controlled
  Their outputs deployed to test

  These definitions are important
  It gives us a framework to discuss the issues and challenges around the process
  It also enables us to start thinking about

What aspects of the process can be automated

13

Agenda

  Definitions
  Tools
  Estimation
  Conclusion

14

Traceability and Completeness

  Traceability
  is knowing throughout the complete software development life cycle (not just building
and releasing)
  Why you are doing and what you are doing

  Completeness is related to traceability
  it is making sure that the build or release contains all of what was intended

15

Lack of traceability and completeness
  Not being able to say exactly what is in the build
  What new features, enhancements, and defects have been addressed? Who requested
them, and why?

  Not being able to say how the build was carried out
  What versions of the code did the build use? What third-party libraries? What compiler
options?

  Not being able to say where the build has gone
  Where is the build being used? What release is being tested? What do your customers
have?

  Incomplete software builds
  Software components are found to be missing or incompatible

  Incomplete releases
  Supporting documentation or associated artifacts are missing from the release

16

Repeatability and Reliability

  Repeatability
  is about being able to do the same thing over and over

  Reliability
  is about its being correct each time

17

Lack of Repeatability and Reliability
  Not being able to reconstruct a build carried out previously
  Can you reconstruct the build environment, fix the problem, and ship a patch to the customer?

  Not being able to consistently construct and deploy a release package
  Is the content of the release package the same each time? When you deploy the release package, is
it installed in exactly the same way?

  Having continual problems with the reliability of the build execution
  When you test a build and find problems, are you sure that the problem is with the code, or could the
problem be with how the code was built?

You should be completely confident that the code being delivered into the
build is at fault, not the build process itself

18

Agility and Speed

  Agility
  is about having a build process in which changes can be integrated quickly or as and
when needed

  Speed
  is about the build process being completed in as short a time as possible

19

Lack of Agility and Speed
  Not being able to integrate changes quickly
  If problems occur during development or testing, can the developer responsible fix the
problem and immediately be able to initiate or request a new Integration or Release
Build?

  Developers waiting for the output of the build
  Does the build process take so long from beginning to end that you can afford to build
only once a week? What happens if that one build fails?

Finding your project rhythm

20

How can you do things better? How can the process be improved?

  Software Build and Release Management is essentially a part of SCM
  you can’t have one without the other

  Manuel procedures
  leave consistency to chance
  repeatability isn’t guaranteed, especially if aspects of the procedure are open to
interpretation by different people

  Automation
  ensure consistency and repeatability on the project
  enables traceability, repeatability, reliability, agility and speed

No matter how well you define a manual process, it potentially can
be error-prone and ultimately unproductive

21

Agenda

  Definitions
  Tools
  Estimation
  Conclusion

22

Rational ClearCase (Base)
  VOB (Versioned Object Base)
  is a database of versions
  files and directories

  Element
  a versioned object that resides within a VOB
  text file, binary file or a directory

23

Rational ClearCase (Base)
  View
  is an individual workspace that is created to select a set of compatible file and directory
versions from across any of the VOBs
  Typically a view is created per user and per task
  2 types of view
  snapshot and dynamic

24

Rational ClearCase (UCM)

  UCM was to simplify the adoption of ClearCase by raising the level of
abstraction and provide an out-of-the-box usage model

  Project
  Making the project a physical object of the SCM system
  Allows the automation and management of security and collaboration by defining who the
members of the project are
  Allows the definition of scope and development policies
  what set of files and directories from the VOB repositories the project is allowed to change

  Components
  VOB may contain many components
  Can be made writeable or readable within a UCM project
  Allowing you to define consumer/producer relationships between projects
  Each version of a component can be identified by a UCM Baseline

25


  Baseline
  Is like a label, but is treated as an object in its own right and collects additional
information such as the level of maturity of the baseline
  Example
  a baseline that has just been created as opposed to one that has gone through testing or into
the live environment

  Stream
  Is like a Base ClearCase branch
  But captures additional information
  UCM component baselines that it is configured for, and the UCM activities which are being
worked on in it
  UCM project has
  A single integration stream where changes are delivered to
  One or more developer streams per developer.

26


  Activites
  Changes to files are grouped according to the reason for their change
  You cannot make a change without declaring this association
  Benefits
  It ensures that no files are changed without an associated reason
  It allows sets of changes to be referred to and integrated as a whole
  Activity is capturing a Change Set
  When you want to deliver the files that you have been working you don’t have to remember
the exact set of files that you changed
  You simply deliver the activity

27


  UCM activities and baselines also work in
combination

  It is possible to automate the process of
determining what is different between
one baseline and another
  List of files that have changed from one
baseline to the next
  Also a list of activities

  Advantages
  automatically generate release notes
  Assist testers in determining the necessary
set of regression tests to run

28

Rational ClearQuest
  Software Change Request and Defect tracking tool

  4 different types of changes
  new requirement
  Capturing new requirements for a new or existing system
  enhancement request
  Capturing requests to enhance an existing system
  defect
  Capturing problems found with testing or deploying a system
  deployment
  Capturing and requesting that a new system is deployed

  Customizable
  Types of change
  Permissions
  Look and feel of individual forms

29

Rational ClearQuest
  Report
  Can be created by any user
  Report format
  Can be designed using Crystal Reports
  Text based reports
  Generate many types of graphs and charts

30

Rational ClearQuest with ClearCase
  ClearQuest manages each team
member’s activities
  They are presented with a prioritized “To
Do” list

31

Rational BuildForge

  Provides a complete build and release process management

  Build and release execution framework that allows development organizations
to standardize and automate repetitive tasks

  ClearCase Integration
  To initiate and report on the software versions that have gone into a build

  ClearQuest Integration
  Report on the ClearQuest Defects that have been addressed in a build and
automatically resolve them
  Create a ClearQuest Build Record automatically as part of a build

32

Rational’s complete Software Delivery Plateform

33

Development Infrastructure

34

Agenda

  Definitions
  Tools
  Estimation
  Conclusion

35

Person days of effort- Rational ClearCase

  No migration considered

  Tool administrator (most likely a developer) : 13 days
  Project Lead : 7 days
  Developers (9) : 1 day
  CoC Specialist : 15 days
  Architect : 7 days
  Project Manager : 15 days

  Total : 58 days

36

Activity

  CM Workshop (5 day)
  ClearCase Administrator, Project Lead, Architect, CoC Specialist

  Analyzing and conception of the structure of the vobs (3 day)
  1 Architect, 1 Developer, ClearCase Admin

  Setup
  Preparing Readiness Plan (2 days)
  CoC Specialist
  Installation and Configuration
  CoC Specialist (5 days), ClearCase Administrator (2 days)
  Configuration of the VOBs
  Security
  Role and Responsibility
  Installing the client tool on each user (1 day)
  ClearCase Administrator

37

Activity

  Training (Self + w/CoC Member)
  ClearCase Administrator (4 days)
  Team Lead (2 days)
  Developer (1 day)

  Documentation (10 days)
  ClearCase Administrator, Developer

  Testing (4-5 day)
  1 Developer and ClearCase Admin

38

Some question that we need to answer during the workshop

  How big do you think the project will be?
  How many people will be involved in the product development?
  At how many locations will the product be developed, tested, and deployed?
  Is the product internal or external?
  What are the third party tools that you will be using?
  What is the development cycle of the product?
  How do your current development methodologies fit into your tool plans?
  Are any key roles missing from your team?
  Do you have the hardware you need?
  Do you have the infrastructure ready to support your plans?

39

WW Infrastructure Service

  $40-50 per project / per VOB (2 GB) / per month
  Establish servers and tools
  Setup Admin (user ids, access level)
  Look at licensing details
  Provide 24X5 support
  Weekend Page Support is available
  if required and provided with advance notice, will have resources available
  Web interface that will allow Client access to these tools and infrastructure
(June 2007) (cost is to be confirm)

40

Risk

  Period of transition for the people
  Learning curve
  Down time
  Duplication of effort
  Decreased productivity
  Assigning Role/Responsibility to people
  ClearCase Administrator
  Integrator
  Etc.

41

Agenda

  Definitions
  Tools
  Estimation
  Conclusion

42

Conclusion

  Automation help us to be more productive
  We need to audit our process

  Benefice of Rational Tools
  There integration
  They cover all aspects of the Software Engineer discipline
  Business Modeling, Requirement, Analysis & Design, Testing and SCM

  The migration should be plan and drive as a project
  Take more time at the beginning but it reduce the risk of failure or the rejection of
change
  At least one person on each role should participate in the testing
  Plan a head and be prepare to perform the migration during the week-end

43

Roles

44

Rational Tools

45

References

  IBM Software Product library - Change and release management
  http://www-306.ibm.com/software/awdtools/resources/scm.html

  ClearCase, Ant and CruiseControl
  Book24x7

  CM Crossroads – section on Build Management tools and forum
  http://www.cmcrossroads.com

  IBM Software -Rational ClearCase- Support
  https://www-306.ibm.com/software/awdtools/clearcase/support/index.html

46

Question

47

Software Configuration Management

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to Software Configuration Management

Similar to Software Configuration Management (20)

Recently uploaded

Recently uploaded (20)

Software Configuration Management