CM10.2 Power Builder Source Control

Post on 14-Jul-2015

46 views 1 download

Tags:

Transcript of 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

Prepared by Eric Saperstein 3

Introduction - Objective

• Provide practical solutions for two issues common to PowerBuilder development projects.– Accurate and Reliable Source

Control– Managing Shared Resources

Prepared by Eric Saperstein 4

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

Prepared by Eric Saperstein 5

Agenda

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

Goals– Questions & Answers

Prepared by Eric Saperstein 6

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– Questions & Answers

Prepared by Eric Saperstein 7

Agenda

• Part IV - The Staircase Methodology– Introduction and Objective– The Staircase Methodology– Questions & Answers

Prepared by Eric Saperstein 8

Agenda

• Part V - Supporting Directory Structure– Applying the Staircase to a Directory

Structure– Example Workstation Directory

Structure– Example Server Directory Structure

Prepared by Eric Saperstein 9

Agenda

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

Prepared by Eric Saperstein 10

Part ISample Environment

Overview

Prepared by Eric Saperstein 11

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.

Prepared by Eric Saperstein 12

SOI Project Overview

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

Prepared by Eric Saperstein 13

SOI Project Overview

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

Prepared by Eric Saperstein 14

SOI Project Overview

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

Prepared by Eric Saperstein 15

SOI Supported Platforms

• Field Rep Laptops

– Windows 95

• Sales Office Desktops– Windows NT 4.0– Windows 95

– DOS / Windows 3.1

Prepared by Eric Saperstein 16

SOI Supported Platforms• Servers

– Windows NT Server Version 4.0

• Development Systems– Windows 95– Windows NT 4.0

Prepared by Eric Saperstein 17

SOI Distributed Development

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

Prepared by Eric Saperstein 18

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

Prepared by Eric Saperstein 19

SOI Source Control Tools

• Current– PVCS Version Manager

• Version 6.0.10

Prepared by Eric Saperstein 20

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

Prepared by Eric Saperstein 21

What Makes up a PowerBuilder application?

• Application Specific PowerBuilder Libraries, Source Code, & Resource Files

• Common PowerBuilder Libraries, Source Code, & Resource Files

• Third Party PowerBuilder Libraries, Source Code, & Resource Files

Prepared by Eric Saperstein 22

What Makes up a PowerBuilder application?

• Application Specific PowerBuilder Libraries, Source Code, & 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

Prepared by Eric Saperstein 23

What Makes up a PowerBuilder application?

• 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

Prepared by Eric Saperstein 24

What Makes up a PowerBuilder application?

• 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

Prepared by Eric Saperstein 25

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

Prepared by Eric Saperstein 26

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.

Prepared by Eric Saperstein 27

Pause for Questions & Answers

Prepared by Eric Saperstein 28

Part IISource Control

Implementation Goals

Prepared by Eric Saperstein 29

Source Control Implementation Goals

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

Prepared by Eric Saperstein 30

Source Control Implementation Goals

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

Prepared by Eric Saperstein 31

Source Control Implementation Goals

• Consistent Directory Structures.• Developers must understand the

directory structures and where to locate resources.

Prepared by Eric Saperstein 32

Part III

Two-Tiered Archive Structure

Prepared by Eric Saperstein 33

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.

Prepared by Eric Saperstein 34

Generic Promotion Model

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

Prepared by Eric Saperstein 35

Generic Promotion Model

• 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

Prepared by Eric Saperstein 36

Generic Promotion Model• 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

Prepared by Eric Saperstein 37

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

Prepared by Eric Saperstein 38

PowerBuilder Promotion Model

• PowerBuilder Development Model– PBWORKING - Developer’s

Personal Working Directory • Object Level / File Level Source Control

• On Local System or Share Server• Accessible Only by Individual

Developers

Prepared by Eric Saperstein 39

PowerBuilder Promotion Model

• PowerBuilder Development 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

Prepared by Eric Saperstein 40

PowerBuilder Promotion Model

• PowerBuilder Development 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

Prepared by Eric Saperstein 41

PowerBuilderSource Control Model

• PowerBuilder Development 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)

Prepared by Eric Saperstein 42

PowerBuilderSource Control Model

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

Prepared by Eric Saperstein 43

PowerBuilderSource Control Model

• File Level Source Control.– Branching

– Multiple Version Labels

– Promotion Models

– Recreate Applications From One Source

– File Level History– Locking at the PBL

Level

Prepared by Eric Saperstein 44

PowerBuilderSource Control Model

• 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

Prepared by Eric Saperstein 45

PowerBuilderSource Control Model

• Advantages of Two Tier Source Control– One Source Library for Repeatable

Releases– Object Level Control & History– Promotion Modeling– Support for Branching

Prepared by Eric Saperstein 46

PowerBuilderSource Control Model

• 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

Prepared by Eric Saperstein 47

Part IV

The Staircase Methodology

Prepared by Eric Saperstein 48

The Staircase Methodology

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

Prepared by Eric Saperstein 49

