PEPSI R2-Rollout and Back Out Plan - V1 2 - AD - HOC - LATAM - 4

Release and Deployment Management
Rollout/Backout Plan
[Select Value]
NEW
IN REVIEW
APPROVED
Project Name
Rollout / Backout Plan
Version 1.0
Document Filename:
Document Status:
Distribution List:
Document History:
Version Date Author(s) Summary
1.0 8/11/2014 Initial Version
1.1 8/18/2014 add pre-impl step
Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 1 of 48

How to use this template
This document is a template of a Release Rollout/Backout Plan document and is to be completed by the person responsible for delivering the release (Release
Manager). This template includes instructions to the author, boilerplate text, and may include sample text that should be replaced with text specific to the
release covered by this document.
Italicized text provides instructions to the document author, or describes the intent, assumptions, and context for content included in this document.
Text enclosed in square brackets ([text]) indicates a field that should be replaced with information specific to a particular release.
Boilerplate text may be used as is or modified as appropriate for a specific release. Empty text boxes outlined in grey are provided where text specific to the
release is required. The empty text boxes may be followed by a solid grey box that provides sample text content. These are offered only as suggestions to
assist in developing the plan content; they do not contain mandatory text.
No sections may be removed from this document, but additional sections may be added as appropriate. For instance, if there are implementation activities
occurring at multiple sites, it may be beneficial to have separate Rollout Schedule and Contact tabs for each distinct site included in this workbook. The
document header and footer information should not be modified.
When using this template for your release document, it is recommended that you follow these steps:
1. Replace all text enclosed in square brackets (including the brackets) (i.e., [Release Name]) with the correct field values. These brackets appear in
both the title page and body of the document.
2. Modify the boilerplate text as appropriate to the specific release.
3. Enter required text specific to the release in the empty text boxes and delete the solid grey boxes containing sample text.
4. To add any new sections to the document, ensure that the appropriate header and body text styles are maintained.
5. Before submission of the first draft of this document for the release, delete this How to use this template page.

1.0 Rollout Plan Purpose

This document describes the process for releasing the product/service into the live environment. This plan should be t
Test (UAT) process.
2.0 Release Rollout Contacts

Provide the points of contact responsible for supporting the release rollout activities. Include the escalation point for e
of the release.
Contact Primary Contact #

Team Contact Name Point Role Type

nt. This plan should be tested as part of the Release Acceptance phase that runs concurrently with the User Acceptance
he escalation point for each resource. Confirm the availability and role responsibilities from these resources in advance
Primary Contact # Secondary Contact # Support Schedule

Number Type Number Location Dates Times Escalation Contact

What information should a good rollout schedule contain?
At a minimum, a good rollout schedule should contain the following:
Pre-implementation, implementation, and post-implementation steps.

All steps should have projected start dates/times, assigned owners, and expected duration.
Steps should be described at a level of detail that someone could logically step through the document and understand specifically what is happening and
when.

Deployment instructions/specifications may be in a separate document, but that document should be linked to the rollout plan in the Notes/Links column.
The level of detail that should be specified includes but is not limited to: module names, version numbers, file names, script names, database names, server
names/addresses, source code repository locations, etc.
Post-implementation steps should include the steps required to validate the success of the implementation. If smoke tests are going to be run, a link to the
test cases should be provided in the Notes/Links column.
The person assigned to execute the implementation should not be the same person verifying the implementation.
Communication steps should be included in your schedule, including distribution lists as appropriate.

3.0 Pre-Implementation Activities Schedule

Provide the schedule of activities to be accomplished to prepare for the delivery of the produc
Archive, Storage, and Purge: Activities to back up, store, and/or purge data.
Data Conversion and Migration: Activities to back up, convert, create, cut over, and/or m
System Operations: Third-party software and hardware installation tasks, network, infra
External Dependencies: Tasks that need to be completed by external resources, vendor
User Operations: Tasks to turn over user procedures and documentation for the system
Planned Start Planned End

