Deployment Guide Specification - · Web viewMuch of this information is already documented in the Commerce Server Secure Deployment Guide and MSIB v2.1 prescriptive documentation

Revision HistoryDate Author Summary6/02/05 kevchen Doc created.6/03/05 kevchen Updated the Preliminary Schedule section.6/04/05 kevchen Added details for the Structural Overview section.6/05/05 kevchen Updated the Related Documents section.6/06/05 kevchen Grew the Intro and updated Dependencies and

Integration Points section.6/09/05 kevchen Updated the Functional Requirements section.6/10/05 kevchen Added the Technical Review, Editing Requirements,

and Production Requirements sections.6/11/05 kevchen Added section for Verifying Functionality in the

Structural Overview section based on feedback from Manish.

6/12/05 kevchen Added sample graphics to the Graphics Requirements section.

6/13/05 kevchen Added dates on the Preliminary Schedule based on

RSWAT Deployment DocumentationFunctional Requirements Specification: Deployment Guide

DeploymentDocSpec.docSpecification Owner -- Kevin Chen

Version 1.0

Project: eBusiness/Commerce

Last Saved: May 2, 2005

Status: Working

© Copyright 2005. All Rights Reserved

Note: This documentation is an early release of the final product documentation. It is meant to accompany software that is still in development. Some of the information in this documentation may be inaccurate or may not be an accurate representation of the functionality of the final retail product. Microsoft assumes no responsibility for any damages that might occur either directly or indirectly from these inaccuracies.

doc milestones that were added to the test plan.

Contents1 Introduction..............................................................................................................1

1.1 Overview and Background...............................................................................21.2 User Definition & Scenarios..............................................................................3

2 Objectives and Assumptions.....................................................................................42.1 Design Goals....................................................................................................42.2 Preliminary Schedule.......................................................................................4

3 Structural Overview..................................................................................................54 Related Documents..................................................................................................85 Dependencies and Integration Points.......................................................................8

5.1 Internal............................................................................................................85.2 External...........................................................................................................85.3 Compatibility Requirements.............................................................................8

6 Functional Requirements..........................................................................................106.1 Requirements Overview...................................................................................10

6.1.1 Prescriptive Guidance for Deploying the Production Environment........106.1.2 Prescriptive Guidance for Deploying the Site Administration Environment

116.1.3 Prescriptive Guidance for Deploying the Development Environment....116.1.4 Prescriptive Guidance for Packaging Site Assets..................................116.1.5 Prescriptive Guidance for Publishing Site Updates................................126.1.6 Prescriptive Guidance for Locking Down the Database Roles...............126.1.7 Prescriptive Guidance for Locking Down the Authorization Roles.........136.1.8 Conceptual Guidance for Design Goals.................................................136.1.9 Introductory Information.......................................................................146.1.10 Listing of Hardware and Software Requirements..................................146.1.11 Sample Deployment Diagrams.............................................................166.1.12 Prescriptive and Conceptual Guidance for Running Reports.................166.1.13 Prescriptive Guidance for Verifying Functionality..................................16

7 Technical Review......................................................................................................177.1 Primary Reviewers...........................................................................................17

8 Graphics Requirements............................................................................................178.1 Minimum Requirements...................................................................................18

9 Editing Requirements...............................................................................................2010 Production Requirements.........................................................................................2111 Open Issues..............................................................................................................21

Jupiter Functional Requirements Specification Draft Version 1. 5/8/2008 03:35:00 PM

1 IntroductionThis document provides details about the Secure Deployment Guide that is shipping with RSWAT, including key milestones, dependencies, requirements, and Deployment Guide structure.The Deployment Guide is largely based on the existing Commerce Server Secure Deployment Guide, but reorganizes the tasks such that they are categorized more logically (and consistent with feedback from MCS and PSS in the field). In addition, the new Deployment Guide will also include the following additional information: Deploying the Web services (among the features in new release) Deploying the site administration tier (where Business Users perform business analytics) Deploying the development tier (where developers update site code, pages, and

navigation) Publishing Site Updates across tiers (using Application Center)

