Compuware Test Drive Source Code Management, Deployment, and release Automation

Transcription

1 Compuware Test Drive Source Code Management, Deployment, and release Automation

2 Contents Getting Started with SCM - ISPW... 3 Code Changes... 7 ISPW Impact Analysis Promotion NEXT STEPS... 49

3 Getting Started with SCM - ISPW The goal of this test drive section is to provide you with experience using Agile Source Code Management, Deployment, and release Automation on a mainframe platform. Compuware ISPW enables developers to quickly and safely build, test and deploy mainframe code. This test drive will take you through the following activities: Code changes Impact analysis Compiling Promotion into test and production environments Instructions: This guide contains many screenshots to provide a visual reference Every action you must take is in BOLD Please note each place that you must enter your own specific ID or number You must complete each step before proceeding to the next to successfully follow the test drive script. The Compuware Test Drive Experience requires that users complete the Building Your Environment plorers_tw_test_drive.pdf exercise before starting any tutorial script. If, at any point during your experience, your host connection times out, you may need to log back in to the TestDrive host connection.

4 To get started in the Topaz Workbench: Open the Host Explorer perspective Click on the arrow next to Hosts, Right-click on TestDrive and select Login Logon on with the user credentials that were provided to you for with the TestDrive and click OK select ISPW from the Compuware menu

5 During this test drive you will encounter terms specific to ISPW. Here is a glossary for your convenience. Terminology Term Application Stream Life-cycle Level Component Component version Task Part Warehouse Assignment container Release container Set container Add task Checkout task Edit task Generate task Promote task Regress task Delete task Fallback task Deploy task Description A group of related elements. ISPW Processing is controlled by application. Examples of applications are the Payroll Application, the Accounts Payable Application, and the General Ledger Development life-cycle used by one or more Applications Transitional code states (DEV, QA, PROD) in the development life-cycle Instance of a code state (DEV, QA, PROD) SCM managed object such as a COBOL source member. An immutable version of a component. An instance of a unit of work. For example, a change to a component. A generated object such as a load module, or a Listing or a DBRM Storage location for inactive historical or overlaid component versions (source and parts). A package of one or more, usually related, tasks. A development container that is used to organize and manage development work. A package of tasks from one or more assignment containers. An operational container that is used to organize and manage operational releases. A package of tasks at an instance in time. A special ISPW container that is used internally to organize and manage work requests. Make a statement of intent, often because of some impact analysis. Copy source to development area Make a change to the source in the development area. Execute Compile and Link processes. Move task forward to the next level in the life-cycle. Move task backwards to the previous level in the lifecycle. Remove a task from the development area Restore previous version of task. Implement task in one or more Run Time environments.

6 Substitute your values in the screenshots In this test drive the screen shots provided have used specific values that may differ from your assigned values. These were provided in your notice. While taking the test drive, you must substitute your assigned values! Variable Your Assigned Values Application Txxx* Assignment prefix Txxx* * For the value of xxx, substitute the last three digits of your test drive ID.

7 Code Changes Your development task in this test drive is to change 2 COBOL copybooks and promote them and any other impacted components thru the application life-cycle to production. First, you will find and collect the two copybooks into an ISPW assignment from which you can perform all this work. 1. Change Stream to CWEZ. 2. Change Application to your assigned application value (Txxx, where xxx is your unique number). 3. Set Level to PRD and ensure that Level option is set to Selected level only. 4. Filter the view even further by typing copy in the Type field. This will allow you to focus only on the copybook components available in your stream / application at the PRD level. Click Apply (circled). Use your assigned values. See instructions above

8 5. The ISPW Repository view lists the COPY components for your application. Right-click on TCPYA01 and click Add to Assignment with Checkout.

9 In the Add task dialog, click New to the right of Assignment (circled). This will allow you to create a new assignment container to put your copybook into.

10 For Stream, use CWEZ. For Application, use your assigned application and use the same value for Assignment prefix. See Substitute your values in the screenshots. Select DEV1 for Default path and provide a description for your assignment. Note: DEV1 is one of 4 paths defined to this application which the components can take to production. A picture of the life-cycle will be provided further along the test drive. Click OK.

11 A message will be displayed providing you with your new assignment name. Make note of the assignment name. Click OK. Your new assignment has been created and is ready to have tasks added to it. An assignment container is the only container type in ISPW that tasks can be added to. The assignment container is where, as a developer, you will spend much of your time. If your new assignment name does not appear in the Assignment field, select it from the drop-down box, then click OK.

12 Messages will be displayed to inform you that the task has been added to your assignment and checked out to the DEV1 level. You have added your first task to your first assignment. Click OK. Scroll thru the list and find TCPYB01 at level PRD. Right-click on it and click Add to Assignment with Checkout.

