Software Configuration Management and Integration

1
Software Configuration Managementand Integration

• Alberto Di Meglio
• EGEE Integration Manager

EGEE is proposed as a project funded by
the European Union under contract IST-2003-508833
2
Summary

• SCM and Integration Activities
• First step Developing the Master Plan
• Second step Implementing the Plan
• Third step Running the Backstage
• SCM Discussion Topics

3
SCM and Integration Activities

• EGEE has a dedicated team for SCM and Integration
  activities
• The vision of the team is that integration must
  start even before a single line of code is
  written and must provide an integrated
  development and collaboration environment
• The mission is to is to provide a solid, reliable
  infrastructure to manage changes and release
  quality software based on standard SCM procedures
  and tools
• Preparation activities are starting now and we
  want all parties to be involved in the process of
  defining the infrastructure and learn from past
  experiences
• SCM is not about setting rules, its about
  collaboration

4
First step Developing the Master Plan

• A master SCM Plan is being formalized now
• It contains basic principles and rules about the
  various areas of SCM and Integration (version
  control, release management, build systems, bug
  tracking, etc)
• We want to involve all the parties in the process
  from developers to end users to make sure
  everybody buys in
• When input is collected and plan is formalized it
  will be circulated to get the final agreement

5
Second step Implementing the Plan

• After the SCM Plan is formalized and published
  (at least an initial agreed version), we will
  start the implementation phase
• All tools, machines and communication channels
  will be put in place
• Developers and Users Guides will be produced
  with clear instructions about how to use and
  interact with the project and manage changes in
  the correct way

6
Third step Running the Backstage

• For the duration of the project, the integration
  team will
• Enforce and support all procedures by means of
  automation tools
• Run the automated and manual operations of the
  build and release management processes
• Deliver integrated installation packages for all
  supported platforms for further testing and
  deployment
• Collect further input from all parties and
  introduce changes in the procedures and tools as
  necessary

7
Version and Configuration Control

• Based on CVS (using central IT CVS service?)
• Fixed directory structure for each module
• Rules for tagging and branching (e.g. bug fix
  branches)
• Common naming conventions for baseline and
  release tags
• Configuration files to automate creation of
  workspaces
• Used to enforce build reproducibility
• Used to create reference private workspaces for
  developers to develop against
• Authorization based on commitavail and tagavail
  according to SCM roles (developers, release
  managers, integrators, etc.)
• Supported protocols K4, SSH (pserver only for
  anonymous read-only)

8
Automated Build System

• Several tools under evaluation
• Most interesting combination so far
• CruiseControl Maven
• CruiseControl runs centrally on standard Ant
  files, developers do not need to add/maintain
  other special files, works for Java, C/C,
  Python, etc (using built-in or custom tasks)
• Ant file structure should be discussed to have a
  set of common items (style checks, coverage
  tests, unit tests, etc)
• Build artefacts from each module should be copied
  to a common local repository for resolving
  dependencies
• Maven implemented centrally to produce all
  project documentation and enforce additional
  checks and collect project metrics (need
  collaboration from developers to produce the
  Maven project files)
• Builds are run centrally every night (HEAD),
  every week (project specs) and when needed
  (staging build server)
• Developers can run private builds by using the
  integration Ant scripts

9
Defect Tracking System

• Bugzilla-like tool provided as part of the
  Savannah project portal
• Provided and supported by SPI team at CERN
• Need to add tools for collecting QA metrics
  (current reporting in Savannah/Bugzilla is not
  sufficient)

10
Quality Assurance

• Software Metrics are collected as part of the
  build process
• Software Defect and QA Metrics are collected from
  the defect tracking system (manually? Can SPI
  provide additional tools?)
• Project Metrics? Should we provide them in
  Integration? (project completion rate, labour
  rate, etc). It can be done, but needs input from
  Project Management

11
Change Control Board

• Changes must go through a formal approval process
• The CCB is tasked to collect and examine the
  change requests
• Changes must be tracked (in Bugzilla?) and
  communicated as efficiently as possible
• The role of the CCB (and SCM in general) is not
  to prevent change, but to organize it so it has
  only positive impacts on the project
• Should meet periodically
• Need to define composition of the board

12
Collaboration Tools

• Project Portal Savannah from CERN SPI
• Single entry point for the project, news, tools,
  documentation
• Links to other relevant sites (CVS web browsing,
  builds status, package repository, project
  metrics and other artefacts)
• Mailing lists?
• News, RSS feeds, etc.?

13
Additional Topics to be discussed

• Supported platforms
• Supported compilers, libraries, etc
• Package, deployment and installation requirements
  for integration
• Roles and responsibilities