For example, the following list reveals the document structure for the existing Commerce Server Secure Deployment Guide: Introduction Overview of the Sample Secure Deployment Setting Up Firewalls and Ports for a Secure Deployment Installing the Base Platform Configuring IP Addresses and DNS Entries for a Secure Deployment Configuring the Network Connections Wiring the Network Installing the ISA Servers Configuring the ISA Servers Installing the Domain Controllers Joining the Servers to Domains Configuring the Domain Controllers Installing and Configuring the SQL Servers Installing Commerce Server Configuring the Business Desk Client Computer Configuring the Web Server Installing the Microsoft Security Tools on the Web Server Securing the Commerce Server Components Completing Wiring the Network

For RSWAT, the Deployment Guide will have the following document structure (approximately): Introduction Deployment Architecture Security Overview

Microsoft Corporation, 2005. All Rights Reserved. 1


Deployment Preparation Deployment Implementation Post-Deployment Tasks Deployment Updates

There are more details about each of these sections below in the "Structural Overview" section. The conceptual sections will leverage content from MSIB 2.1 (most notably the Deployment Overview document) for information on design goals and deployment preparation. The detailed technical information will capture the laboratory configuration and testing conducted by the RSWAT product team.The word "secure" should not be in the document title because security is assumed and implied: we don't document scenarios that are not secure and realistic. The Deployment Guide will have a Security Overview section to address security.

1.1 Overview and BackgroundEssentially, RSWAT delivers a revamped Business Desk for accessing and managing data in Commerce Server. With the delivery of RSWAT to certain retailers, we need supporting documentation that prescribes how to deploy RSWAT in a secure environment We have existing documentation from the Commerce Server Secure Deployment Guide, but we need to accommodate the new Web services in RSWAT. Additionally, the updated Deployment Guide needs to cover an end-to-end scenario that includes information not only about the production tier, but on configuring the other tiers in the deployment and deploying site content across these tiers.The following diagram illustrates the scope of the deployment.



1.2 User Definition & ScenariosWhile RSWAT is not actually being sold to customers (it is only being delivered to retailers), the RSWAT Deployment Guide will target a generic (but broad) range of readers, including developers, network administrators, Business Users, and Managers. The Deployment Guide will not be published like other whitepapers (over the Web), but be delivered as a Microsoft Word document with the RSWAT product CD.



The scenario for the Deployment Guide will focus on building a large eCommerce site that enables the following tasks: Site architects to plan and design the deployment architecture according to their

requirements and resources Network administrators to configure and deploy the hardware and software on the

various servers Developers to collaboratively update site code, pages, and structure using Visual

Studio .NET Site visitors to shop and perform transactions securely on the production site Business users to profile site visitors and run reports to analyze site activity Business users to update product catalog data and marketing strategies in response to

business analytics

2 Objectives and AssumptionsThis section lists and explains the customer-based and internal goals of the RSWAT Deployment Guide. Goals should be specific and comprehensive enough to be used to measure the success or failure of the feature. It includes the major assumptions that are made in the specification of the feature area requirements.

2.1 Design GoalsThe RSWAT Deployment Guide enhances the existing Commerce Server Secure Deployment Guide by presenting a cleaner document structure, but includes additional information for deploying, configuring, and managing the RSWAT Web services (the new way of accessing Commerce data).The updated Deployment Guide will be more comprehensive than the previous version, including information about configuring the other tiers in the deployment (not just production) and also the process of deploying site updates across these different tiers.

2.2 Preliminary ScheduleMilestone DateFirst draft complete 6/16/2005Technical Review 6/23/2005Edit pass 6/30/2005Second draft complete 7/1/2005Production pass 7/2/2005Final draft complete 7/10/2005Final drop 7/11/2005

Refer to the MS Project file for further details:



3 Structural OverviewThe RSWAT Deployment Guide will have the following contents:A. Introduction

1. Background on RSWAT (show the RSWAT components/layers, diagrams, management UI, etc.,)

2. Overview of primary phases in deploying RSWATa. RSWAT Network Configurationb. RSWAT Server Deploymentc. RSWAT Site Developmentd. RSWAT Site Publishing and Updatinge. RSWAT Business Analytics and Reporting

3. Purpose and scope of document4. Document structure and conventions5. Target audience

