Main Page | Recent changes | Edit this page | Page history Printable version | Disclaimers | Privacy policy

Not logged in Log in | Help

Configuration Management

From DGC Wiki

As of winter 2007, this is a project with tracker [bug #3106] and contact Rob Grogan.

Contents 1 Project GOTChA 1.1 Goals 1.2 Technical Challenges: 1.3 Objectives: 1.4 Approach: 2 Software 2.1 Proposed Build Process 2.2 notes on this build process 3 Hardware 4 Tools

Project GOTChA

[edit] Goals Keep track of hardware and software changes in Alice Make documenting hardware and software changes in Alice possible Design configuration management system flexible enough to handle Alice's continuing electronic and mechanical evolution	[edit] Technical Challenges: Need to obtain parts from places Need to find time on ALICE to revamp system Need to have hardware configuration management in place
[edit] Objectives: Take inventory of all computers, sensors and other devices in Alice Publish inventory for review by other race teams Make editable Wiki page to visually represent Alice's current configuration	[edit] Approach: Subdivide actuators, electrical supply components, computers, sensors, E-Stop and other items into component classes Test usability of Alice Config Wiki page by soliciting feedback from its users

This page contains notes on ways to manage and maintain the software and hardware configurations of Team Caltech's race vehicle.

• it would also be a good idea to apply configuration management to ALL test platforms
• we need a way to ensure that there is always someone around who knows whatever subsytems are being worked on, an someone who knows more generally about the entire system, to facilitate fixing problems as they happen - currently a big problem do to few returning team members and poor documentation
  • could define different depths or resolutions of knowledge and assign 2 or more people to each level.
  • could try to get a couple of people who just learn everything - probably a full time job...

Software

• software needs to compile, link, and test successfully before being added to the baseline configuration
• be sure to note subversion checkout number used for each test
• note which modules are running in each test, with special note of which are being tested?
• would be useful to have simulation not only feed raw data, but capable to faking outputs from modules in developement?
• give simulation environments abiltiy to introduce faults or noisy data.

Proposed Build Process

• Need for code work arises
  • bug fix
  • functionality fix
  • New module/submodule/component etc.
• in the case of new code, a spec team or person determines the requirements and relevant test cases
• a "issue" is put up on Bugzilla to track the code package
  • this "issue" should list the reason for the code, its specs and tests, dependencies, priority and general status
  • the "issue" starts in a "dev waiting" or "dev needed" state.
• a developer picks up the "issue" and creates a branch solely for working on that code, using a naming convention that links the branch to the bugzilla "issue"
  • the developer changes the "issue" state to "dev" or "under dev" and begins work on the code.
• when the code is finished, the developer should build and test the code on their own.
  • When it passes, they change the "issue" state to "dev finished"
• the build/test master monitors the status of all "issues". When one changes to "dev finished" he/she will build and test the code in the branch to ensure its fitness
  • it is the build master's responsibilty to determine the order in which completed code is built and tested, if multiple packages are ready. He/she must be aware of dependencies and relative priorities, and sequence things accordingly.
  • if the code fails the build/test, the "issue" state is changed back to "dev" and the developer is notified and must fix whatever the problem was and resubmit the code, by changing the "issue" state back to "dev finished"
  • if the code passes the build/test, then it advances to the integration stage and the "issue" state changes to "built".
• the branch is merged ( by the build master) back into the "trunk".
  • If conflicts come up at this stage, the build master must sort them out, or delegate it to the developers involved.
  • If merging is succesful, the code package is considered finished and the "issue" state is changed to "integrated"
• the integrated code is now part of the trunk, which can be considered as a baseline, against which future code can safely be developed

notes on this build process

• this process requires a dedicated build master person who tracks all code progress and manages the build process. The build master must think more in terms of the system as a whole and using the build process to ensure a succesion of stable baselines. This person should not be actively writing code to avoid a conflict of interest.
• Merging conflicts can be minimized and efficiency maximized if code packages are kept small, so that the developement time is short, impact is smaller, and divergence is minimized
• this might be organized as a nightly build, with one round of building/testing/merging happening per night, all at oncce, resulting in a new baseline every morning, or it could happen continuosly, resulting in a new baseline anytime some code passes the build/test stage.
• this way the developers can focus on developing, can work quickly, and there is still someone keeping the projects moving and on track
• bugzilla provides a good medium for communicating between developer and build master, and can help in providing better documentation for code on Alice, and tracking of requirements.
  • bugzilla will need to have the issue states added to it, possibly replacing the current "priority" field
• this can all be done with our current tools, but we will explore using the YAM tool from JPL's delta labs to add capability and facilitate the branching/merging process.
• in addition to establishing this process/protocol, we will need to subject it to a "shakedown" period before the beginning of the term to hash out any issues and develope a training program to introduce new coders to the process
  • this training needs to be as painless and non-technical as possible
• the "issue" tracking process can be used to track hardware changes as well as software changes, though perhaps with differently named states: "design waiting", "design/build","test/certify","installation","installed"
• an additional state could be added, "obsolete", to indicate that the code or hardware has been removed from use
• it may be necesary or useful to have these tracking "issues" in a seperate instance of bugzilla, to avoid confusion with standard bug reports.

Hardware

Please use the new list alice@gc.caltech.edu to notify configuration management gurus of changes. This is a temporary solution; eventually, all messages will be wiki-viewable. Nfette 13:48, 7 February 2007 (PST)

• keep a main page up to date with the current stable/main/baseline hardware configuration of Alice, Alice should always return to this configuration after tests that use special configurations
• create a specific hardware configuration sheet for each test calling out specific changes in hardware configuration for that test/series of tests
• always determine resource requiremtents for new hardware before it is mounted (power, cooling, compressed air, space, etc.) Ensure that there is sufficient supply of these resources on Alice before the hardware is mounted (avoid try-it-and-see as much as possible)
• Test new hardware for functionality, robustness in the shop before mounting as much as possible
• develope procedures for testing robustness of hardware in shop

Tools

Here are a list of some tools to look at, recommended by Kenny Meyer and Mark Indictor

• Unit testing: c++ unit
• Jira, confluence
• Cruise contorl, continuum (continuous integration)
• Eclipse
• testmanager
• lint++

Edit this page | Discuss this page | Page history | What links here | Related changes Main Page | About DGC Wiki | Recent changes |   This page has been accessed 182 times. This page was last modified 21:48, 7 February 2007 by Nicholas Fette. Based on work by Robert Grogan and Richard Murray and DGC Wiki user(s) Kenneth.