Presentation is loading. Please wait.

Presentation is loading. Please wait.

© 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential 1 Module 8: I2R Change Control 1.1 Gatekeeper Audit April 2007.

Similar presentations


Presentation on theme: "© 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential 1 Module 8: I2R Change Control 1.1 Gatekeeper Audit April 2007."— Presentation transcript:

1

2 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential 1 Module 8: I2R Change Control 1.1 Gatekeeper Audit April 2007

3 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Change Control Training Agenda This training will cover nine short modules on the New Change Control Process: 1Training Introduction and Change Request Types 2Risk Assessment 3Quality Assurance 4SOX Assessment 5Architecture Review Board 6Change Control Board 7Release Management Office 8Gatekeeper Audit 9Merging with the New Process and Support Info

4 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Program Change Control Objectives The Program Change Control (PCC) audit process helps mitigate the following risks that can affect the quality, performance, or integrity of Cisco’s systems:  Unauthorized changes are promoted to production  Untested software is promoted to production By the end of this module, you will learn about:  Program Change Control (PCC)  SOX Testing Requirements  Gatekeeper Role and Responsibility  Gatekeeper Cheat Sheet: What a Gatekeeper looks for  Gatekeeper Engagement Process

5 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Program Change Control Risk Management The following controls were implemented to mitigate risks: ControlDescriptions (Prior to Production Deployments) Requests Documented Obtain documented requests for program changes Change ApprovalObtain documented business/change control approval Test/Prod Environments Make (develop and test) changes in development/test/staging environments TestingTest and validate changes Test and Migration Approval Obtain business/change control approval after testing completion for production migration

6 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Classifications of Change Types All change requests for information systems must be classified into change types. In addition, the association of change requests with change types is mandatory for all I2R system components to:  Enable consistent and objective identification of appropriate tests and test documentation for each change request  Enable consistent testing and test documentation for information system changes based on change type REQUESTS Change Types

7 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Change Types Each change request must be classified into one of the following change types:  Aesthetic Application User Interface GUI change Aesthetic Application User Interface GUI change  Application Code Changes Application Code Changes  System Configurations and Setups System Configurations and Setups  Business Configurations and Setups Business Configurations and Setups  Other Technical System Level and Performance Change Other Technical System Level and Performance Change  Data Changes Data Changes  Application Changes That Impact Interface Application Changes That Impact Interface

8 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Classification of Test Level All change requests and their associated testing must be categorized into defined test level. In addition, association of change requests with test level is mandated for all I2R system components to:  Provide external auditors with consistent test documentation  Ensure that each information system is testing similar changes in a similar fashion throughout Cisco

9 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Classifications for Test Level Each change request requires a minimum test level:  Validation Testing Validation Testing  IT Acceptance Testing IT Acceptance Testing  Business Acceptance Testing Business Acceptance Testing Validation Testing IT Acceptance Business Acceptance

10 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Minimum Level of Testing Matrix The below matrix shows the test level that your change type requires: Lowest LevelHighest Level For example… if your change request is classified as an “Application Code Change”, you are required to perform “Business Acceptance Testing”. Your test documentation and tester must adhere to guidelines defined for “Business Acceptance Testing”.

11 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Gatekeeper Role and Responsibilities The Gatekeeper serves as an internal auditor to ensure that I2R IT complies to and passes external audits. Gatekeeper’s responsibilities include:  Accountability for ensuring changes migrated to production environment adhere to PCC compliance requirements  Enforcing controls to ensure that unauthorized and untested changes do not get into production  Providing Kintana approval to authorize push of code to production

12 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Not Role and Responsibilities of the Gatekeeper Below are not roles and responsibilities of a gatekeeper:  Recommending scenarios and test cases for your change request  Preventing defects for your change request  Authorizing production implementation and deployments unless CCB has provided production approval Exception: Active emergency P1/P2 alliance cases  Chasing after you to provide Kintana approval

13 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Gatekeeper Cheat Sheet Before approving a change request for production, the Gatekeeper must verify that all necessary compliance items are checked off the list: One PCC ITG Request is appropriately created with all relevant details complete Change description in One PCC ITG request is understandable to third parties Quality Center Requirement is associated with One PCC ITG request and completed test documentation is available Test documentation adheres to level of test requirements based on the change request’s change type Test executioner in Quality Center is appropriate according to the level of test requirement One PCC ITG Request number and associated Kintana package are found in scope document or build listassociated Kintana package The individual that implemented the change (creator/developer of Kintana package) is not the same as the individual that tested the change (tester in Quality Center) Valid and approved One PCC ITG request number is referenced in the Kintana package Evidence of business delegation and sign-off for IT to perform testing on behalf of the business is attached to One PCC ITG request or updated in the request notes Justification and business sign-off as to why code with failed test steps or failed test cases should still be deployed to production is attached to One PCC ITG request or updated in the request notes