Task # Date Time Date Time
1 08/01/14 9.00AM CDT 08/04/14 8:30 AM CDT
2 08/01/14 9.00AM CDT 08/04/14 6.00PM CDT
3A
08/15/14 08/18/14 10:00 AM CDT
3B
08/15/14 9.00AM CDT 08/22/14 1:00PM CDT
3C
08/18/14 9.00AM CDT 08/22/14 1:00PM CDT
4 08/15/14 9.00AM CDT 08/18/14 11:00AM CDT
5 08/15/14 9.00AM CDT 08/22/14 11:00AM CDT
6
08/15/14 3:00 PM CDT 08/18/14 6:00 PM CDT
7
08/15/14 6:00 PM CDT 08/18/14 1:00 PM CDT
8 08/04/14 9.00AM CDT 08/21/14 10.00AM CDT
9 08/15/14 2:00 AM CDT 08/22/14 12:00PM CDT

10 08/15/14 10:30 PM CDT 08/22/14 5:00 AM CDT
10A 08/19/14 10:30 PM CDT 08/22/14 5:00 AM CDT
11
08/15/14 9.00AM CDT 08/22/14 1:00 PM CDT
12
08/15/14 9.00AM CDT 08/22/14 1:00 PM CDT
13 08/15/14 4:30 AM CDT 08/22/14 1:00 PM CDT
14 08/15/14 4:30 AM CDT 08/22/14 1:00 PM CDT
15
08/15/14 12:00 PM CDT 08/19/14 8:00PM CDT
16
08/15/14 10:00 AM CDT 08/22/14 1:00 PM CDT
17 08/15/14 2:00 PM CDT 08/22/14 1:00 PM CDT
18 08/15/14 4:30 AM CDT 08/22/14 1:00 PM CDT
19 08/15/14 10.00AM CDT 08/22/14 1:00 PM CDT
20 08/15/14 10.00AM CDT 08/22/14 1:00 PM CDT
21
08/15/14 10.00AM CDT 08/15/14 11:00 AM CDT
22 08/05/14 10.00AM CDT 08/15/14 10.00AM CDT
23 08/05/14 10.00AM CDT 08/15/14 11.00AM CDT
24 08/05/14 10.00AM CDT 08/15/14 12.00PM CDT
25 08/15/14 10.00AM CDT 08/19/14 1.30PM CDT
26 08/15/14 1.30PM CDT 08/18/14 3.00PM CDT
27 08/15/14 9.00AM CDT 08/18/14 6.00PM CDT
28 08/15/14 9.00AM CDT 08/18/14 6.00PM CDT
29 08/15/14 12.00PM CDT 08/22/14 1:00 PM CDT
30 08/15/14 9.00AM CDT 08/18/14 11.00AM CDT

31 07/09/14 12.30PM CDT 07/31/14 1.00PM CDT
32 08/04/14 8:00 AM 08/07/14 8:00 AM CDT
33 08/04/14 12:00 PM CDT 08/15/14 5.00 PM CDT
34 08/15/14 12:00 PM CDT 08/18/14 5.00 PM CDT
35 08/04/14 12:00 PM CDT 08/08/14 5.00 PM CDT
<insert pre-implementation steps above this line>

4.0 Implementation Activities Schedule