13 Select your assignment from the drop-down box. Click OK. Messages will be displayed to inform you that the second COPY task has been added to your assignment and checked out to the DEV1 level. A new version of the source has been copied, in this case from the PRD level, to the DEV1 level dataset. Click OK.

14 Open the ISPW Containers view. To do this, click the Window menu, mouse over Show View and click ISPW Containers. The ISPW Containers View shows all the containers which belong to you. Your new assignment should be included in this view.

15 Your assignment has been created and you should now have 2 copybooks in it. There are two ways to view the tasks your assignment: one is to double-click on the assignment entry in your container List. The other is to right-click on the assignment entry and click View Tasks (shown in the screenshot below). The ISPW Tasks view will open and the 2 tasks that were added will be listed. Every operation that needs to be performed on these tasks and other components which are impacted by changing these 2 tasks (edit, impact analysis, compile, promote, deployment there are over 50 operations available) can be performed from this space this assignment. Note that the COPY tasks in the assignment are checked out and sitting in the DEV1 level. The checkout date/time and userid is reflected in the task information.

16 At checkout, a destination level for the checkout was chosen DEV1. To see the ISPW life-cycle diagram, path structure, that was constructed for the Application, click on the View Life- Cycle button.

17 A picture of the life-cycle is presented. Click once on one of the two tasks. You will notice the levels containing versions of the highlighted COPY task are colored indicating the existence of a version of that component at those levels. From this picture it is very easy to visually see where versions exist. By choosing the DEV1 level, you have defined the path to production DEV1-QA1-STG-PRD. Other versions of these components may also exist at other levels and may be passing thru the other three paths FIX, DEV2 or DEV3. Four paths were created for the application one for emergencies starting at level FIX and three for development starting at DEV1, DEV2 and DEV3. The application level structure is customizable when defining the applications to ISPW. Any number of paths can be defined with a minimum of three levels.

18 Now that you have a version of each copybook the next step would be to make changes to one of them. To do this either right-click on TCPYA01 and click Open or simply double-click on it. The version s source will be presented in SlickEdit for editing. Change the source but ensure you do not break the copybook (perhaps change/add a comment). Once you have made a change, close the SlickEdit view. Click Yes to save the changes. Note the Operation, date/time and User ID fields have been updated to reflect the change in the task status. Now make a similar change to TCPYB01 and save it.

19 ISPW Impact Analysis Now that changes have been made to both copybooks it is time to find out what components are affected by these changes. Right-click on the TCPYA01, mouse over View and then click on Impacts.

20 The ISPW Impacts view is opened showing the components impacted by the change to the COPY TCPYA01 component. Information is provided showing the level at which these components exist in the current Path to production as well as the type of relationship static or dynamic. In the ISPW Impacts view, click on the filter button Make sure your level of indirection is at least 5. Select Reset, then click OK

21 Expand the impacts level of indirection as indicated below Understanding the impacts: The list above shows the component for which the impact option was requested, as well as those components related to and thus potentially impacted by a change to this component. The Level of Indirection column contains numbers and indentations to indicate the relationships of the changed component to the other components listed. Coloring is also used to indicate the calling level. o The value of 0 indicates the component for which this impacts list was built (the changed component). o ISPW will display one level downward with a value of -1. Downward means these -1 components are called/used by the changed component. o o o ISPW will also display up to 32 calling levels upward - that is, component A calls component B calls component C.and so on. up to the call of the changed module. The positive 1 indicates components which directly call/use the changed component. The positive 2 indicates components which call/use the positive 1 above them.

22 In the example below: TCPYA01 is the changed module and it has a Level of Indirection value of 0. Cobol program TPROG01 is at Level of Indirection value of 1 which means it calls/uses COPY TCPYA01 directly. JOB TJOB01 is at Level of Indirection value of 2 which means it calls/uses the component above it at value 1. So, Job TJOB01 calls/uses COB TPROG01 which in turn calls/uses COPY TCPYA01. To visually see the call structure, click on the Visualize Impacts icon.

23 The impact structure is displayed. This visualization is very simple. Calling structures can become quite complicated which makes a visualization of the structure very valuable it enables a quick understanding of the component relationships. Close the Visualization view. To manually add the impacted components (TPROG01 and TJOB01) to your assignment, select both (click on the first one and then Ctrl-click on the second one), right-click on the grouping and click Add to Assignment with Check Out.

24 The add task to assignment dialog will appear. Simply click OK to add the first task. Close the ISPW Impacts view to see the assignment task list view. You now have 4 tasks in your assignment. A message is presented to indicate that the first task is checked out. Click OK. A second Add task to assignment dialog is presented. Click OK. A message is presented to indicate that the second task is checked out. Click OK. The original 2 COPY tasks are in the assignment (and have been edited) and now there are 2 new tasks a COB type (Cobol program) and a JOB type (JCL). The 2 new tasks also are at DEV1 and have been checked out but nothing else has been done to them.