14 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential One PCC and Application Configurations There must be evidence of approval for application configuration work to proceed. The change requester must ensure that Change Control Board (CCB) production approval is obtained for application configuration deployment requests.  If the application configuration work is part of a project request or tactical request, make sure that application configuration QC Defect Issue number references a parent One PCC ITG request number  The parent change request must have created a One PCC ITG request and pass PCC audits. Else, the dependent application configuration request cannot be deployed to production  Approved parent One PCC ITG request will be used for deployment of the dependent application configuration setup

15 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential One PCC and Cross Functional Patches The CA-IT patch lead is only required to create One PCC ITG Request for all patches going into a planned release. The Functional Track is responsible for:  Ensuring that the Gatekeeper has been given the QA sign-off evidence that the patching has resolved issues, enhanced functionality, or did not break existing functionality  Attaching evidence in One PCC ITG request or updating the request notes  Associating Quality Center Requirement with One PCC ITG request and providing completed test documentation QA

16 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential How to Request a Gatekeeper Audit To request a gatekeeper audit, the change requester must follow these steps:  Upon completion of the last test cycle, send an to For details to include in the , see detailed gatekeeper audit info gatekeeper audit info  See standard release exception production approval cut-off time or non-standard release exception production approval cut-off time for Gatekeeper review and approval turnaround expectationsstandard release exception production approval cut-off timenon-standard release exception production approval cut-off time  During Release planning and scope identification, the Release Manager schedules a meeting with the Gatekeepers

17 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Planned Release Production Approval Flow

18 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Release Exception Production Approval Flow

19 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Emergency Bug Fix Production Approval Flow

20 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Quarterly vs. Monthly Release Test Cycles Quarterly and Monthly releases have different test cycles. To ensure that a change request is included in a release, the following must be confirmed:  Quarterly Releases – Release Manager must end the last test cycle weeks before the Readiness Review  Monthly Releases – Release Manager must end the last test cycle 1 week before the go-live date  The change requester is responsible for ensuring that all cut-off times are met  The change requester must adhere to Gatekeeper engagement procedures  If the change request misses the intended deployment window, the change requestor must re-seek CCB approval for deployment in another deployment window Notes If you do not adhere to the Gatekeeper engagement procedure, your request will not be deployed to production

21 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Emergency Bug Fix Deployment Since Emergency Bug Fix (EBF) often requires immediate deployment without adequate time to go through the regular approval cycle, it has slightly different requirements outlined below:  EBF deployment is only available for active P1/P2 alliance case  Requires Gatekeeper approval based on verbal certification  Requires post deployment Change Control Board (CCB) review of the change request  Requires post deployment CCB approval documented in change request notes  Requires change requester to provide Gatekeeper with completed PCC template and relevant test case documentation (in Quality Center) no later than 24 hours after the change was deployed into production

22 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential PCC Download and Upload Directories for EBF  For an EBF, download PCC template: https://ework.cisco.com/Livelink/livelink.exe?func=ll&objId= &objAction=Open  Remember to follow instructions in PCC template to… Adhere to file naming conventions Link completed PCC template to the One PCC ITG request number  Completed PCC documents can be uploaded to:

23 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Module 8: Quiz 1. A Gatekeeper does not do what? A. Serves as an internal auditor B. Prevents defects C. Recommends test cases and test case scenarios D. Verifies that implementer of the change is not the same as the tester for the change 2. What is the total number of Gatekeeper engagement processes? A. 1 B. 2 C. 3 D. 4

24 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Module 8: Quiz Cont. 3. Evidence of testing should not look like what? A. Only state an approval of testing completion B. Provide who, what, when, how in the test case C. Show test case with results recorded D. Show failed test steps/cases without justification for code push 4.What is the minimum level of testing required by SOX for System Configuration and Setup change type? A. Validation Testing B. IT Acceptance Testing C. Business Acceptance Testing D. Validating Testing and Business Acceptance Testing

25 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Gatekeeper Audit Summary As we conclude this module, we hope that you have a thorough understanding of the following three key points:  The purpose of the Program Change Control (PCC) process is to audit and ensure that unauthorized and untested software are not put into production  The Gatekeeper does not recommend testing scenarios for your change request or prevent defects. However, the Gatekeeper might indirectly reduce the chances of defects because of Project Change Control (PCC) audits  If you do not adhere to the Gatekeeper engagement procedure, your request will not be deployed to production