The Staircase Methodology• 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.

Prepared by Eric Saperstein 50

The Staircase Methodology• 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.

Prepared by Eric Saperstein 51

The Staircase Methodology• Measurable

increments allow for accurate planning.

• Accurate planning is key if deadlines are to be met and resources accurately allocated.

Prepared by Eric Saperstein 52

The Staircase Methodology• 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.

Prepared by Eric Saperstein 53

The Staircase Methodology

• The Developers both build the staircase, and climb the steps.

• Steps can be added to a staircase without effecting current climbers.

Prepared by Eric Saperstein 54

The Staircase Methodology

• 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

Prepared by Eric Saperstein 55

The Staircase Methodology• Managing Common Components

– Support Other Applications As Customers– Each Can Have Multiple Revisions on One

System – Each Has a Staircase– Each Has a Versioning Scheme– Each Version Has Release Notes

Prepared by Eric Saperstein 56

The Staircase Methodology

• 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

– Each Has a Staircase– Each Has a Versioning Scheme– Each Version Has Release Notes

Prepared by Eric Saperstein 57

The Staircase Methodology

• Applying the Staircase Practically:– What happens when Wigits 1.0

requires resources from common source?

Prepared by Eric Saperstein 58

The Staircase Methodology• 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.

Prepared by Eric Saperstein 59

The Staircase Methodology

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

Prepared by Eric Saperstein 60

The Staircase Methodology• 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.

Prepared by Eric Saperstein 61

The Staircase Methodology

• 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.”

Prepared by Eric Saperstein 62

The Staircase Methodology

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

Prepared by Eric Saperstein 63

The Staircase Methodology

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

Prepared by Eric Saperstein 64

The Staircase Methodology

• 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

Prepared by Eric Saperstein 65

Part V

Supporting Directory Structure

Prepared by Eric Saperstein 66

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 i g i t s 1 . 0W i g i t s 1 . 1W i g i t s 1 . 2W i g i t s 1 . 3W i g i t s 1 . 4

W i g i t s

Prepared by Eric Saperstein 67

Supporting Directory 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 . 0W i g i t s 1 . 1W i g i t s 1 . 2W i g i t s 1 . 3W i g i t s 1 . 4

W i g i t s

Prepared by Eric Saperstein 68

Supporting Directory Structure

• All applications exist with this directory structure• Applications can reference any version of any

other application to obtain required resources

W i g i t s 1 . 0W i g i t s 1 . 1W i g i t s 1 . 2W i g i t s 1 . 3W i g i t s 1 . 4

W i g i t s

C o m m o n 1 . 0C o m m o n 1 . 3C o m m o n 1 . 5 . 1C o m m o n 1 . 6C o m m o n 1 . 7

W i g i t s

Prepared by Eric Saperstein 69

Supporting Directory Structure

• Example Workstation Directory Structure

D e v e l o p e r s P C o r H o m e D i r e c t o r y

C o m m o n S o u r c eW i g i t sF i g i t s

P B 5 D E V

C o m m o n S o u r c eW i g i t sF i g i t s

P B 5 S N A P S H O T

P B 5 W O R K I N G

Prepared by Eric Saperstein 70

Supporting Directory Structure

• Example Server Directory Structure

P V C S S e r v e r

C o m m o n S o u r c eW i g i t sF i g i t s

P B 5 D E V

C o m m o n S o u r c eW i g i t sF i g i t s

P B 5 U N I T

C o m m o n S o u r c eW i g i t sF i g i t s

P R O M O T E

S O U R C E

Prepared by Eric Saperstein 71

Part VI

Conclusion

Prepared by Eric Saperstein 72

Conclusion

• SCM Implementation Goal Review– Established Clear & Measurable Increments

• The “Staircase” Methodology• Release Documents

– Provided Reliable Repeatable Releases• PVCS Version Manager• Version Labeling

– Isolated the Development Environments• PVCS Version Manager• Version Labeling• Promotion Modeling

Prepared by Eric Saperstein 73

Conclusion• SCM Implementation Goal Review

– Accurately Versioned Shared Resources

• PVCS Version Manager• Release Documents

– Provided Support Structure Throughout the Software Life Cycle

• The “Staircase” Methodology• Reliable Repeatable Releases • Version Labeling• Promotion Modeling

Prepared by Eric Saperstein 74

Conclusion

• SCM Implementation Goal Review – Provided Consistent Directory

Structures• The “Staircase” Methodology• Reliable Repeatable Releases• Version Labeling• Promotion Modeling• Distinct Directory Names

Prepared by Eric Saperstein 75

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

Prepared by Eric Saperstein 76

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.

Prepared by Eric Saperstein 77

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.

Prepared by Eric Saperstein 78

Conclusion• Bottom Line:

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

Prepared by Eric Saperstein 79

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.

Prepared by Eric Saperstein 80

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

Prepared by Eric Saperstein 81

Open Floor

Eric Saperstein

Contact Number: (908) 253-1881

Email: esaperstein@metlife.com

Thank you!