25 Right click on TCPYB01, mouse over View then click Impacts.

26 The ISPW Impacts view is opened showing the components impacted by the change to the COPY TCPYB01 component. In the example above: TCPYB01 is the changed module and it has a Level of Indirection value of 0. Cobol program TPROG01 is at Level of Indirection value of 1 which means it calls/uses COPY TCPYB01 directly. JOB TJOB01 is at Level of Indirection value of 2 which means it calls/uses the component above it at value 1, being TPROG01. So, Job TJOB01 calls/uses COB TPROG01 which in turn calls/uses COPY TCPYB01. Also, TSUBR01 is at Level of Indirection 1 which means it also directly calls/uses COPY TCPYB01. COB TPROG01 is at Level of Indirection 2 under TSUBR01 which shows TSUBR01 is called/used by TPROG01. And then JOB TJOB01 is at Level of Indirection value of 3 under TPROG01 so TJOB01 calls/uses TPROG01. Thus, TJOB01 calls/uses COB TPROG01 which calls/uses COB TSUBR01 which calls/uses COPY TCPYB01.

27 To visually see this call structure, click on the Visualize Impacts icon. A diagram depicting the relationships listed above is displayed (to see the larger display you can maximize this view by double-clicking on the view tab).

28 Double click on the view tab and then close the visualization view. Under the Level column, you can see that TSUBR01 only exists at the PRD level. Since the copybook changes have impacted this subroutine, we want to recompile this program and thus we must add it to the assignment as well. To add the impacted program (TSUBR01) to your assignment, select the task, right-click and click Add to Assignment with Check Out. (Note ISPW also provides a Generate Impacts option that allows mass adding and generating of tasks to assignments based on the list of components in assignments or releases. So, for larger volumes of changes, it is not necessary to go thru the impacts for each individual task.)

29 The Add Task dialog is displayed. Click OK to add this component as a task to your assignment with DEV1 as the chosen path. A confirmation prompt is displayed when the task has been added. Click OK. Close the ISPW Impacts view.

30 The TSUBR01 task has been added to your assignment and the level should now show DEV1. If the level for TSUBR01 is not DEV1, click the refresh button. As the subroutine calls one of the changed copybooks, it needs to be compiled/generated. To do this right-click on TSUBR01 and click Generate.

31 A status will display showing that the task has been generated. The screen will refresh automatically when the generate is done. A Host Explorer message will appear displaying a job completed message with the job name and number. Click on the Host Explorer message to see the generate job output. Close the message and the generate output when you have finished browsing the output.

32 When the generate is done, the task will be updated with the date and time of the generate, the user who performed the generate, and the operation will reflect a generate has occurred. The listing from the generate can be browsed at any time by right-clicking on the task and clicking View Generate Listing.

33 The listing is displayed in a SlickEdit window. Scroll up and down, notice that everything is available that you normally see in a listing. Close the listing display when you are finished. As part of the generate, ISPW collects each of the parts created as part of the generate (load, listing, DBRM, etc.) and registers them against the source. To view the generated parts, right-click on the task, mouse over View and then click Parts.

34 The generate of this subroutine created a DDIO (part DMEM), an Object and a Listing. The types of parts created can be unique by application and type of component as well as the values of the generate parms. Close the ISPW Parts view. Now that the statically linked subroutine has been generated, the mainline which calls it needs to be generated. To do this right-click on the TPROG01 task and click Generate.

35 The COBOL program will be generated, and your assignment task list will be updated to reflect the new status. The Operation will be Generate. The User ID, Date/Time will be updated. The message will be updated to reflect the successful completion of the generate. If you want to see the listing: Click on the Host Explorer message to see the generate job output or right click on the program and either view generate listing or generate job output.

36 Promotion At this point you have Edited 2 copybooks. Determined the impacted modules and collected them all in your assignment container. Generated the programs in the correct order. Now you are ready to promote your changes to the QA1 level. Select all the tasks by clicking on the top task in your assignment then holding the shift key down, clicking on the bottom task.

37 To promote all the tasks to the QA1 level right-click on the tasks and click Promote. This action will create a set container. Sets are a special category of containers within ISPW that are used to conduct operations such as promotion and deploy. They are temporary and created by ISPW as needed for the work. This allows you to promote subsets of tasks within an assignment container without the need to act on all the tasks at once.

38 Once you click Promote, the selected tasks are placed in a set container for the promotion. The ISPW set processor will: Perform the promotions of all the source to QA1. Cleanup the DEV1 level (source and parts if applicable). Perform generates, in order, of all the tasks in the set which require a generation. Deploy to runtime environments (if required). As the tasks in the set are being processed you can monitor the progress by clicking the refresh button (circled).