26 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential 25 Backup Slides Gatekeeper Audit

27 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Creation of a Request 3. Fill in all required information denoted by a red asterisk 1. Select the Request option under the create menu 2. Select the request type from the drop down menu

28 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Associating a Test Case to a Requirement  Test cases need to be associated to their corresponding requirement so that testing information will flow to ITG and be visible for approvals  The test cases must be associated to the systematically generated requirement in order to be associated to the correct request in ITG. Testing Information ITG Request

29 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Associating a Test Case to a Requirement  On the Reqs Coverage tab  Once you select the Reqs Coverage button the Requirements tree will appear on the right side of the screen Click on the Select Reqs button

30 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Associating a Test Case to a Requirement 1. Highlight the systematically generated requirement that the test case needs to be associated to 2. Click the Green Arrow to associate the Requirement

31 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Associating a Kintana Package to an ITG Request  To associate a Kintana Package to the corresponding One PCC ITG request, the One PCC Request ID field located on the User Data tab of the Kintana package must be populated with the One PCC ITG request number  Prior to the package’s deployment into a test environment, the Kintana workflow will automatically perform the validation to ensure that the package’s associated One PCC ITG request has been initially approved by CA CCB  Prior to the package’s deployment into production, the Kintana workflow will automatically perform the validation to ensure the One PCC ITG request has been finally approved by CA CCB

32 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Associating a Kintana Package to an ITG Request In the One PCC ITG Request ID field on the User Data tab of the Kintana Package click the Table Icon to display all the One PCC ITG requests that the Kintana Package can be associated to. The pick list shows all ITG requests that have been approved and are not in a closed status In the One PCC ITG Request ID field on the User Data tab of the Kintana Package click the Table Icon to display all the One PCC ITG requests that the Kintana Package can be associated to. The pick list shows all ITG requests that have been approved and are not in a closed status

33 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Control Description / RequirementExample Evidence UPDATE/PATCH POLICY: Regular and critical patch/code updates from outside vendors are reviewed per the update/patch policy and implemented per the program change control process  Documented vendor patch/software update process  All vendor supplied patch/software patches adhere to program change control deployment processes PCC Control # 1

34 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Control Description / RequirementExample Evidence APPROVAL OF THE CHANGE:  A change request must be reviewed and approved by the appropriate owner or managerial representative before the request can be worked on.  Appropriate segregation of duties exists. The individual who submits/owns that change request cannot approve the commencement of work on that change request.  Change request approval must be documented and retained in a centralized repository. Auditors must be able to easily trace change requests back to approvals.  A list of approved approvers for change requests must be maintained and archived.  Change approval must also state the minimal level of testing required based on the nature of the change to implement. The change request submitter/owner must ensure that testing for the request is compliant to the stated minimal level of testing requirements. Please see minimal level of testing section of details. An approved approver or representative of a change control board updates the change request’s case notes with the following:  “Approved”  Approver user ID or name  Approval date PCC Control # 2 Back to slide #4: PCC Risk ManagementPCC Risk Management

35 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Control Description / RequirementExample Evidence USER APPROVAL OF TESTING AND MIGRATION OF CODE: If business validation or acceptance testing is required for the change request, then the appropriate business sign-off is required to certify the test results.  Executed test cases with clearly documented test results  If business validation or acceptance testing is required, test cases show that a business user performed successful testing  If IT documented or performed testing on behalf of the business, appropriate business sign-off for testing has been updated in the One PCC ITG request notes by an appropriate business user  If IT documented or performed testing on behalf of the business, appropriate business sign-off for testing is attached to the associated One PCC ITG Request (i.e. pdf or html copy of evidence) PCC Control # 3 Back to slide #4: PCC Risk ManagementPCC Risk Management

36 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Control Description / RequirementExample Evidence FINAL APPROVAL FOR PRODUCTION DEPLOYMENT:  Final change request approval for code push to production is given by an approved approver  A list of approved approvers for change requests must be maintained and archived  Final approver in Kintana code migration workflow must be an approved Gatekeeper (known as IT Manager/ QA Reviewer in the tool) The following scenarios are NOT allowed under SOX segregation of duties rules: A = Person A, B = Person B Developer Tester Final Approver A A B A B A B A A An approved approver or representative of a change control board updates the change request’s case notes with the following:  “Approved”  Approver user ID or name  Approval date Final Push to Production approval step in Kintana workflow was performed by an approved Gatekeeper (known as IT Manager/ QA Reviewer in Kintana) PCC Control # 4 Back to slide #4: PCC Risk ManagementPCC Risk Management

