Configuration Management for SAS® Projects John Quarantillo, Westat, Rockville, MD

NESUG 16 Applications Development

AD004 Get in Control! – Configuration Management for SAS® Projects John Quarantillo, Westat, Rockville, MD

Abstract Evolution of Development SAS applications development can benefit Environment Design greatly from the use of Configuration Manage- • Initially, programmers would often develop ment/Source Control software. Not only can systems in an ad hoc manner. There was lit- multiple developers stay on track, but also they tle or no separation between development can work independently on different modules and production. without stepping on each other’s code or inad- • Later, the need for program accuracy and vertently working on the same module simulta- data integrity brought about the need to cre- neously. The development area can be config- ate a separate development environment. ured in such a way that each developer has his • Larger development efforts brought about own independent work area that has a separate the need for separate testing staff that copy of all finalized programs, and interim cop- worked independently from the developers. ies of programs assigned to that developer. This • Finally, with the addition of version control, paper will illustrate techniques used to develop and multi-developer teams, a separate de- SAS programs for a production reporting system velopment environment was added for each running against an Oracle database. Develop- developer. ment teams of any size can implement these concepts that structure and organize the devel- Creating Multi-Environment opment, testing and deployment of SAS applica- Programs tions. Although this example shows SAS development using Microsoft Visual SourceSafe, The key to creating SAS programs that work in the same techniques can be implemented with more than one environment is to remove all ref- almost any configuration management software. erences to locations of data and other programs and place them in a “driver” program. The re- Introduction mainder of the programs is then defined as SAS Macros, which are called by the driver program. SAS developers are not immune to the chal- (Sample SAS code can be found at the end of lenges faced by developers using such pro- the paper.) gramming languages as Visual Basic, C++, etc. All developers need to address the issues of Version Control/Source Control change management, source code control, and Software configuration management. Proper use of version control software such as Visual SourceSafe There are many popular version control or can easily meet the challenges and address the source control software packages in use today. issues. In addition to using version control Basically, these programs allow developers to software, it is equally important to design the control and track changes to source code. This development environment to take full advantage project was already using Microsoft Visual of the benefits of using version control software. SourceSafe to manage the development of Ac- tive Server Page (ASP) code for a web-based interface, as well as middleware components ******************** developed using Microsoft Visual Basic. Visual SourceSafe integrates nicely with those development environments. Although Visual 1 NESUG 16 Applications Development

SourceSafe does not integrate directly into the SAS development environment, it can still be used to manage SAS programs.

Basic Model Our development life cycle has three separate phases. Development, Testing, and Production. Figure 1 illustrates the logical layout of our basic environment.

Each workspace contains all the necessary programs and directories necessary to run the system. This includes a “driver” program, a macro library, a directory in which “work” data sets can be dumped for troubleshooting, and an output directory. A separate work area is created in the workspace for each developer (see Figure 3).

After programs are developed, they move to the testing phase. Programs that pass testing, move into production, programs that fail testing, go back to development. Because the programs are developed using the “driver” approach, they can be freely moved from one step of the development life cycle (and its corresponding environ- In addition to creating a work area for each user, ment) to another without having to modify the there is also a “work area” for testing. This area source code. is not directly accessed by any of the developers. Source programs that are ready for testing Setting Up the Workspace are automatically placed here during the development process (this will be further explained in The development workspace is set up on a net- the “Using Shadow Folders” section below). work server volume. This is mainly done to Figure 4 shows the top-level layout for the de- take advantage of corporate infrastructure that velopment and testing workspace. provides backup of network volumes. The network volume also comes into play for the testing area. For illustrative purposes, we will out- line a team of 4 developers (Al, Bob, Chris, and Don.) Figure 2 shows the logical design of the ******************** multi-user environment from the perspective of the development life cycle.

2 NESUG 16 Applications Development