39 In the screenshot below, you can see the promotion has progressed the 5 tasks have been promoted to QA1 (see the Level value and the Operation in the task list as well as the highlighted level in the picture). The subroutine generate is started before the mainline generate. The mainline generate will wait until the subroutine generate has completed successfully. ISPW s set processor performs generates of the tasks that are contained in one set in the correct order automatically. This helps ensure even inexperienced developers are productive and everyone stays within site standards. Click OK when the confirmation dialog comes up that the 5 tasks have been promoted.

40 In the screenshot below a final refresh has been done showing that: The promotion has completed. All the tasks have successfully been promoted to QA1. All the generates have completed successfully. Note the Operation column of the 2 programs shows Generate as the last operation. The set processor performed a promotion and then a generate as ISPW recognized it was required for COB types at the QA1 level based on the configuration of this application.

41 Let us assume all the testing at the QA1 level has been successfully completed and you are ready to promote to the STG level. Select all the tasks as before, right-click and click Promote. ISPW automatically creates a set container. The ISPW set processor will: Perform the promotions of all the source and parts to STG. Cleanup the QA1 level (source and parts if applicable). As the tasks in the set are being processed you can monitor the progress by clicking the refresh button if necessary. Click OK.

42 In the screenshot below a final refresh has been done showing that: The promotion has completed. All the tasks have successfully been promoted to STG.

43 Assuming all the testing at the STG level has been successfully completed, you are now ready to promote the tasks to the PRD level. Select all the tasks as before, right click and click Promote. Note: ISPW uses your installation s security (RACF/Top-secret/ACF2) to manage process security (granular control of permissions by user and function). Process security defines who can perform which commands at which levels in the life-cycle. While a developer defined to this application can perhaps request the promote operation when promoting to the STG1 and QA levels, perhaps a change coordinator role is responsible for requesting the promotion to PRD. One or more approvals can be put in place for each application/level promotion, including but not limited to application manager, QA manager, impact, DBA, job scheduling, peer, or VP roles.

44 The selected tasks are being placed in a set container for the promotion. The ISPW set processor will: Perform the promotions of all the source and parts to the PRD level. Cleanup the STG level source and parts as applicable. The application has been configured to require an approval for the promotion to PRD. In the screenshot below, the Status Column shows the tasks are locked in a set for a promote process but the set needs approval before the promote can proceed. The Approval can be performed from: Topaz/ISPW. TSO/ISPW. Web browser. Mobile browser. For this test drive you will do the approval from Topaz/ISPW. Click OK.

45 Click on one of the tasks, then right-click on the STG box in the life-cycle diagram. Click APPROVE to approve the set promotion. The primary ISPW started task will now start a set processor to perform the promotion of the tasks collected in the set to the PRD level.

46 Click the refresh button (as indicated in the screenshot) You can see in the updated screenshot below that: Set processing has begun. The tasks are being processed for a promotion to the PRD level. The promotion to the PRD level has completed. The source and parts for all 5 tasks were moved to the PRD level life-cycle libraries and the STG level libraries were cleaned up as appropriate.

47 As a Developer you are now finished with your assignment, so it can be closed. Assignments are to be closed manually and are usually closed to unclutter the ISPW containers view. To close the assignment, first close the ISPW tasks view. To Close your assignment, right-click on your assignment and click Close.

48 The Modify Assignment dialog is presented. Click OK to complete the close. Closed assignments, sets and releases are never deleted from ISPW. They are just filtered out of the standard day-to-day filtering. Once an assignment, set or release is closed it is removed from the standard filtered list, but it is still part of ISPW history and can be viewed at any time.

49 You are done your job has been to change 2 COBOL copybooks. As a part of this exercise, you have been able to use Compuware ISPW within Topaz Workbench to execute a workflow: Created an assignment. Added and checked out the two copybooks. Changed them using SlickEdit. Ran an impact analysis to determine the components impacted by your change. Added and checked out the impacted components. Generated (compiled) the program components. Viewed your generated output. Viewed the listings from the generate. Viewed the parts created as part of the generate. Promoted 5 tasks from DEV1 to QA1 with generates of the programs performed by ISPW in the correct order. Promoted 5 tasks from QA1 to STG. Promoted 5 tasks from STG to PRD. Approved your assignment. Closed your assignment to complete the change cycle. Congratulations! This completes the ISPW tutorial for Compuware Test Drive. NEXT STEPS Take a deep dive into other Topaz functionality if you haven t already. Pick your next tutorial: File and Data Management Code Analysis and Debugging Automated Unit Testing