Provide the schedule of activities to be accomplished to deliver the product/service into the liv
Batch Scheduling: Identify the tasks and checkpoints to ensure changes to schedulers (
Communications: Identify the communication activities throughout the implementation.
appropriate.
System Operations: Third-party software and hardware installation tasks, network, infra
External Dependencies: Tasks that need to be completed by external resources, vendor
Archive and Storage: Activities to back up and/or store data at critical points in the rollo
Pilot/Ramp-up: Identify whether the implementation involves a pilot or production ramp

12:00 AM CDT
36 08/25/14 10:30 AM IST 08/25/14 1:00 AM
1:00 AM CDT
37
08/25/14 08/19/14 1:30 AM CDT
38 08/25/14 1:30 AM CDT 08/25/14 6:30 AM CDT
39 08/25/14 6:30 AM CDT 08/25/14 6:30 AM CDT
40 08/25/14 6:30 AM CDT 08/25/14 1:30 PM CDT
41 08/25/14 9:00 AM CDT 08/25/14 1:00 PM CDT

42 08/25/14 1:30 PM CDT 08/25/14 4:30 PM CDT
43 08/25/14 4:30 PM CDT 08/25/14 8:30 PM CDT
44 08/25/14 8:30 PM CDT 08/25/14 11:30 PM CDT

45 08/25/14 11:30 PM CDT 08/26/14 4:30 AM CDT
46 08/26/14 4:30 AM CDT 08/26/14 11:30 AM CDT
47 08/26/14 11:30 AM CDT 08/27/14 7:30 AM CDT
48 08/27/14 7:30 AM CDT 08/27/14 7:30 AM CDT

49 08/27/14 7:30 AM CDT 08/27/14 1:30 PM CDT
50 08/27/14 1:30 PM CDT 08/27/14 1:30 PM CDT

51 08/27/14 1:30 PM CDT 08/27/14 2:00 PM CDT
52 08/27/14 2:00 PM CDT 08/27/14 4:30 PM CDT
53 08/27/14 9:30 PM CDT 08/28/14 4:00 AM CDT
54 08/28/14 8.30 AM CDT 08/29/14 1.30 PM CDT

55 08/28/14 2.30 AM CDT 08/28/14 4.30 AM CDT
56 08/28/14 4.30 AM CDT 08/28/14 3:30 PM CDT
57 08/28/14 8.30 AM CDT 08/29/14 11.30 AM CDT
58 08/28/14 8.30 AM CDT 08/29/14 11.30 AM CDT
<insert implementation steps above this line>

5.0 Post-Implementation Activities Schedule

Provide the schedule of activities to be accomplished once the product/service has been delive
Verification and Validation: Tasks to ensure that the solution was implemented as expec
Communications: Identify the communication activities with operations and other key s
Archive, Storage, and Purge: Activities to back up, store, and/or purge data.
System Performance and Monitoring: Identify the tasks that need to be undertaken or m
defined in the NPI requirements process. If there are outstanding engagement items w
System Environment Updates: Activities required to synchronize all system environmen

57 08/28/14 09:00 AM CDT 08/28/14
58 08/22/14 08/22/14
<insert post-implementation steps above this line>

ities Schedule
e accomplished to prepare for the delivery of the product/service into the live environment. Make sure to include any activities requi
tivities to back up, store, and/or purge data.

Activities to back up, convert, create, cut over, and/or migrate data.
software and hardware installation tasks, network, infrastructure, and facilities-related tasks.
hat need to be completed by external resources, vendors, etc. prior to implementation.
over user procedures and documentation for the system and software.
Pred
Activity Description Task #
Create implementation plan
Create rollback plan
Identify the proper order of Project creation. And templates that need to be created. (Maybe bi-monthly?)
VERIFY Cleanup LATAM Template - 1)Canada LRB 444, 2) Canada Sav 444, 3) Columbia
SAV Bi-Monthly
Remove "#LOGIN_NAME# from warehouse SQL for all template projects.
Deny Browse in ACL on the I-Cube Report template

Delete the TERRITORY attrbiute from ORS
Create ticket to have script createdto correct objects (renaming the invalidated objects to overcome
POS utility treatment of MSTR metadata issues) (CD7421) DONE
Need to create a script to correct objects (renaming the invalidated objects to overcome POS
utility treatment of MSTR metadata issues) Milind is working a script
Get CAB approvalLATAM Canned + Ad Hoc
Smoke test by Dev team - Smoke test of cleaned LATAM project in task 3

