MSC Version control strategy
The following model supports distributed development and structured build releasing among developers, testers, and users.
|Environment & [Design Relationship]||Usage||Used by|
|A. Design (.NSF)||
- In-progress design
- Development test data
|B. Testing (.NTF)||
- Most recent untested build
- Frozen during testing
- Test data
Testers (only when frozen)
|C. Build Template (.NTF)|
[is a template]
- Most recent successful build
- No data
- Replicates to all production servers if more than 1 production instance exists
|Build Manager (design storage only)|
|D. Production (.NSF)|
[inherits from C]
- Most recent released build
- Production data
- Replicates to all production servers
|E. Development Management||
- Issues tracked by status, date, version, developer, etc.
- Build file attachments (from C) by date
- Referring to old builds to confirm fixed bugs
|Developers (develop & fix issues)|
Testers (test features)
Build Managers (archive approved versions)
Users (log issues directly or via mail-in)
Development Manager (assign issues)
(A) Design (is not a template)
(B) Testing -- replace --> (C) Build Template -- refresh ---> (D) Production
One set of databases (A) through (D) exists for each final database in the application, plus one single instance of (E).
The build process would include these steps:
1. Developers work in (A), guided by design & bugs logged in (E)
2. Developers manually implement new modules in (B) whenever a new feature is ready for testing, and notify Tester when (B) is frozen
3. Testers begin testing in (B). Developers can continue working in (A) for next build.
4a. If issues exist, Testers report issues into Bug Tracking module of (E), [return to 1]
4b. If build is determined to be satisfactory, Testers notify Build Manager [continue to 5]
5. Build Manager or Tester updates About doc (or other document) with build info, major fix list, date
6. Build Manager replaces design of (C) with that of (B), and afterward attaches a copy of (C) in Version Tracking section of (E).
7. Production (D) automatically inherits from (C), or can be immediately updated via design refresh.
8. Users report Bugs/Enhancements to Bug Tracking module of (E). If any serious bugs warrant a roll-back, (C) can be replaced with previous acceptable version from file copy saved in (E) during Step 6. Note that data in production may not be compatible with previous versions. Documentation should address.
Note that (C) is not necessary if there is only one instance of the application in production. When multiple instances of the application exist, (C) allows design to propagate to production with a single refresh. If (C) is not used, Steps 6, 7, and 8 can refer to (D) instead of (C). However, the attachment procedure in Step 6 should not be a production data copy. Instead, consider using a design-only file copy of (B).