B. Deployment Architecture1. Functional requirements

a. Design goalsb. RSWAT components

2. Logical design/groupinga. Production environment (Web/DMZ and data/database tiers)b. Site Administration environmentc. Development environment

3. Physical designa. Network topology diagram(s)b. Server/tier description tablesc. Production environment

1. Web tier2. Data tier

d. Site Administration environment1. SQL Server2. Data Warehouse (OLAP)3. Legacy Business Desk4. Web Services Management UI

e. Development environmentC. Security Overview

1. Distributed architecturea. Isolated tiersb. Firewalls and ISA Server



2. Trusted Subsystem Model for accessing services and resourcesa. Role-based and resource-based authorizationb. .NET roles and SQL Server database roles

3. Site visitor authenticationa. Kerberosb. IIS authentication (anonymous, basic, digest, integrated Windows, client

certificates)4. Business User authentication5. Database roles

D. Deployment Preparation1. Hardware Requirements2. Software Requirements3. Deployment sequence/stages4. Assessing hardware, software, server, and network requirements5. Identifying a suitable deployment architecture6. Acquiring all of the necessary hardware and software

E. Deployment Implementation1. Configure the network

a. Table of network settingsb. Physical diagram of rack and server connections

2. Deploy the production environmenta. Deploy the data tier

1. Deploy the domain controller(s)2. Create the necessary accounts3. Deploy the SQL Server(s)4. Deploy the RSWAT server

b. Deploy the Web tier1. Deploy RSWAT server(s)

3. Configure the database roles in SQL Server4. Configure roles for the RSWAT Authorization Manager5. Deploy the site administration environment

a. Deploy the SQL Serverb. Deploy the Data Warehouse serverc. Deploy the RSWAT server (with the RSWAT Management Web services)

6. Deploy the development environmenta. Deploy the domain controllerc. Deploy the SQL Serverd. Deploy the RSWAT development computer

F. Post-Deployment Tasks



1. Installing the Microsoft Security Toolkita. Requesting and importing an SSL certificateb. Running the IIS Lockdown Toolc. Disabling unnecessary services

2. Verifying functionalitya. Testing the browse functionality by site visitorsb. Testing the purchase functionality by site visitors

i. Testing login/authenticationii. Testing basket functionalityiii. Testing checkout functionality

c. Testing the Commerce Web services functionality by business usersi. Testing the Catalog Web serviceii. Testing the JAMS Web serviceiii. Testing the Inventory Web service

G. Publishing Site Updates1. Using Application Center 2000

a. Installing Application Center 2000b. Creating an Application Center 2000 clusterc. Adding Application Center 2000 cluster membersd. Defining an RSWAT application in Application Center 2000e. Deploying IIS Web site assets with Application Center 2000

2. Deploying RSWAT Web services and database resources with Site Packagera. Packaging the Web services into an MSIb. Deploying the MSIc. Registering the Web service

3. Verifying Site Updatesa. Verifying updates to the product catalog systemb. Verifying updates to the profiling system

i. Verifying updated profile definitions and site termsc. Verifying updates to the targeting system

i. Verifying updated campaignsd. Verifying updates to the business processing pipeline system

i. Verifying updated shipping information

4 Related DocumentsDocument Name LocationMicrosoft Commerce Server Secure Deployment Guide

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/comm/



comm2002/deploy/SecCncpt.aspRSWAT Functional SpecificationRSWAT Deployment SpecificationRSWAT Deployment Architecture DiagramRSWAT Secure Deployment Plan - Identities and Roles Spreadsheet

5 Dependencies and Integration PointsThis section lists dependent technologies, both internal and external, and also key interactions/integration points. For example, any components within the eBiz suite that these features will impact, with brief overview of the integration or interaction

5.1 InternalTo deliver the RSWAT Deployment Guide, UE must work with the test team to provide the prescriptive guidance for deploying RSWAT. This requirement involves rigorous trial-and-error for prescribing the proper database and roles, as we document our best educated guess as a stake in the ground, then have test determine what the proper roles are (let us know where the stake should actually be located).And as test determines the proper roles, we update the documentation and then re-test for any regressions.