Smoke test by QA team of cleaned LATAM project in task 3
QA approval for AMEA AD-Hoc
Copy the cleaned DEV DEV\PEP SAV LATAM Columbia Prod Template to PROD with name "PepsiCo
GTC R2 SAV LATAM Columbia Template"
Copy the cleaned DEV DEV\PEP LRB NA Canada Prod Template to PROD with name "PepsiCo GTC R2
LRB LATAM Canada Template"
Copy the cleaned DEV DEV\PEP SAV NA Canada Prod Template to PROD with name "PepsiCo GTC R2
Sav LATAM Canada Template"
Validate project config details for template projects, check catalog warehouse SQL, project config
setup for user access, cache setting
SetNielsenAnswersProjectType=LinkedProject
Link Project
Create and Validate new output spec in NISP Prod for 4 LATAM projects (have been created
for PROD in NISP PROD)
Before activating the new output specs send the list of new cubes to be activated list to Arul and Verify NISP
Dhamod - Created
Validate entries added for the new cubes from Arul / Dhamod
SetNielsenAnswersProjectType= CD3Project
Prod Metadata backup
Confirm we have all right templates in place migration
NISP cubes readiness for PEPSICO implementation

Validation of NISP Prod DB user account (CD3USER)
Assign READ access to LRB and Savoury production tables
Validate DB connection details for LRB and Savory
Confirm if CD3 prod can access the new cubes via CD3user
Valadtion of DNS for DB Instance for LRB and Savoury - Is there different DNS for R2
Provide the List of PepsiCo users who require access to CD3 platform
User Setups in OM
Pre-Implementation DCM task
Review of the implementation plan ( Dry-run)

Release readiness meeting
QA sign-off for Production deployment
Internal Users sign-off
Performance Testing Sign-off
UAT Approval

s Schedule
e accomplished to deliver the product/service into the live environment. Key activities to consider including in this section are:
asks and checkpoints to ensure changes to schedulers (automatic or manual) are implemented.
ommunication activities throughout the implementation. These should include key implementation team communications and check
software and hardware installation tasks, network, infrastructure, and facilities-related tasks.
hat need to be completed by external resources, vendors, etc. prior to implementation.
to back up and/or store data at critical points in the rollout in order to facilitate ease of backout or partial backout should it be neces
the implementation involves a pilot or production ramp-up period (warranty period), and the strategy to roll out to full production.
Pred
1) Start:SD to check Iserver run in cluster before we start project creation
2) Ensure no other activity is occuring in POS
(NISP) Modify NISP-PROD connector settings to point to the CD3-Prod environment

(NISP)Get DCD XML into the CD3 Prod by Registering the DCDs using the new production output specs
Stop: MAL before project creation
Create DCM Projects from DCM template. - Send landing page details to CD3-Support for LRB and Savoury
projects - Email from Sonam
"PEP SAV LATAM Brazil"
"PEP SAV LATAM Colombia"
"PEP LRB LATAM Candada"
"PEP SAV LATAM Canada"
Canned Reprots. Create Migration package in DEV ASM for base objects Documents and reports and dependent
objects to respective country projects to be migrated to PROD AD HOC. Create Migration package in DEV ASM
for base objects Documents and reports and dependent objects to respective country projects to be migrated to
PROD

Import UAT migration packages to PROD for each counrty
- Set up project level settings for ,

"PEP SAV AMEA China" "PEP LRB AMEA China"
"PEP SAV AMEA Egypt" "PEP LRB AMEA Egypt"
"PEP SAV AMEA India" "PEP LRB AMEA India "
"PEP LRB AMEA Saudi Arabia" "PEP SAV AMEA Saudi Arabia"
"PEP LRB AMEA Thailand"
"PEP LRB AMEA Vietnam"
"PEP LRB AMEA Philippines"
"PEP SAV LATAM Brazil"
"PEP SAV LATAM Colombia"
"PEP LRB LATAM Candada""PEP SAV LATAM Canada"
NISP Connections.
- Validate ACL for all objects and folders in both LRB and Savoury projects
- Send landing page details to CD3-Support for LRB and Savoury projects
- Update cache setting
- Enable stats
Verify Ad-hoc create option - User should only see Nielsen Template Report
Validate Table Prefix , Logical Tables and Custom Attributes
Clean up flagged objects by POS utility for PepsiCo GTC LRB, PepsiCo GTC Savoury
Smoke testing by Dev (Check that physical tables are created)

(OPTIONAL STEP) If any migration, copy folder level ACL's to the migrated objects
Clear cache from all the cluster iservers