37 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Control Description / RequirementExample Evidence SEPARATE TEST AND PRODUCTION ENVIRONMENTS: Testing and production occurs on separate databases / servers / technical environments For an audit, use EMAN tools and/or DBA Oracle 11i website to show proof that test and production environments are separate PCC Control # 5 Back to slide #4: PCC Risk ManagementPCC Risk Management

38 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential DescriptionExamples Changes to the appearance of the application. This does not include changes to business logic to enable appearance changes to the application.  Changes to ensure proper fields and buttons available  Changes to ensure user interface pick lists are correct  Changes to ensure default values are correctly populated  Changes to text content on a website Change Type - Aesthetic Application User Interface GUI Change Back to slide #6: Change TypesChange Types

39 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential DescriptionExamples Changes to application code that can impact business logic/rules/functionality, values, calculations, decision paths, or transactions.  Change to interactive and batch processes  Changes to the database  Changes to database triggers and stored procedures  Alterations/additions to schemas, tables, views, privileges  Includes changes to reports  Includes major database upgrades or patches that can impact business logic or data Change Type - Application Code Changes Back to slide #6: Change TypesChange Types

40 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential DescriptionExamples Configuration changes and/or setup changes that do not impact business logic and/or functionality  Changes to Oracle job scheduling Change Type - System Configurations and Setups Back to slide #6: Change TypesChange Types

41 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential DescriptionExamples Changes that only require configurations and/or setup changes. These changes can have potential impacts to business logic and/or functionality. However, these requests require no code changes.  Changes to an approval step in a workflow Change Type - Business Configurations and Setups Back to slide #6: Change TypesChange Types

42 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential DescriptionExamples Technical changes to an application that do not impact business logic or functionality  Changes to database table space  Changes to application, operating system, or database memory allocation  Changes to database indexes Change Type - Other Technical System Level and Performance Changes Back to slide #6: Change TypesChange Types

43 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential DescriptionExamples Data fix that adds/updates/deletes information from database tables that cannot be accommodated by the SCM-PDF workflow due to magnitude of the change. This data change can be associated with a release data migration or it can be as part of a production data fix.  Updates to a descriptive flex field associated with a large number of customer records  Insert large number of records into a database table  Purge large number of records from an interface staging table Change Type - Data Changes Back to slide #6: Change TypesChange Types

44 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential DescriptionExamples Changes to application code that impacts data exchange between the application and other applications or systems  Code change to interface that affects the logic to bring MFG Standard Cost from ODS to CTSPRD  Code change to interface to filter out ODS bad data from prices that need to be pulled into CTSPRD Change Type - Application Changes That Impact Interface Back to slide #6: Change TypesChange Types

45 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Description Example of Change That Could be Tested This Way Test Documentation Required Data Elements  Testing performed by the business or IT where the change can be verified by visual inspection.  This type of testing occurs when the change does not require validation of business logic or transactions. Aesthetic user interface change  Date of validation  Name of person who performed validation  Description of performed validation steps Test Level – Validation Testing Back to slide #8: Classifications for Test LevelClassifications for Test Level

46 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Description Example of Change That Could be Tested This Way Test Documentation Required Data Elements  Testing performed and documented by technical resources.  This type of testing checks the quality of system-related changes to the application with no risk to business logic or application controls. Performance test due to index changes  Date of test  Name of tester  Test description  Test steps  Expected results for each test step  Actual results for each test step  Pass/Fail for each test step Test Level – IT Acceptance Testing Back to slide #8: Classifications for Test LevelClassifications for Test Level

47 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Description Example of Change That Could be Tested This Way Test Documentation Required Data Elements  Testing performed and documented by application users to validate business transactions are appropriately processed.  This type of testing checks the quality of changes to business logic or functionality by using business test conditions or scenarios. Changes to reports, calculations, approval routing, logic within application code  Date of test  Name of tester  Test description  Test steps  Expected results for each test step  Actual results for each test step  Pass/Fail for each test step Test Level – Business Acceptance Testing Back to slide #8: Classifications for Test LevelClassifications for Test Level

48 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Detailed Gatekeeper Audit Info To request a gatekeeper audit, the change requestor can send an to with the information Subject :  Release Exception Audit for Go-Live or  Release Audit for Body:  One PCC ITG Request number  Contact person for One PCC ITG request (for e.g. IT PM)  Intended go-live date Back to slide #16: How to Request a Gatekeeper AuditHow to Request a Gatekeeper Audit

