CM10.2 Power Builder Source Control

SESSION: ENTER SESSION
SPEAKER: ENTER SPEAKER

Prepared by Eric Saperstein 2
Introduction
• Eric Saperstein
– Software Configuration Manager for the
MetLife Sales Office Infrastructure (SOI)
Project
• Joined MetLife in March of ‘97.
• Reviewed the Existing Source Control
Procedures.
• Designed & Implemented New Source Control
Procedures.
– PVCS Administrator NJ State Medical
Underwriters
– Business Admin/CIS Degree Rider
University

Introduction - Objective
• Provide practical solutions for two
issues common to PowerBuilder
development projects.
– Accurate and Reliable Source
Control
– Managing Shared Resources

Agenda
• Part I - Sample Environment
Overview
– SOI Project Overview
– PowerBuilder 5.X and 6.X Overview
– What Makes up a PowerBuilder
Application?
– PVCS Version Manager Overview
– Environment Review
– Questions & Answers

Agenda
• Part II - Source Control
Implementation Goals
– Source Control Implementation
Goals

Agenda
• Part III - Two-Tiered Archive
Structure
– Two-Tiered Archive Structure
Objective
– Generic Promotion Model
– PowerBuilder Promotion Model
– PowerBuilder Source Control Model
-Two-Tiered Archive Structure

Agenda
• Part IV - The Staircase
Methodology
– Introduction and Objective
– The Staircase Methodology

Agenda
• Part V - Supporting Directory
Structure
– Applying the Staircase to a Directory
Structure
– Example Workstation Directory
Structure
– Example Server Directory Structure

Agenda
• Part VI - Conclusion
– SCM Implementation Goal Review
– Cost/Benefit Analysis
– Open Issues
– Closing - Total Commitment
– Open Floor

Part I
Sample Environment
Overview

SOI Project Overview
• The primary objective of the
MetLife Sales Office Infrastructure
(SOI) project is to provide the field
and sales office team members
with a reliable system that offers
all required business functionality.

• SOI Project Scale
– 6,000 Field Laptops
– 2,000 Sales Office Desktops
– 420 Sales Office Servers
– 23 Database Servers

• Supported Life Cycle Stages
– Design
– Development
– Unit Testing
– System Testing
– Production Pilot
– Production

• Multiple Production Environments
– Various Sales Office Models
– Various Sales Force Rep Profiles

SOI Supported Platforms
• Field Rep Laptops
–Windows 95
• Sales Office Desktops
– Windows NT 4.0
– Windows 95
– DOS / Windows 3.1

SOI Supported Platforms
• Servers
– Windows NT Server Version 4.0
• Development Systems
– Windows 95
– Windows NT 4.0

SOI Distributed
Development
• Development Sites
– Bridgewater, NJ
– Denver, CO
– Warwick, RI
– Telecommuters - 3 Team Members
– Third Party Sites

SOI Primary
Development Tools
• PowerBuilder Client/Server
Development
• Version 5.0.02, 5.0.04, 6.5
• Visual C++
– Version 5.0, 6.0
• Visual Basic
– Version 3.0, 4.0, 5.0, 6.0
• Sybase SqlAnywhere
– Version 5.0.3

SOI Source Control
Tools
• Current
– PVCS Version Manager
• Version 6.0.10

PowerBuilder 5.X and
6.X Overview
• Rapid Application Development &
Deployment
• Object Oriented Development
• Tiered Architecture
• Two Levels of Source Files
• Proprietary Development
Environment
• Supports/Encourages Common
Components

What Makes up a
PowerBuilder application?
• Application Specific PowerBuilder
Libraries, Source Code, &
Resource Files
• Common PowerBuilder Libraries,
Source Code, & Resource Files
• Third Party PowerBuilder
Resource Files

What Makes up a
• Application Specific PowerBuilder
Resource Files
• Each application performs a specific
business function. Source related to
this function is maintained by the
business unit teams in application
proprietary PCVS archives.
• Examples:
• Printing Sales Illustrations
• Save/Load Sales Illustrations
• Sales Illustration Solves