5.2 ExternalWe must work with the different Commerce feature teams to aggregate information for the document because there is no official RSWAT team.We will also need to recruit a "green guy" who has no prior knowledge of RSWAT (CS2k+ is okay). This person will execute and validate the instructions in the Deployment Guide, and provide feedback about the product and document.

5.3 Compatibility RequirementsThe RSWAT Deployment Guide will not have backwards compatibility with the Commerce Server 2002 Secure Deployment Guide because RSWAT does not add anything on top of the Commerce Server bits. Rather, RSWAT replaces the Commerce Server bits and provides an entirely new Commerce Server (2002+).



6 Functional RequirementsThis section explains what functionality the features in this component are required to provide and/or support. It also provides implementation guidance for how these requirements will be met. This chapter is the heart of the document.

6.1 Requirements OverviewThis is a table of the major features and functions to be built, an estimate of their cost from a development and test standpoint, and the priority of the feature. Release Objective

Functional Requirement Priority Impact

Prescriptive guidance for deploying the production environment H LPrescriptive guidance for deploying the site administration environment

H M

Prescriptive guidance for deploying the development environment

H M

Prescriptive guidance for packaging site assets (with PUP and AC)

H M

Prescriptive guidance for publishing site updates H HPrescriptive guidance for locking down the database roles H HPrescriptive guidance for locking down the authorization roles (azman)

H H

Conceptual guidance for design goals. H MIntroductory information (background, scope, audience, doc structure, overview, etc.,)

H M

Listing of hardware and software requirements H LSample deployment diagrams H MPrescriptive and conceptual guidance for running business reports

M H

Prescriptive guidance for verifying functionality H H

This is a mechanism for gathering and tracking potential requirements for the release. The following sections will describe each of the requirements in detail. Example provided below.

6.1.1 Prescriptive Guidance for Deploying the Production EnvironmentThis requirement involves setting up the domain controller, SQL Server(s), and RSWAT server in the data tier, and setting up the RSWAT server(s) in the Web tier. It might also involve setting up the tier 2 ISA Server that separates the Web and data tiers.Much of this information is already documented in the Commerce Server Secure Deployment Guide and MSIB v2.1 prescriptive documentation. For RSWAT, the following changes are different from the Commerce Server secure deployment and must be documented: Platform updates such as Windows 2003 SP4 and .NET Framework 3.1 No domain trust between Web and data tiers (since Web tier has no domain controller) Integration of Application Center on the RSWAT servers and SQL Server



6.1.2 Prescriptive Guidance for Deploying the Site Administration EnvironmentThis is a new requirement of RSWAT that was not part of the Commerce Server Secure Deployment requirements. Deployment of the site administration environment consists of setting up the following servers: SQL Server (that hosts the administration and run-time databases) Data warehouse server (with OLAP) RSWAT server (with Business Desk, the RSWAT Web services, and Application Center)

While this requirement is new, we can take the prescriptive guidance for deploying the production environment and reduce it to accommodate the following differences in the site administration environment: No firewall/ISA Server that separates the RSWAT server from the database server No domain controller No clustered SQL Server for the administration and run-time databases Additional SQL Server for data warehouse and OLAP

6.1.3 Prescriptive Guidance for Deploying the Development EnvironmentThis is a new requirement of RSWAT that was not part of the Commerce Server Secure Deployment requirements. Deployment of the development environment consists of setting up the following servers: Development computer (with Visual Studio .NET, source control client application, and

possibly local SQL Server) SQL Server computer (if developers are not running SQL locally, but multiple developers

reference a common SQL Server) Integration server where developers check-in their work and the project is built

While this requirement is new, we can leverage content from the MSIB v2.1 Configuring a Development Environment document.

6.1.4 Prescriptive Guidance for Packaging Site AssetsThis is a new requirement of RSWAT that was not part of the Commerce Server Secure Deployment requirements. Since a requirement of the RSWAT Deployment Guide is to prescribe a process for publishing site updates across tiers, we must document the following tasks: Enumerating site assets (how to identify what all needs to be deployed) Packaging site assets (whether thru pup or defining an Application Center 'application') Deploying site assets (methodology for transferring the site updates/assets)

We can leverage the existing documentation in Commerce Server for using Site Packager, and also the Application Center documentation for defining and adding resources to an Application Center 'application'.