Data Validation with AD and CD3 Reports (See notes regarding command scripts to remove special characters)
Not
(Optional Step): Re-migrate the changed objects. Required
- Upload Thumbnails/Images into CD3 production servers and apply to the Reports.
Enable Internal user access, via collaboration group - Spot Checks Internal Users
Smoke testing by QA
Smoke testing by internal users.

Provide access to group of external users for testing
Confirm external user groups operational
Pepsi Smoke Test - Internal
Provide access to the external users to the PepsiCo GTC LRB and PepsiCo GTC Savoury projects

vities Schedule
e accomplished once the product/service has been delivered into the live environment. Key activities to consider including in this sec
s to ensure that the solution was implemented as expected and is performing correctly. This verification should include downstream
ommunication activities with operations and other key stakeholders upon successful completion of the implementation and subsequ
tivities to back up, store, and/or purge data.

oring: Identify the tasks that need to be undertaken or monitored to prove that the installed system is operating as intended accordi
process. If there are outstanding engagement items with the HP Apps Monitoring team or DIRT approvals to be obtained, detail the
Activities required to synchronize all system environments with the new system and software - development, test, and training envir
Pred
Business user communication and Validation
Close CAB request

nvironment. Make sure to include any activities required to support execution of the backout plan as well, such as database backup
-related tasks.
entation.
Actual Complete
Owner(s) Date Time
08/04/14
08/04/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14 9:10 AM CDT

8/xx/2014

8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
08/15/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
08/15/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14

8/xx/14
08/06/14
08/06/14
8/xx/14
8/xx/14

tivities to consider including in this section are:

are implemented.
key implementation team communications and checkpoint calls, release status communication points, critical backout assessment p
-related tasks.
entation.
ease of backout or partial backout should it be necessary.
eriod), and the strategy to roll out to full production.
Actual Complete
Owner(s) Date Time
8/xx/14
8/xx/14
8/xx/14
8/xx/14

8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14

8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14
8/xx/14

onment. Key activities to consider including in this section are:
correctly. This verification should include downstream systems affected as well. The backout plan should provide instructions for wh
essful completion of the implementation and subsequent system validation.
the installed system is operating as intended according to planned performance. Reference the required benchmarks or throughpu
ring team or DIRT approvals to be obtained, detail them here.
m and software - development, test, and training environments.
Actual Complete
Owner(s) Date Time

out plan as well, such as database backups. Key activities to consider including in this section are:
Notes / Links Status
CD7421

Balamani, Dhamodharan (TCS Consultant) <Dhamodharan.Balamani.consultant@nielsen.com>; Bhoopathy,

Arulkumaran <Arulkumaran.Bhoopathy.ap@nielsen.com>
Feb 14 data is available 5/7/2014 and March 14 data will be available by 5/16/2014
User naming stds to be discussed with NISP. Create CCM Ticket
Validate with DBA group - Rajesh Sharma & Andy Johnson

Smoke Tesing team ( Dev and T&V) to be provided access.
Create CCM Ticket - No additional users for July
DCM checklist to be attached


ation points, critical backout assessment periods, and communication with operations and other key stakeholders as
Lingam to coordinate with NISP support team for NISP pointer

Please refer the document ' ' in the ___ Section

Report Time out
Max Row governing Limit
Project Level VLDB settings
Hosts to whitelist:
dayrhecdxp001.enterprisenet.org
dayrhecdxp002.enterprisenet.org
IPAD Landing Page
https://ishare.nielsen.com/teams/Port_Man2/PepsiCo/Glb_Vis/Workstreams/Technology/_Global%20Visibility%20-%20Phase
%201/R1%20Implementation%20Docs/PEP%20R1%20PROD-iPad%20Landing%20Page.png
https://ishare.nielsen.com/teams/Port_Man2/PepsiCo/Glb_Vis/Workstreams/Technology/_Global%20Visibility%20-%20Phase%201/R1%20Im
https://ishare.nielsen.com/teams/Port_Man2/PepsiCo/Glb_Vis/Workstreams/Technology/command%20scripts%20to%20remove%20special
Verify deployment and communicate to QA team for further testing