What Makes up a
• Common PowerBuilder Libraries,
Source Code, & Resource Files
• Some application functions may be
similar to the functions of other
applications. To reduce duplicate
efforts, these functions may be
developed and maintained as common
components.
• Examples:
• Database Interface
• Error Handling
• GUI Standards

What Makes up a
• Third Party Applications
– Applications purchased or
commissioned by MetLife that are
maintained by third parties. Third
party applications may be used as
common components.
• Examples:
• EZ Data Client Data System
• Sterling Wentworth Fact Finding & Needs
Analysis
• Lotus Notes Email

PVCS Version Manager -
Overview
• Source Code Library
• Check-out/Check-in Library
Functions
• Revision Tracking & History
• Version Labeling
• Branching & Multiple Development
Paths
• Source Code Integrity
• Archive Security

Environment Review - End
Part I
• We are supporting
applications that:
– Have proprietary
resources.
– Share resources.
– Have multiple
development paths.
– Are developed, built,
and maintained in a
distributed environment.
– Are at various stages of
their life cycle.

Pause for Questions &
Answers

Part II
Source Control

Source Control
• Clear & Measurable Increments.
• Measurable increments allow Project
Managers to accurately plan time lines
& resource allocation.
• Reliable Repeatable Releases.
• We must be able to accurately
reconstruct any version of an application
on demand.
• Isolated Development
Environments.
• Development, Unit Test, System Test,
EDM, and Production will be logically
separated and secured.

Source Control
• Accurate Control of Shared Resources.
• Shared resources must be clearly and
permanently labeled to ensure proven
compatibility with Laptop applications.
• Support All Stages of the Software Life
Cycle.
• Developers must have the ability to perform
maintenance on applications during any phase
of their life cycle.

Source Control
• Consistent Directory Structures.
• Developers must understand the
directory structures and where to locate
resources.

Part III
Two-Tiered Archive
Structure

Two Tier Archive Structure
• The objective of creating a Two
Tier Archive structure is to provide
source control at the most
granular level possible while still
producing releases from a single
source.

Generic Promotion Model
• Basic Logical Promotion Model
– Follows the “Staircase” Approach.

• Logical Model
– All Source Code in One PVCS
Archive
– Each Stage of the Life Cycle Is
Isolated
– Clear Concise Version Labeling
– No Physical Promotion Is Required

• Development
– Coding in Progress (PowerBuilder Splits Into Three
Levels)
• Unit Testing
– Development Team Testing of Compiled
Application
• System Testing
– Formal QA, Functionality, Integration, & Regression
Testing
• Production Pilot / Production
– Applications Currently In Use in the Users Systems

PowerBuilder Promotion
Model
• PowerBuilder Development Model
– The Development Step of the
Promotion Model Is Split Into Three
Levels:
• PBWORKING
• PBDEV
• PBUNIT
– Breaks The Rules of Logical Promotion
– Requires Redundant Archival

Model
– PBWORKING - Developer’s
Personal Working Directory
• Object Level / File Level Source Control
• On Local System or Share Server
• Accessible Only by Individual
Developers

Model
– PBDEV - Development Team
PowerBuilder Library
• Object Level Source Control (First
PVCS Archive)
• Located on PVCS Server
• Accessible by All Team Members for
Checkout/checkin Only

Model
– PBUNIT - Read Only Development Team
Reference Library
• File Level Source Control (Second PVCS
Archive)
• Contains Individual Developer Tested Source
Code for Reference by All Team Members
• The “Staircase” Methodology Applies
• Located on PVCS Server
• Accessible to All Developers That Require
Access

PowerBuilder
Source Control Model
-Promotions from PBDEV to
PBUNIT
– Physical Promotion
– Bridges the Gap Between File and
Object Level Archives
– Requires Planning and
Communications
– Requires a Staging Directory
(PBPROMOTE)

PowerBuilder
• Two Tier Source Control
– File Level - PBL’s, Help Files, Images,
etc.
• File level version control allows applications
to be recreated from one source library.
• Does not provide version control on PB
objects.
– Object Level - PowerBuilder Objects
• Provides version control for PB objects.
• Does not provide the ability to recreate
applications from one source library.

