Practical Configuration Management Seattle Delphi Users Group June 6, 2002

Introduction What is Configuration Management? Isn’t it just pretty basic stuff? Why does it always seem to be left to the very end of a project? What does it take to integrate it with the entire development process?

What is Configuration Management? Version control Systems Formal Build Procedures Packaging / Distribution Processes Build Verification Tests Defect Tracking System Build Test Defects VCS Coding BVT Req. Docs InstallPackaging

Isn’t it just pretty basic stuff? Yes. But when do you start? VCS for small teams? “InstallShield” for simple tools? Plan on all projects being wildly successful, and growing more than you expect. Put the infrastructure in place to make it manageable.

Why does it always seem to be left to the very end of a project? Development (often) focuses on Componentization, Compartmentalization, and Specialization. CM is a task heavy with “integration” issues... “It works on my ‘Dev’ box… I don’t know what else it requires to function…” Uncertainty over what will ship, and what will wait until the next release. Nobody wants to do it.

What does it take to integrate CM in a Development Process? Patience Communication Lots of tools

Some Tools for CM A good scripting tool –4NT ( –WinBatch –CScript A Search/Replace text tool –SRWCons –Perl CMLog – Configuration Management Logging System.

Now what? Overview of your basic build process Some common Configuration Management Questions/example solutions. Look at the CMLog build process to show how those questions are solved.

Your Basic Build Process Developers check code into VCS Build process gets latest source from VCS (Extraction) Compile the source Package the results Build Verification Tests Pass build on to QE

Does Order Make A Difference? Get all source compile #1 compile #2, etc. Package Prep Packaging Get source for #1 compile #1 Package Prep Get source for #2 compile #2 Package Prep Packaging

Miscellaneous ‘How To’

Do I have to “Lock” the VCS? How do I do a build with known-versioned code, without forcing all the developers to stop work during the process? VCS Labels, Stripes, Pins, branches... –Fundamental point is to make some "marker" in the code, whereby it does not matter if developers check in ABOVE the marker. –Your extraction for a formal build is never off of the real "tip" per se, but based on the code at the time of the marker.

Keeping Scripts in sync w/VCS The location of files are in flux, moving both on the file-system, and/or their location in the version control system. How do I make the scripts that depend on the VSC easier to manage? Abstract all interaction with the VCS to your own higher-level script. See P4VCS.cmd

Database Schema and a VCS How can one manage all the SQL required for a DB application, while not providing that SQL to the customer? SQLToBAS.EXE -- Reads a manifest that lists all the SQL files that need to be processed, converts it into a BAS file. (note: DTS in SQL can do this too, but it's much harder to keep all the SQL objects in a VCS)

Documenting DB Schema How does one adequately document DB Schema, stored procs, views, and other DB objects? Semi-automated… see CMLog proc docs.

Version Stamping How do I stamp version numbers into the product? That depends on what it is: –SQL files, such as Stored procs (or data that is inserted via SQL) can be searched/replaced during the build process. –DPR/PAS files can be auto-stamped, or use a similar search/replace technique.

Localizing Scripts for re-use How do we make build scripts flexible enough to work on a variety of machines, were tools are located in different places for each developer? Make use of the %ComputerName% environment variable, and let each box have a localizing variable file.