cannot be directly accessed without using the Visual SourceSafe interface. The Visual SourceSafe Administrator interface allows you to create what it calls “shadow folders”. Each Visual SourceSafe project can be associated with a physical directory on a network volume. Every time a developer checks in a program, the copy of that program is updated in the shadow folder. The main project folder should be set up with a Note that in Figure 4 there is no representation shadow folder directed to the “Testing” work of the production environment. The production area. Driver programs should not be put in environment is often on a different network shadow folders. server, and frequently on the opposite side of a firewall from a development/testing environ- Development ment. Programs are usually migrated to the production environment manually, or as part of The development process is fairly simple, once a separate install script. a user/developer has been set up correctly. Each time a developer begins to work on the project Add the Programs to Visual Source- they will need to do the following: ° Safe “Projects” Update their work area by choosing “Get Latest Version…” on the Visual SourceSafe The SAS programs are then added to Visual project folder. (see screenshot) SourceSafe “projects” which roughly corre- spond to directories or folders. This “project” structure should be as close as possible to the structure outlined in the previous discussion of workspaces. A good rule of thumb to follow is “something does not exist unless it has been checked in to Visual SourceSafe”.

Setting up Users in Visual Source- Safe Each developer is given a user account in Visual SourceSafe. Users with administrative rights can control what rights other users have, and can control their access to source programs on a “project" level. After a developer’s user account has been established, they need to open the Visual SourceSafe program, and set “working folders” for each directory set up in the workspace discussion above.

Using “Shadow” folders ° Choose the program(s) that they need to When a program is initially added to a Visual modify, right click and “Check Out” those SourceSafe project, or subsequently “checked programs. in” to Visual SourceSafe, that program code is ° Open SAS, or some other program editor, stored in the Visual SourceSafe database. It and make the modifications. 3 NESUG 16 Applications Development

° Unit test the modifications by submitting specific contents of a “release”. If a developer their user-specific driver program. Because needs to create a patch of a production program the developer has a current copy of all work- independent of the current development process, ing programs (see the first step) the newly they can obtain a copy of the exact version of modified program is tested against the cur- every program at the time of the release using rent programs in the testing environment. these labels. ° If the program modifications pass unit testing, check the programs back in to Visual SourceSafe, making sure to indicate what significant changes were made in the “Comments” section of the “Check In” dia- log box. Another good rule of thumb is to never check anything in without making a comment here. These comments become incredibly useful when reviewing a program’s history in Visual SourceSafe.

Testing After a developer has successfully modified a program, and unit tested it, the program is ready for full testing. This is usually communicated to the testing unit either through a change management tracking database, or possibly something as simple as emailing the testing team. Conclusions Because all programs currently checked into Visual SourceSafe are updated in the Testing As outlined above, with a bit of front-end envi- shadow folder, the testers can run the current ronment design and planning, and a small learn- system by simply submitting their user-specific ing curve to comfortably navigate the Visual driver program. SourceSafe interface, a SAS project can benefit greatly. The hidden beauty of managing pro- Production jects with source code control or version control comes to light when there is a problem with the After a number of program changes have been system. A developer can compare different ver- made, and successfully passed testing, they are sions of a program and see exactly what changes ready to be migrated to the production environ- were made and when. If developers followed ment. This can be done manually, or by using the “never check in a program without adding a an automated installation builder that will draw comment” mantra, troubleshooting program the current programs from the testing shadow changes should be greatly simplified. In addi- folder, and install them on the production envi- tion, a developer can be given an entire working ronment. At this point, it is important for the copy of a system at any “Label” point. (see Project Administrator to “Label” the project by Production above). Projects can also be right clicking the project, and choosing “Label” “branched” to allow for multiple development from the menu, and labeling the project with a paths, and later merged, using a built in differ- release number, or some other milestone (see ences interface. screenshot below).

Visual SourceSafe will place an entry in the

History of every file in that project. These la- ******************** bels are necessary to facilitate identifying the 4 NESUG 16 Applications Development

References Microsoft and Visual SourceSafe are registered trademarks of Microsoft, of Redmond, WA. Ray, C. (1998) “Establishing Production and  Development Environments for Base SAS Many thanks to Craig Ray, for laying the foun- Software Development” Proceedings of the dation for this structured approach. Twenty-Third Annual SAS Users Group Inter- national Conference, Paper 26. Contact Acknowledgments John Quarantillo SAS and all other SAS Institute Inc. product or Westat, Inc. service names are registered trademarks or 1650 Research Blvd. trademarks of SAS Institute Inc. in the USA and Rockville, MD 20850 other countries. ® indicates USA registration. [email protected]