The new inventory and marketing Web services in RSWAT will be rolled into and deployed with Site Packager. We might need additional documentation on deploying the assemblies and updating the Global Assembly Cache (GAC).

6.1.5 Prescriptive Guidance for Publishing Site UpdatesThis is a new requirement of RSWAT that was not part of the Commerce Server Secure Deployment requirements. Since different users will be updating different aspects of the site, this requirement involves separating the tasks according to the user segments as described in the "Usage Scenarios for Publishing Site Updates" sub-section below.Once the tasks have been defined (user segments have been associated with the site assets that they will update), we can prescribe how to accomplish the tasks.We can leverage content from the MSIB v2.1 Content Propagation document that was started but not included with the final release.

6.1.5.1 Usage Scenarios for Publishing Site Updates Developers update site code, pages, and navigation Business Users update product details (single field edit of single product)

Move a product to a different (or additional) category Delete an old product Add a (or several) new variant to a product Change a product price Create a new category

Less common: create a new base catalog create a new virtual catalog change prices on all products in a category

Business Users update marketing strategies (targeting, personalization, campaigns, advertisements, discounts, etc.,)

Business Users update order information (such as location codes, tax rates, and shipping methods)

Business Users update profile information (such as site terms, property definitions, and expressions)

6.1.6 Prescriptive Guidance for Locking Down the Database RolesThis requirement existed in the Commerce Server secure deployment and involves assigning database roles on the Commerce Server resource databases for each SQL Server login account (database account).We can leverage the "Securing the Commerce Server Components" section in the Commerce Server Secure Deployment Guide that describes how to lock down the database roles.



6.1.7 Prescriptive Guidance for Locking Down the Authorization RolesRSWAT will be using the Authorization Manager (Azman) module that ships with Windows 2000 SP4. This module will handle authentication for the Web service identities, and require prescriptive guidance on locking down the proper roles.The current point-of-reference is that these roles (like the SQL database roles) will be created during the unpup process, but users still need to configure the roles appropriately for their environment/scenario.There is no existing documentation for using or locking down these roles, so I will work with the team to get the correct information into the document.

6.1.7.1 Default rolesWe should provide some predefined/sample roles, such as: Catalog Administrator – all powerful, can do anything the catalog system allows Product Editor – can change all product properties except product price Price Manager – can change product prices Catalog Reader – can only view catalogs, no updates allowed Deployment Administrator - can only run Site Packager, MSIs, etc,. cannot update

marketing or catalog data Developer - can update site code and pages, but not run any of the marketing Web

services Marketing Manager - can run reports against Data Warehouse and update marketing

data, but not update catalog data

6.1.8 Conceptual Guidance for Design GoalsThis requirement involves explaining to users how to design their deployment, what design considerations to take into account, and how various factors and requirements should impact their deployment design.This section will require the following steps:

1. Identify functional requirements (the functionality that the deployment must support).

2. Organize the functional requirements into a conceptual design (map the required functionality against the features in our products, and logically group the functionality into conceptual tiers).

3. Transform conceptual design into physical design (now that the functionality is organized into conceptual tiers, define how the conceptual tiers will be deployed physically).

4. Implement/deploy the physical design (execute the prescriptive guidance according to the standards, requirements, and resources of your particular environment).

We can use information from the MSIB v2.1 Deployment Overview document but ultimately, we should have some metrics based on performance characterization. For example, the document needs to be able to say "This deployment architecture consisting of 12 servers supports up to 100,000 concurrent shoppers while processing up to 10,000 transactions.



Internally, up to 25 developers can simultaneously update site code and pages while up to 1,000 business users are analyzing and updating marketing data."

6.1.9 Introductory InformationThis requirement involves providing background information about RSWAT and its associated concepts and technology. We will need introductory information to cover the following topic areas:

Introduction to the document (purpose, scope, structure, conventions, target audience)

Introduction to RSWAT (RSWAT features, architecture, and design overview) RSWAT Deployment Overview

o RSWAT Network Configurationo RSWAT Server Deploymento RSWAT Site Developmento RSWAT Site Publishing and Updatingo RSWAT Business Analytics and Reporting

