Administer > Deploy

WebSphere Commerce deployment checklist

The WebSphere Commerce deployment checklist is based on lessons learned from IBM internal groups, external customers and business partners deploying WebSphere Commerce-based solutions. This checklist is intended to provoke discussion; it is not a detailed set of instructions.

• Access control
• Database
• Cache
• Integration
• Store pages
• Initial data load
• Campaigns
• Site Monitoring
• Reporting
• Backup and recovery
• Upgrades and fixes
• Development, test, staging and production

Access control

• Is access control on commands and on JSP pages applied appropriately?

• Ensure that access control is turned on

• Ensure that each URL command is restricted to only those users that are supposed to be able to execute them. URL commands can be typed on the browser address line, so safeguard beyond the links available on the JSP pages.

• Ensure that each view is also restricted to the right set of users. For example, any additional WebSphere Commerce Accelerator pages should be viewable by specific roles only.

• Is access to administration tools (WebSphere Commerce Accelerator, Administration Console, and Organization Administration Console) outside the firewall properly configured, or disabled?

  • If we will not be using the browser-based administration tools, then remove the code from the server so no one can access it, or try to access it.

• Are the right subset of roles assigned to the right set of administrators? Do any passwords need to be reset?

  During testing, you may have used a user assigned the Site Administrator or Seller role, but as the system is rolled out to specific users for specific roles, make sure they have been assigned only the roles they are allowed to perform.

  • Select roles for an organization

  • Select roles for a user

Database

• Is the production database free from test data, or erroneous data?

  Ensure that all test catalog data is removed before going live a smaller database will be faster to access.

  To clean the database use the Database Cleanup utility.

• Are the database statistics up-to-date?

  • The database statistics are used by the query optimizer when selecting the best way to execute a query.

  • If the database statistics are wrong, then the query optimizer may select a course of action that results in a lot longer to execute than it planned.

  • See REORG and REORGCHK in the DB2 documentation, or similar commands in Oracle.

• Are the database configuration and tuning parameters signed off by the Database Administrator (DBA)?

  • The WebSphere Commerce database is very important as it is the data store for the users, catalog, and orders.

  • The database must be configured properly for the amount of memory that is available, the size of the catalog, any new tables/columns that were added, and any new queries that are being performed. For example, do any new indices need to be created to help new SQL in EJBs or Access Beans or Data Beans perform better?

Cache

• Is the cachespec.xml set up appropriately for caching and invalidation?

  The cachespec.xml contains the rules for when to cache servlets, pages, and fragments, the amount of time to hold them, and the invalidation rules

• Are the caches primed (pre-populated) to maximize response times?

  • You can create automated scripts to go through all the pages on the site and pre-populate the cache

• Is the Web server cache (images? fragments?) and Edge Server cache (images? fragments?) configured and loaded properly?

  • Ensure to cache appropriate assets at appropriate locations http://www.ibm.com/developerworks/websphere/library/techarticles/0405_caching/0405_caching.html

  • Web server caching, including ESI caching, is available out-of-the-box.

  • Edge caching with services such as Akamai or IBM WebSphere Edge Server is available at an additional cost.

Integration

• If a back-end system is unavailable, or too slow to respond, is there a alternative solution in place?

  • One of the functional verification test cases should test when the back-end system is unavailable and what impact that will have on the customer.

  • Will the customer be asked to try again later? Will some default value be assumed and then checked manually later?

Store pages

• Is the final artwork and store JSP pages approved?

  Make sure the final approved artwork and JSP page look-and-feel is uploaded to the production site.

• Are the error JSP pages meaningful and helpful for the customer?

  • If there is a typo in a URL command link or a command times out, then the generic error page will be seen. Modify this page to make it look like the rest of the site and to provide a means for the customer to continue, or retry the function.

  • The Web server's 404 (page not found) error page should also be updated to provide the customer with a course of action.

Initial data load

• Are the final catalog updates loaded and verified?

  • Verify the catalog information is accurate.

• Are the final prices and inventory levels loaded and verified?

  • Ensure that prices are correct, for example there are no items for $0.00 or $0.01.

  • Some customers explicitly check for accidentally low priced items during checkout.

  • Ensure that inventory levels are as up-to-date.

• Are the right set of contracts deployed?

  • Contracts need to be deployed to be in effect.

Campaigns

• Are the right set of campaign activities Active?

  Campaign activities are can be in active and inactive modes. They must be in Active mode to be in effect.

Site Monitoring

• Are the system administrators aware of how to tell if the site is working well or if the site is experiencing problems?

  • Ensure that system administrators know which logs to look at for errors and which tools to use to monitor performance. For example, the Tivoli Performance Viewer, Cache Monitor, WAS log viewers

  • Viewing service and activity logs

• Is there a plan to monitor resource utilization?

  • What are the acceptable limits to the resources and at what level should someone be notified?

• As traffic increases, is the site's expected breaking point known?

  • Through performance, stress, and load tests, you should understand how the site will become constrained as site traffic increases.

• Are the right Application Server logs turned on?

  • Verify the right granularity of information is being tracked to aid problem determination

  • Verify the logs are archived and not overwritten so that they can be used for problem determination

• Is the right level of WebSphere Commerce logging turned on?

  • Log services

Reporting

• Is there a need to turn on the User Traffic Log?

  • The user traffic log data is required for some reports in the WebSphere Commerce Analyzer

  • Configure caching to capture user traffic data

Is there a need to turn on the Marketing Event Monitors?

• The event monitors are required to be on to measure effectiveness of campaign activities. For example, the Marketing Event Monitor is required to log how many times a particular campaign activity ad shown to customers and how many times did they click on it?

  • Marketing Event Monitor for WebSphere Commerce Accelerator

Are the right Web Server logs turned on?

• Is there information in the Web server logs that is needed for reports? For example, the type of browser, the forwarding destination, access information (time of day), click stream data.

Backup and recovery

Is a backup of the production site database, customized code, and configuration parameters available?

• All configuration information should be recorded so that it can be used to create a duplicate test environment or a duplicate production environment in the case of an emergency

• Ensure all source code is backed up so that future changes can be made

• Ensure the customer and order data is backed up

Is a disaster recovery plan in place?

• What is the plan if the database disk drive crashes?

• What is the plan if the WebSphere Application Server becomes non-responsive?

• What is the plan if the Web server becomes unavailable?

• What is the plan if the load balancer stops working?

Is there a plan for how the site will be managed in the case where the site needs to be brought down temporarily or for an extended period of time?

• What will a customer see if the site is taken down for emergency maintenance, or in case of a networking problems?

Upgrades and fixes

Is a regular maintenance window planned?

• Are regular maintenance windows planned for operating system or networking maintenance?

• Will these maintenance windows take place during periods of low traffic?

Is there a plan for how upgrades and fixes will be applied to the site?

• What are the set of steps that will be performed to make changes to the production site?

• What changes will require the site to be brought down?

• What changes can be made while the site is operational?

Is there a plan for how emergency updates will be made to the catalog, for example to update products or prices?

• If a price is discovered to be incorrect due to a typo, such as $10.00 instead of $100.00 or a product description incorrect, such as an acrylic sweater really being made from cashmere, what is the process to update the Web site. Will the source be updated as well?

• Does the person responsible for the emergency updates understand how to perform the task? and are any approvals required?

Development, test, staging and production

• Have you confirmed that key functionality, scripts, processes work the same way in the production environment as they did in the test environment?

Related concepts

What's changed for deploying customized assets

Related tasks

Deploy customized assets

Related reference

Top 10 tips to ensure a successful deployment of WebSphere Commerce

+

Search Tips   |   Advanced Search