Sample Code for a Simple Driver Program:

/*******************************************************************/ /* John Q's simplified driver program */ /* */ /* simple_driver.sas 6/16/2003 */ /* */ /* This program creates and sets the global macro variables */ /* necessary to use a Multi-Environment development approach. */ /* */ /*******************************************************************/

/* Macro that loops and calls the report for each region*/ %macro callrpts; %local j; /*Local loop counter */ %do j=1 %to &numregions; /* 1 -> &numregions run each report for all regions */ %let Region = &j; /* this should evaluate to actual region number */ %let Report = SimpleReport; %SimpleReport; /* Run the report */ %end; /* of %do j=1 %to &numregions; */ %mend callrpts;

%global Environ; /*var that indicates the Environment */ %global Developer; /*used to identify correct developer (and their environment)*/ %global ProgRoot; /*main directory where the macros are kept */ %global OutputRoot1; /*main directory where the output should go */ %global OutputRoot2; /*directory where the output for archival goes */ %global SaveWork; /*Save SAS work library? (1 = Yes) */ %global DB; /*database name */ %global LoginID; /*database loginID */ %global PW; /*database password */ %global UserName; /*database UserName */ %global Report; /*Name of Report (and program) */ %global Region; /*Region Number */ %global NumRegions; /*Number of Regions */

(continued)

5 NESUG 16 Applications Development

Sample Code for a Simple Driver Program (continued):

/* vvvv Use these to Run in Development environment vvvv */ %let Developer = Bob; *%let Developer = Testing; /*for Testing*/ %let Environ = DEV; %let ProgRoot = \\rk24\vol2404\KCCS\AD004\&Developer; %let OutputRoot1 = &ProgRoot\Output; %let OutputRoot2 = \\rk24\vol2404\KCCS\AD004\&Developer\ReportsArchive; %let savework = 1; /* ^^^^ Use these to Run in Development environment ^^^^ */

/* vvvv Use these lines to Run in PRODUCTION environment vvvv */ *%let Environ = PRD; *%let ProgRoot = d:\KCCS; *%let OutputRoot1 = \\FOSTS1\KCCSRPT; *%let OutputRoot2 = \\rk24\vol2404\KCCS\ReportsArchive; /* ^^^^ Uncomment these to Run in PRODUCTION environment ^^^^ */

%let LoginID = kccs_user; /* Same across all environments */ %let pw = kccs_pass; /* Same across all environments */ %let UserName = 0; /* Same across all environments */ %let DB = KCCS1&Environ; /* Varies based on value of Environ */ %let NumRegions = 2; /* Project Specific */

libname ora ORACLE user=&LoginID orapw=&pw path=&DB; libname workstuf "&ProgRoot\Work Dump"; options ls=100 ps=58 missing=' ' nofmterr mprint /*mlogic*/ notes mautosource sasautos=("&ProgRoot\Macros");

%callrpts

6 NESUG 16 Applications Development

Sample Code for a Simple Report Program (Macro):

%macro SimpleReport;

/**************************************************************** /* Name: SimpleReport.sas /* Date: 6/16/2003 /* Desc: Simple Report Program /****************************************************************/

ods pdf(1) file="&OutputRoot1\Region&Region&Report..pdf" notoc; ods pdf(2) file="&OutputRoot2\Region&Region&Report..pdf" notoc;

proc sql; connect to oracle (user=&LoginID orapw=&PW path="@&DB");

/* EXTRACT REPORT DATA */ create table ReportData as select * from connection to oracle ( SELECT * FROM vRoleRegion a WHERE

/* FILTER FOR REGION */ %if &Region ^= %THEN a.Region=&Region;

) as sasfile;

disconnect from oracle; quit;

/*for testing and debugging*/ %if &savework = 1 %then %do; proc datasets library=work nolist; copy out=workstuf; run; quit; %end;

/* INSERT CODE HERE TO CREATE REPORT OUTPUT (PROC REPORT/PRINT/TABULATE) */

Title1 "Report &Report for Region &Region"; proc print data=reportdata; run;

ods pdf(1) close; ods pdf(2) close;

%mend SimpleReport;