VCS Extreme

1. VCS Extreme AmerOmnis ‘03 David Barnett, Encoda Systems, Inc.

2. VCS ExtremeA Case Study An ‘Extreme’ case of the use of the Omnis VCS to manage multiple developers developing and maintaining multiple releases of a product in a complex development/support environment. Not a ‘How To’ session on the VCS. VCS Extreme: AmerOmnis ‘03

3. The task: Managing Multiples Who ‘ya goin’ to call? • Multiple Omnis Developers • 20 active developers • 6 others in Dev. Mgmt., DBA roles. • 2 Development teams • 3 office + remotes VCS Extreme: AmerOmnis ‘03

4. Development CycleMajor Steps • Pure development • QA testing & fixes (alpha, internal) • Beta Testing & fixes (beta, external) • Release!! (in production) Rah! • Bug reports/fixes • New Features: requests, roadmap items VCS Extreme: AmerOmnis ‘03

5. Releases to manageThe Release is just the beginning • v1 - Production • v2 - Beta • v3 - QA • v4 - Development • v5 - Development Specs • v6 - functional specs • v7 - planning feature set VCS Extreme: AmerOmnis ‘03

6. Issues & NeedsHow to deal • Field releases never perfect . (admit it) • Bugs to fix. But formats have new work. • Prevent mixing of new work & bug fixes. • Bug fixes to the field. • Same bug fix in newer versions. • Replicate customer environment VCS Extreme: AmerOmnis ‘03

7. Elements of an ApplicationWhat to keep in sync • Omnis: Exe, DAMS, externals. • Libraries: 1 or more which work together • Database structure: schemas, triggers, procs... • Internal data: settings, defaults, menus... VCS Extreme: AmerOmnis ‘03

8. Managing workEncoda’s way • ALL work from an Idea: IMS database. • Idea is for a specific release version. • Bug Fixes: Idea per target release • If new work already done in format, need separate Ideas for version the bug was ‘found’ in, and for current development release. • Check In/Outs must relate to a valid Idea. • No unplanned work. VCS Extreme: AmerOmnis ‘03

9. Release IntegrityEach to its own • Create an independent, fully operational instance of each release. • Multiple databases. • Central independent code repository. • A ‘Portal’ to allow access to specific releases. • Citrix Published Applications for each release: QA on. • Development by ‘fat client’ (local libraries). VCS Extreme: AmerOmnis ‘03

10. Encoda’s EnvironmentOur ‘Releases’ • Multiple DB, Lbr, VCS combinations. • Dev: Developer ‘playground’. • DevQA: built every night from Dev VCS. • Dev Mgrs can review checked in work. • QAv1: first for testing, turns into release. • QAv2: ditto • QAv3: • etc. VCS Extreme: AmerOmnis ‘03

11. Omnis Development WorkflowMajor Steps • Idea for work defined, work spec’d. • Development ‘happens’. • Formats checked out/in to main VCS. • Nightly builds to DevQA for Dev. Mgmt. Review. • QA informed of Ideas which pass Dev Review. • QA requests ‘build’ of Idea. • Formats built to QAv# libraries (# from Idea). • DB changes applied to QAv# database. VCS Extreme: AmerOmnis ‘03

12. Non-Omnis Dev WorkflowMajor Steps • SASM: Self-Applying Script Manager • Database scripts: text saved in database. • schema changes, data manipulation. • Always ‘move forwards’ scripts. • ITD: Internal Tables Data: • App constants: ie: Int_Media_ID=19=Nat’l TV • Roles, dynamic menus, app behaviors. • Scripts, ITD entries tied to an Idea. Stay in sync with formats when Idea is requested. VCS Extreme: AmerOmnis ‘03

13. Bug Fix WorkflowMajor Steps • Bug Report received: specific release. • Find bug, scope work in that environment. • Specify which releases need fix. • May be fixed, or superceded by new work. • Determine if affected formats have ‘newer’ work yet or not. • No: same fix in releases from ‘bug source’ on. • Yes: manual fix in each, based on newer work. VCS Extreme: AmerOmnis ‘03