DEV: Patil, Milind S <Milind.S.Patil.ap@nielsen.com>; hemkumar, somala <somala.hemkumar.ap@nielsen.com>; Klauss, Mathis
<Mathis.Klauss@nielsen.com>; Bellamkonda, Vijay <Vijay.Bellamkonda.ap@nielsen.com>; Natarajan, Krithiga
<Krithiga.Natarajan.ap@nielsen.com>; <AnithaMeesala.Suryanarayana.ap@nielsen.com>; <Mathis.Klauss@nielsen.com>;
Ottenfeld, Timothy Lee <Timothy.Ottenfeld@nielsen.com>; Sonam.Gupta.ap@nielsen.com>;

https://ishare.nielsen.com/teams/Port_Man2/PepsiCo/Glb_Vis/Workstreams/Technology/command%20scripts%20to%20remove%20special
in
- Report, Adhoc, Contact Us, Quicklinks, Insights and User Access to be checked
QA: Horthur, Kishore <Kishore.Horthur.ap@nielsen.com>; Magalapalli, Prasanna <Prasanna.Magalapalli.ap@nielsen.com>;
Mohandoss, Harithadevi <Harithadevi.Mohandoss.ap@nielsen.com>; Murugan, Sundaravel
<Sundaravel.Murugan.ap@nielsen.com>; Nithiyanandan, Sasikala
UAT: Colyer, Jocelyn <Jocelyn.Colyer@nielsen.com>; Adair, Roy E <Roy.Adair@nielsen.com>; Roberts, Glenn
<Glenn.Roberts@nielsen.com>
Send notification to Jocelyn for user setup completion
James G to co-ordinate

out plan should provide instructions for what to do in the event that a verification step fails.
ce the required benchmarks or throughput levels that must be attained as documented in the performance requirements

6.0 Backout Plan Purpose

This document describes the contingency plan to be executed if problems occur during release deployment activities, or duri
plan should be tested as part of the Release Acceptance phase that runs concurrently with the User Acceptance Test (UAT) pr
7.0 Backout Assumptions and Constraints

Describe the backout strategy for the release. Include details such as:
Any assumptions that need to be stated about the process of the backout and/or the status of the mainframe and/or serv
Critical backout assessment periods in the rollout activities.
Time constraints on backout decisions, execution, and completion.
Highlight any release components that cannot be backed out.
The PepsiCO project is a new application, the backout will not impact existing user.
The PepsiCO project will be disabled by CD3 team in case of failures/errors, data integrity concerns or perfomance issues on
All components including MSTR project, database schema and new user Ids created can be easily deleted without impactin

8.0 Backout Decision Process

Describe how will the decision to backout the full release or particular components of the release will be made and communi
will be made and the authorization process that will be followed to invoke the backout plan for a No-go decision. Include who
notification, and method of communication.
Following are the scenarios where backout of the full release will be made:
- NISP/POS utility unable to create MSTR project
- If Ad-hoc reports and Canned Reports are not working
- Application causes severe performance impact to MSTR/CD3 platform or oracle database.
Backout of Particular Components will be made:

- If Ad-hoc reports are working but there are issues with canned reports
- If Canned reports are working but there are issues with ad-hoc reports
- Backout release for the drill paths that have issues or are having severe performance impact.
9.0 Backout Decision-Makers

Provide the points of contact responsible for making/authorizing release backout decisions. Confirm the availability and role
the release.
Contact Primary Contact #

Organization Area Contact Name Point Location Type Number

<insert contacts above this line>

uring release deployment activities, or during the post-implementation validation tasks. This
ntly with the User Acceptance Test (UAT) process.
or the status of the mainframe and/or server systems before or after the backout.
er.
integrity concerns or perfomance issues on either MSTR/CD3 platform or oracle database.
ted can be easily deleted without impacting any other applications.

of the release will be made and communicated. Describe at what point the Go/No-go decision
kout plan for a No-go decision. Include who will receive the notification, the timing of the
pact.
ecisions. Confirm the availability and role responsibilities from these resources in advance of
Secondary Contact # Decision-Making / Authorization