PowerBuilder
• File Level Source
Control.
– Branching
– Multiple Version
Labels
– Promotion Models
– Recreate
Applications From
One Source
– File Level History
– Locking at the PBL
Level

PowerBuilder
• Object Level Source
Control.
– Object Level History
– Locking at the Object
Level
– Branching in PB 6.5
only
– No Source Control
Tool Promotion
Models
– Can Not Recreate
Complete
Applications From
One Source

PowerBuilder
• Advantages of Two Tier Source
Control
– One Source Library for Repeatable
Releases
– Object Level Control & History
– Promotion Modeling
– Support for Branching

PowerBuilder
• Disadvantages of Two Tier Source
Control
– Redundant Archival of Objects
– No Object Level Source Control on
Branches Created at the File Level
– Difficult to Track Which Version of an
Object Is in Which Version of a PBL

Part IV
The Staircase
Methodology

The Staircase Methodology
• The Objective of the Staircase
Methodology is to provide a
consistent, stable, and accurate
means of sharing resources
between multiple applications.

• Introduction - The
“staircase” is an easily
visualized physical
representation of the our
source control
methodology.
– The Goal: Climb the
staircase.
– The Catch: The
staircase is always
under construction.

• A staircase provides an
incremental path from
point A to point B.
– Each increment, or step, is
a visible physical target.
– The increments are a
constant; they remain in
place before, during, and
after use.
– Gaps between Increments
are measurable.

• Measurable
increments allow
for accurate
planning.
• Accurate planning
is key if deadlines
are to be met and
resources
accurately
allocated.

• How does a
“Staircase” Apply to
Development?
– The staircase
represents an
application.
– The Step represents
a version of an
application.
– The rise represents
a measurable
increment between
versions.

• The Developers
both build the
staircase, and
climb the steps.
• Steps can be
added to a
staircase without
effecting current
climbers.

• Managing Business Unit
Applications
– Each Can Have Only One Revision
Per System
– Each Has a Staircase
– Each Has a Versioning Scheme
– Each Version Has Release Notes

• Managing Common Components
– Support Other Applications As Customers
– Each Can Have Multiple Revisions on One
System

• Managing Third Party Applications
– Support Other Applications As Customers
– Can Have Only One Revision on a
System
– Must Be Compatible With All Applications
on the on the Laptop at the Time of Their
Deployment

• Applying the Staircase Practically:
– What happens when Wigits 1.0
requires resources from common
source?

• Practical
Application:
– A step is a repeatable
version of an
application.
– The Wigits team will
choose a version of the
Common Source to
reference, in this case
1.2.
– The chosen version of
Common Source is a
fixed reproducible
reference point.

• What happens when things go wrong with a
step? There are three possible situations:
– The step is not in use, and may be fixed with no
impact.
– The step is in use, and the user can climb to the
next step.
– The step is in use, and the user can not climb to
the next step.

• The step is not in use, and may be
fixed with no impact.
– The step is replaced, and the old one
removed from the staircase for safety.
Climbers below are routed to the new step.
• The step is in use, and the user
can climb to the next step.
– The user climbs to the next step and
climbers below are notified to skip the
broken step.

• The step is in use, and the user
can not climb to the next step.
– A step in between the broken step and the
next step must be built to move the climber
to safety. The source control term for this
is “branching.”

• Branching occurs when
there is an enhancement
or bug in a fixed version.
– A new step is created
between existing steps.
– Application teams may
choose to use this step or
skip it as they can any
other step.

• Branching should be used
sparingly. The cost can
be high. Branching can:
– Trigger duplicate bug &
enhancement fixes.
– Impede historical version
tracking if not handled
carefully.
– Result in rogue
applications that are
difficult to route back
towards the trunk.

• Key Items to Remember When Fixing
Steps
– Notify stair climbers of the repairs in progress.
– Notify stair climbers of any available detours.
– Notify stair climbers upon repair completion.
– Check the other steps above and below the
broken step for the same problem.
– Documentation
– Release Notes

Part V
Supporting Directory Structure