49 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Kintana package description must be named as follows: + Release + + December 2007 Release - This is a description of my package Release Exception - This is a description of my package In the User Data area for the Kintana package, the developer must reference One PCC ITG Request number in One PCC Request ID field Referencing Change Request to Kintana Package Back to slide #12: Gatekeeper Cheat SheetGatekeeper Cheat Sheet

50 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential ActivityResponsible Party Cutoff Time Complete testing in STAGE/TEST environment and request PCC audit Project ManagerWednesday, 11AM PST Complete PCC audit, inform Change Requestor of audit resultsGatekeeper/ QC Manager Wednesday, 5PM PST Obtain CCB approval for deployment to productionProject ManagerThursday, 2PM PST Add approved change request number and associated Kintana package(s) to production deployment scope document- send document to SCM Build Team, SCM Operations, Gatekeeper, C3-Support alias CCB CoordinatorThursday, 3PM PST Have C3 downtime packages ready in Kintana for Gatekeeper approval DeveloperFriday, 10AM PST Provide Kintana migration approvals for C3 downtime packagesGatekeeperFriday, 11:30AM PST Have C3 non-downtime or non-C3 packages ready in Kintana for Gatekeeper approval DeveloperFriday, 3PM PST Provide Kintana migration approvals for C3 non-downtime and non-C3 packages GatekeeperFriday, 4:30PM PST Record Gatekeeper comments and decisions into production deployment scope document- archive document GatekeeperFriday, 5:00PM PST SCM migrates package(s) to productionSCM Friday, 6PM - 8PM PST Saturday, 12AM - 4AM PST (C3 down) Release Exception – Standard Production Approval Cutoff Time Back to slide #16: How to Request a Gatekeeper AuditHow to Request a Gatekeeper Audit

51 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential ActivityResponsible PartyCutoff Time Complete testing in STAGE/TEST environment and request PCC audit Project Manager11 AM PST, 2 days prior to intended deployment window Complete PCC audit, inform Change Requestor of audit resultsGatekeeper5PM PST, same day review request received Obtain CCB approval for deployment to productionProject Manager2PM PST, 1 day prior to intended deployment window Add approved change request number and associated Kintana package(s) to production deployment scope document- send document to SCM Operations, Gatekeeper, C3-Support alias CCB Coordinator3PM PST, 1 day prior to intended deployment window Have evening packages ready in Kintana for Gatekeeper approvalDeveloper2PM PST, on intended deployment day Provide Kintana migration approvals for evening window packagesGatekeeper4:30PM PST, on intended deployment day Record Gatekeeper comments and decisions into production deployment scope document- archive document Gatekeeper5:00PM PST, on intended deployment day SCM migrates package(s) to productionSCM6PM - 8PM PST Release Exception – Non-Standard Production Approval Cutoff Time Back to slide #16: How to Request a Gatekeeper AuditHow to Request a Gatekeeper Audit

52 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential CCB Coordinator downloads blank gatekeeper log: https://ework.cisco.com/Livelink/livelink.exe?func=ll&objId= &objAction=Open 2.CCB Coordinator adds approved production deployment change requests to the the gatekeeper log. Use the completed One PCC ITG Request (referenced in the change request) as input for the gatekeeper log. 3.CCB Coordinator renames completed gatekeeper log as follows: I2R_ScopeDoc_.xls Example: I2R_ScopeDoc_10FEB06_11FEB06.xls 4.CCB Coordinator uploads completed gatekeeper log to the following directory: https://ework.cisco.com/Livelink/livelink.exe?func=ll&objId= &objAction=browse&sort= name 5.CCB Coordinator notifies SCM, Gatekeepers, and CACO Support of intended deployment scope Gatekeeper Log Instruction for CCB

53 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential Release Manager/Transition Manager downloads blank build list template: https://ework.cisco.com/Livelink/livelink.exe?func=ll&objId= &objAction=Open 2.Release Manager/Transition Manager adds only CCB approved production deployment change requests to the the build list. 3.Release Manager/Transition Manager renames completed build list as follows: I2R_ _PRD_Build_List_.xls Example: I2R_MAY2006_PRD_Build_List_Downtime.xls I2R_MAY2006_PRD_Build_List_Non-Downtime.xls 4.Release Manager/Transition Manager uploads build list to the Release’s transition directory: https://ework.cisco.com/Livelink/livelink.exe?func=ll&objId= &objAction=browse&sort= name 5.Gatekeeper updates build list with audit results 6.Release Manager/Transition Manager s final build list to SCM Build List Instructions for RMO

54 © 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential


Download ppt "© 2006 Cisco Systems, Inc. All rights reserved.Cisco Confidential 1 Module 8: I2R Change Control 1.1 Gatekeeper Audit April 2007."

Similar presentations


Ads by Google