Type Number Responsibility


What information should a good backout schedule contain?
At a minimum, a good backout schedule should contain the following:
Description of different scenarios that may necessitate a backout of the change.

Backout steps should be detailed for each different scenario.
Persons that will decide whether to back out the change.
All steps should have projected start dates/times, assigned owners, and expected duration.
Steps should be described at a level of detail that someone could logically step through the document and understand specifically what is happening and
when.

Detail backout instructions/specifications may be in a separate document, but that document should be linked to the backout plan in the Notes/Links column.
The level of detail that should be specified includes but is not limited to: module names, version numbers, file names, script names, database names, server
names/addresses, source code repository locations, etc.

Steps should include validation of the backout. If smoke tests are going to be run, a link to the test cases should be provided in the Notes/Links column.
The person assigned to execute the backout should not be the same person verifying the success of the backout.
Communication steps should be included in your schedule, including distribution lists as appropriate.

10.0 Backout Scenarios

List the events that could occur during, or result from the release rollout activities and detected during the verification/val
components but not all) of the release. List the release components (software, permanent libraries, database changes, sc
response to the scenario, which option is most recommended, and who needs to authorize the backout response decided
ID Release
# Components Affected Backout Scenario Description
1.0 POS Project Creation POS Fails to create the project
2.0 Micro Strategy Project Reports (Canned and Ad hoc) are not woking as expected
3.0 System/Reports not Reports are not working even after re-migration
functioning even with re-
migration
4.0 MSTR/CD3 Platform or NISP Application causes severe performance impact to MSTR/CD3 platform or oracle database.
Database
5.0 Canned Reports If Ad-hoc reports are working but there are issues with canned reports
6.0 Ad-hoc Reports If canned reports are working but there are issues with ad-hoc reports
7.0 Drill paths If certain drill paths have issues or are having severe performance impact.
<insert scenarios above this line>

11.0 Release Backout Steps

Provide the sequence of activities to back out the entire release or particular portion(s) of the release. Include a section fo
including in this section are:
Verification and Validation: Tasks to ensure that the solution was backed out successfully and the system is once ag
Communications: Identify the communication activities with operations and other key stakeholders upon successfu

11.1 Scenario #1 POS Fails to create the project- Backout Steps

Expected Pred
Task # Duration (Hrs) Activity Description Task #
1 1.50 Disable users accessing application link for Web
2 1.50 Disable users accessing application link for iPad
3 0.50 Notify all the stakeholders with updates
4 Between 2 to 8 hrs Recreate the project using POS Utility
~4 to 12 hrs TOTAL ESTIMATED BACK-OUT TIME
<insert backout steps above previous line>
11.2 Scenario #2 Reports(Canned and Ad-Hoc) are not working as expected- Backout Steps
Expected Pred

g the verification/validation steps, that would necessitate a full backout or partial backout (backout of some release
database changes, scheduling requests, etc.) affected in each scenario. Detail the backout options to be considered in
out response decided upon.
Authorization
Backout Options Recommended Response Required By
Disable users accessing application link for Web and iPad, Re Create the project using POS utility POS/CD3 Service Delivery
send notification about further updates.
Remigrate the Reports Remigrate reports from External UAT CD3 Service Delivery
Disable users accessing application link for Web and iPad, POS/CD3 Service Delivery
send notification about further updates. unload MSTR
project from PROD
Disable/Remove MSTR project and re-create using POS.
Disable users accessing application link for Web and iPad, NISP DBA/CD3 Support
send notification about further updates. unload MSTR
project from PROD Work with NISP DBA team/CD3 Support Team to analyse
performance impact and tune accordingly.
Hide canned report links in the web application Remigrate canned reports from External UAT CD3 Service Delivery, CD3
BI Team
Hide Adhoc link in the web application Remigrate ad-hoc objects from External UAT CD3 Service Delivery, CD3
BI Team
Hide drill path links on web and ipad application CD3 Service Delivery, CD3
BI Team
Re-migrate drill paths

. Include a section for each backout scenario identified (by ID #) in the previous section. Key activities to consider
he system is once again performing correctly. This verification should include downstream systems affected as well.
ders upon successful completion of the backout and subsequent system validation.

Actual
Owner(s) Duration (Hrs) Notes / Links Status
Steps
Actual

12.0 Rollout/Backout Issues List

Track issues related to the pre-implementation, implementation execution (including deployment activities), and post-im
process. In addition to problems that may have occurred, also include items such as steps that were missing from the ro
included in future releases, etc.
Issue Opened Issue Closed

Issue # Date Time Status Date Time Issue Description Owner
<insert issues above this line>

loyment activities), and post-implementation activites in this log for future input into the project/release lessons learned
s that were missing from the rollout, deployment, or backout plans, additional communication points that should be
Owner Issue Impact Closure Notes

PEPSI R2-Rollout and Back Out Plan - V1 2 - AD - HOC - LATAM - 4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PEPSI R2-Rollout and Back Out Plan - V1 2 - AD - HOC - LATAM - 4

Uploaded by

Copyright:

Available Formats

Release and Deployment Management

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 1 of 48

How to use this template

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 2 of 48

1.0 Rollout Plan Purpose

2.0 Release Rollout Contacts

Contact Primary Contact #

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 3 of 48

Primary Contact # Secondary Contact # Support Schedule

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 4 of 48

What information should a good rollout schedule contain?

At a minimum, a good rollout schedule should contain the following:

Pre-implementation, implementation, and post-implementation steps.

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 5 of 48

3.0 Pre-Implementation Activities Schedule

Planned Start Planned End

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 6 of 48

08/15/14 9.00AM CDT 08/22/14 1:00 PM CDT

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 7 of 48

<insert pre-implementation steps above this line>

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 8 of 48

4.0 Implementation Activities Schedule

Planned Start Planned End

38 08/25/14 1:30 AM CDT 08/25/14 6:30 AM CDT

39 08/25/14 6:30 AM CDT 08/25/14 6:30 AM CDT

40 08/25/14 6:30 AM CDT 08/25/14 1:30 PM CDT

41 08/25/14 9:00 AM CDT 08/25/14 1:00 PM CDT

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 9 of 48

42 08/25/14 1:30 PM CDT 08/25/14 4:30 PM CDT

43 08/25/14 4:30 PM CDT 08/25/14 8:30 PM CDT

44 08/25/14 8:30 PM CDT 08/25/14 11:30 PM CDT

46 08/26/14 4:30 AM CDT 08/26/14 11:30 AM CDT

47 08/26/14 11:30 AM CDT 08/27/14 7:30 AM CDT

48 08/27/14 7:30 AM CDT 08/27/14 7:30 AM CDT

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 10 of 48

49 08/27/14 7:30 AM CDT 08/27/14 1:30 PM CDT

50 08/27/14 1:30 PM CDT 08/27/14 1:30 PM CDT

53 08/27/14 9:30 PM CDT 08/28/14 4:00 AM CDT

54 08/28/14 8.30 AM CDT 08/29/14 1.30 PM CDT

58 08/28/14 8.30 AM CDT 08/29/14 11.30 AM CDT

<insert implementation steps above this line>

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 11 of 48

5.0 Post-Implementation Activities Schedule

System Environment Updates: Activities required to synchronize all system environmen

Planned Start Planned End

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 12 of 48

tivities to back up, store, and/or purge data.

Remove "#LOGIN_NAME# from warehouse SQL for all template projects.

Deny Browse in ACL on the I-Cube Report template

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 13 of 48

NISP cubes readiness for PEPSICO implementation

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 14 of 48

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 15 of 48

2) Ensure no other activity is occuring in POS

(NISP) Modify NISP-PROD connector settings to point to the CD3-Prod environment

Stop: MAL before project creation

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 16 of 48

Import UAT migration packages to PROD for each counrty

- Set up project level settings for ,

Validate Table Prefix , Logical Tables and Custom Attributes

Smoke testing by Dev (Check that physical tables are created)

Version 2.0: 10/01/2012 RDM-02-RBP-01-00 page 17 of 48

Smoke testing by internal users.