Practical Configuration Management

1. Practical Configuration Management Seattle Delphi Users Group June 6, 2002

2. 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?

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

4. 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.

5. 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.

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

7. Some Tools for CM • A good scripting tool • 4NT (http://www.jpsoft.com) • WinBatch • CScript • A Search/Replace text tool • SRWCons • Perl • CMLog – Configuration Management Logging System.

8. 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.

9. 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

10. 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 Does Order Make A Difference?

11. Miscellaneous ‘How To’

12. 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.

13. 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

14. 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)

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

16. 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.

17. 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.