14. ImplementationSetup • VCS database in Oracle. • Multiple VCS’s, each in own schema. • A Oracle ‘user’ per VCS schema. • Log in as a specific VCS user to get to a VCS. • Citrix Published Apps per Release. • Point to dedicated set of libraries, db and VCS. • Slighly modified VCS library per Release. • Proper VCS logon hard-coded into library. VCS Extreme: AmerOmnis ‘03

15. VCS CustomizationsWhat we did • Oracle: • Tables: for logging check-in/check-out info. • Idea: IMS#, Release #, functional description. • Format Info: Format, Rev, Idea, Release, status. • Triggers: fire on chek-in/out for logging. • PL/SQL Packages: for moving VCS data. • Omnis: • ‘Auto-Builder’ Library triggers builds. VCS Extreme: AmerOmnis ‘03

16. Check-Out/Check-In ActivityWhat developers do • IMS# must be start of check in/out notes. • Check-out: validate Idea: # and Release. • If no work on format for higher release, OK. • If work logged on higher release, STOP! (bug?) • Do work in that Release environment. • Get IMS# for work in newer releases if needed. • Check-in: log format • Name, VCS rev#, IMS#, release# from Idea. VCS Extreme: AmerOmnis ‘03

17. Build RequestsWhat Managers or Testers do • Work on Idea complete, QA requests it. • A status field on Idea record is set. • Bug fix Ideas set by Dev. Mgmt. • Will force fix to QA for testing. • Same status field is set. • Records in Format Info table which are ‘ready to go’ to QA are now flagged. VCS Extreme: AmerOmnis ‘03

18. Formats-to-Go: Auto-BuildersMoving Formats and Building Libraries • OS Cron Job runs nightly: • Copy Formats: PL/SQL Package. • Build Releases: Omnis Libraries. • Move Releases: OS batch commands. • Releases ready for testing following morning. VCS Extreme: AmerOmnis ‘03

19. Copy Omnis FormatsBeta-Man to the Rescue • Oracle PL/SQL Package(used to be done manually) • Scans Format Info table for formats flagged to move. • Copies VCS record with format data to release-specific VCS based on Release # in Format Info. • Logs into VCS database as release-specific user, each release in turn, as needed. • Sets ‘sent’ flag in Format Info table. VCS Extreme: AmerOmnis ‘03

20. Automatic BuildsEach Release gets built • Custom Omnis library, 1 per Release. • Logs into VCS database as release-specific user, each release in turn, as needed. • Sets up list of Libraries to build from VCS, target directory specific to a release. • Triggers building of those libraries. VCS Extreme: AmerOmnis ‘03

21. All Releases to their ‘home base’Each Release gets archived and published. • OS Batch commands move each release to: • Archive location • File Server: for in-house fat-client testing • Citrix farm: for Published Apps • All release ready for testing the following morning. VCS Extreme: AmerOmnis ‘03

22. Deployment ProcessGetting a Release to Customers • Release package prepared: • Libraries for release zipped together. • SASM scripts for release exported from DB. • ITD records for release exported from DB • Done at Client Site: • Libraries into central location or Citrix farm. • SASM script records imported. • PL/SQL package run to apply SASM scripts. • Internal tables truncated, new values imported. VCS Extreme: AmerOmnis ‘03

23. ADS: Auto-Distribution SystemADS setup • ‘Master’ Directory on a File Server: • All Libraries in Release • An ‘master.ini’ file lists libraries and release dates. • On User’s local machine: • Omnis runtime. • A Local directory for user’s libraries. • An ‘local.ini’ file, listing local libs and release dates. • An ‘update.ini’ file with pointer/alias to Master dir. • Main libraries hops over to Update VCS Extreme: AmerOmnis ‘03

24. ADS: Auto-Distribution SystemADS operation • When user boots app (GENERAL library): • GENERAL library hops over to UPDATE library. • Local pointer file read, verifies server is mounted. • Master.ini and Local.ini read, entries compared. • Local lbr’s older than Master lbr’s copied down. • Local lbr’s not in Master.ini removed. • Local.ini file re-built with new list of lbr’s and dates. • UPDATE hops back to GENERAL with message to re-start without re-running Update process. VCS Extreme: AmerOmnis ‘03

25. VCS Extreme • That’s all, folks! VCS Extreme: AmerOmnis ‘03