Supporting Directory
Structure
• Applying the Staircase to a Directory
Structure
– Each Staircase Gets a Directory
• Each Step Gets a Subdirectory
• Each Rise Gets a Release Notes Document
W ig it s 1 . 0
W ig it s 1 . 1
W ig it s 1 . 2
W ig it s 1 . 3
W ig it s 1 . 4
W ig it s

Structure
• Applying the Staircase to a Directory
Structure
– One Directory Per Application
• One Sub-Directory Per Version
• One Document Per Version
W i g i t s 1 . 0
W i g i t s 1 . 1
W i g i t s 1 . 2
W i g i t s 1 . 3
W i g i t s 1 . 4
W i g i t s

Structure
• All applications exist with this directory structure
• Applications can reference any version of any
other application to obtain required resources
W ig it s 1 . 0
W ig it s 1 . 1
W ig it s 1 . 2
W ig it s 1 . 3
W ig it s 1 . 4
W ig it s
C o m m o n 1 . 0
C o m m o n 1 . 3
C o m m o n 1 . 5 . 1
C o m m o n 1 . 6
C o m m o n 1 . 7
W ig it s

Structure
• Example Workstation Directory
StructureD e v e lo p e r s P C o r H o m e D ir e c t o r y
C o m m o n S o u r c e
W i g i t s
F i g i t s
P B 5 D E V
W i g i t s
F i g i t s
P B 5 S N A P S H O T
P B 5 W O R K IN G

Structure
• Example Server Directory
Structure
P V C S S e r v e r
W i g i t s
F i g i t s
P B 5 D E V
W i g i t s
F i g i t s
P B 5 U N IT
W i g i t s
F i g i t s
P R O M O T E
S O U R C E

Part VI
Conclusion

Conclusion
• SCM Implementation Goal Review
– Established Clear & Measurable Increments
• The “Staircase” Methodology
• Release Documents
– Provided Reliable Repeatable Releases
• PVCS Version Manager
– Isolated the Development Environments
• Promotion Modeling

Conclusion
– Accurately Versioned Shared
Resources
• Release Documents
– Provided Support Structure
Throughout the Software Life Cycle
• Reliable Repeatable Releases

Conclusion
– Provided Consistent Directory
Structures
• Reliable Repeatable Releases
• Distinct Directory Names

Conclusion
• Cost Benefit Analysis - The Costs
– Increased Load Common Objects
Team
• Must Support Multiple Releases
• Must Handle Branching and the
Resulting Duplicate Bug Fixes &
Enhancements
– Increased Configuration
Management Effort
• Support Two-Tiered Archive
• Physical Promotions

Conclusion
• Cost Benefit Analysis - The Benefits:
– Fixed versions are not impacted by
the requirements of other
applications.
– The Project Managers can plan
based on measurable increments.
– The Common Source team can
continue development and build
new top steps without impacting
existing steps.

Conclusion
• Cost Benefit Analysis - The Benefits:
– Assurance that the correct versions are
tested and deployed.
– The advantage of Common Components
without the disadvantage of being chained
to the schedules of other teams.
– Provides the option of branching.

Conclusion
• Bottom Line:
– By Increasing The Load The Common
Objects and Configuration Management
Teams, We Decreased The Load on 16
Business Unit Application Teams.

Conclusion
• Closing
– Source control can be successfully
implemented for PowerBuilder
Projects.
– Source control can be an invaluable
part of the development
infrastructure that reduces overall
development costs.
– Total commitment to success is
required, without it, your source
control effort will fail.

Conclusion
• Closing - Total Commitment Includes:
– An Individual Dedicated to Source Control
– Support of Project Managers
– Support of Management
– Source Control Training for All
Development Team Members &
Management
– Policing Yourself: Strict Enforcement of
Source Control Procedures for All Team
Members and Management With No
Exceptions

Open Floor
Eric Saperstein
Contact Number: (908) 253-1881
Email: esaperstein@metlife.com
Thank you!

CM10.2 Power Builder Source Control

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to CM10.2 Power Builder Source Control

Similar to CM10.2 Power Builder Source Control (20)

More from Eric Saperstein

More from Eric Saperstein (7)

CM10.2 Power Builder Source Control