Much of this information can be leveraged from the MSIB v2.1 Deployment Overview document. We will need to update this information and add details to accommodate RSWAT.

6.1.10 Listing of Hardware and Software RequirementsThis requirement involves listing the hardware and software requirements for each server in the RSWAT deployment. For hardware, we will need to include the minimum hardware requirements and the recommended hardware requirements (what we actually tested against). For software, we only need to document the minimum software requirements, as these requirements are the same requirements that we tested against.We should organize this information in a table with the following column headings:

Server Hardware Recommendation Software Requirements

The following table is an example of how this section would appear in the Deployment Guide.Server Hardware Recommendations Software RequirementsWeb Server Dual 1.0 GHz Processor

1024 MB RAM 9.0 GB Hard Disk Space 2 Network Adapters

Windows 2000 Advanced Server with Service Pack 4

Internet Explorer 6.0 with Service Pack 1

MSXML 4.0 with Service Pack 2

SQL Server 2000 Client Tools

SQL Server 2000 Service Pack 3



MDAC 2.7 RTM Refresh .NET Framework with

Service Pack 2 Jupiter Technical Preview

for Retail Visual Basic 6.0 with

Service Pack 5 runtime hotfix

Secure Sockets Layer (SSL) certificate

Internet Information Services (IIS) Lockdown

Application Center 2000 with Service Pack 2

SQL Server Quad 800 MHz Processor 2048 MB RAM 50.0 GB Hard Disk Space 2 Network Adapters




SQL Server 2000 Enterprise Edition with Service Pack 3

Application Center 2000 with Service Pack 2

Domain Controller Dual 800 MHz Processor 512 MB RAM 9.0 GB Hard Disk Space 1 Network Adapter




Visual Basic 6.0 with Service Pack 5 runtime hotfix

Data Warehouse Server Quad 800 MHz Processor 2048 MB RAM 50.0 GB Hard Disk Space 1 Network Adapter




SQL Server 2000 Enterprise Edition with Service Pack 3

SQL Server 2000 Analysis Services with



Service Pack 3

Most of this information can be leveraged from the MSIB v2.1 Deployment Overview document, but we will need to format the information into a table and update the requirements for RSWAT.

6.1.11 Sample Deployment DiagramsThis requirement involves providing conceptual and technical diagrams to help explain certain aspects of the deployment. The conceptual diagrams provide visual representation of RSWAT concepts (such as the RSWAT architectural layers and logical components) while the technical diagrams will show the physical network topology and network connections.This requirement is explained in further detail (with examples) in the "Graphics Requirements" section below.

6.1.12 Prescriptive and Conceptual Guidance for Running ReportsThis requirement involves explaining to users how to run reports and analyze business activity with the Data Warehouse. There is a work item to create an RSWAT Data Analysis Guide, but this document will be released much later than the RSWAT Deployment Guide. Therefore, we should provide some high-level information about data analysis in the Deployment Guide, and leave the procedures and details for the RSWAT Data Analysis Guide.We will need to leverage content from Commerce Server 2002 and also the Business User's Guide in MSIB to cover this requirement.

6.1.13 Prescriptive Guidance for Verifying FunctionalityThis requirement involves running tests and other validation procedures to verify functionality. We need to identify 'checkpoints' throughout the deployment process so users can get confirmation at each stage, then define how the verification will be executed.This validation is critical to the deployment because users need confirmation and reassurance that they are deploying appropriately and successfully before proceeding onto the next stage in the deployment.For this content, we can leverage some of the test cases, and also formally create some simple tests based on informal steps that I have observed SMEs using in the lab (for example, checking the number of rows in a database table to verify that changes to the table were staged properly from the site administration tier/domain to the production tier/domain).The following example shows the types of validation tests we can prescribe users to perform:

1. Verifying functionalitya. Testing the browse functionality by site visitorsb. Testing the purchase functionality by site visitors

i. Testing login/authenticationii. Testing basket functionalityiii. Testing checkout functionality

c. Testing the Commerce Web services functionality by business usersi. Testing the Catalog Web service



ii. Testing the JAMS Web serviceiii. Testing the Inventory Web service

2. Verifying Site Updatesa. Verifying updates to the product catalog systemb. Verifying updates to the profiling system

i. Verifying updated profile definitions and site termsc. Verifying updates to the targeting system

i. Verifying updated campaignsd. Verifying updates to the business processing pipeline system

i. Verifying updated shipping information

7 Technical ReviewTechnical review will occur towards the end of the document development phase and can actually be conducted in parallel with editing to save time. The Deployment Guide will be attached in email and sent to the RSWAT Deployment team ("rswatdep") for technical review. Comments must be incorporated before the production pass starts.We should also solicit feedback from MCS and PSS wherever possible, and line-up a "green guy" with no prior knowledge of RSWAT to step-through and evaluate the deployment guide. These key contacts (and the ones listed below) are all essential for getting critical feedback about the document.Additionally, we are continuously getting feedback from Costco (represented by Pradeep) at key milestones in our project before we begin work against that particular milestone.

7.1 Primary ReviewersA bug must be opened against the primary reviewers for official sign-off on the Deployment Guide.

8 Graphics RequirementsThis section identifies the pieces of art that will be required for the RSWAT Deployment Guide. One art bug must be opened for each requirement, where the editor reviews the bug first before the graphic designer begins designing. The art will reside in VSS in a sub-folder beneath the source document.

8.1 Minimum RequirementsThe RSWAT Deployment Guide will need the following pieces of art (at a minimum):

1. Conceptual diagram depicting the "big picture" view of the entire deployment (including production, site administration, and development environments).

a. This graphic will be based on the deployment diagram.vsd in the RSWAT Test Spec (similar to the diagram at the beginning of this specification).

2. Physical diagram depicting the network and laboratory connections.a. This graphic will be based on the physical diagram created on sheet 2 of the

vsd. This graphic looks like the following.



3. Physical diagram of the production environment (including Web and data tiers).a. This graphic will be based on the following graphic from MSIB.



4. Physical diagram of the site administration environment.a. This graphic will be a new requirement, and look similar to the 3rd graphic

(production environment) except that the RSWAT server(s) and database server are in the same environment (not in separate Web and data tiers).

5. Conceptual diagram of the development environment.



a. This graphic will be based on the following graphic from MSIB.

6. Conceptual diagram of the components in the deployment (how the conceptual tiers are related.

a. This graphic will be based on the following graphic from MSIB.

7. Conceptual diagram of the primary deployment stages.a. This graphic will be based on the following graphic from MSIB.

9 Editing RequirementsWe must line-up an editor for this document near the end of June or beginning of July. Ideally, this editor would be one who has worked on Commerce Server (CS) and MSIB documentation in the past, and is familiar with the CS concepts as well as the format of the prescriptive guidance.One possibility to consider that alleviates editing requirements is to hand-off sections of the document as they are completed, rather than waiting until the scheduled time to hand-off the entire document at once for review. For example, the introductory and conceptual sections will certainly become stable before the prescriptive guidance will, so we can have



the editor review those sections while test determines the proper steps in the technical details of the prescriptive guidance.Another note in regards to editing is the prescriptive guidance itself, as there will undoubtedly be regressions from bug fixes against the document. Having just worked on the prescriptive guidance in MSIB, I suggest that after the scheduled document freeze date, any changes to the document should ONLY require editing (and possibly production) if any NEW text is added. Editing is not required if no new text is added (for example, if steps are re-ordered, steps are eliminated, or some values are updated).

10 Production RequirementsDave Johnson (fictitious for this sample) will likely be the production contact for the RSWAT Deployment Guide. Upon completion of technical review and editing, the document is run through a production pass to ensure that it will display properly when users open it.Unlike the editing requirement, where we can skip editing if no new content is added, we still need production to review any changes after the scheduled document freeze date. This requirement is necessary because changes that don't impact editing might still impact the document's presentation and flow (if for example, deleting some step causes a page break to appear in an awkward/unnecessary location).

11 Open IssuesThis section lists the potential issues that might need to be addressed. The following list describes some issues that have not been currently addressed: Not sure how databases will be updated across tiers (current POR is to use Application

Center?) At what level of granularity will the database roles and Azman roles be applied? Per

database or per table? Different identities for each Web service?
