1 / 17

B2B Change Management at Corporate Express

B2B Change Management at Corporate Express. Sonam Chauhan Corporate Express. Overview. Introduction Change Process Testing Monitoring and Administration Change Deployment CECM Deployment Verification Tool webMethods Deployer? Some Feature Requests. Introduction.

auryon
Download Presentation

B2B Change Management at Corporate Express

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. B2B Change Management at Corporate Express Sonam Chauhan Corporate Express

  2. Overview • Introduction • Change Process • Testing • Monitoring and Administration • Change Deployment • CECM Deployment Verification Tool • webMethods Deployer? • Some Feature Requests

  3. Introduction • Constant pressure for change  • Change management process crucial • webMethods weaknesses • Development skills required for changes • Primitive source control • Lack of testing support • No verification of change deployments

  4. Development Change Process Requirements Specification Requirements Definition Changes ValidatedChanges Review and Testing Change Deployment (Test  UAT  Live)

  5. Testing • Like development, testing is an engineering skill • Allocate limited resources for max. benefit. • Best return for your testing buck  Black-box Integration testing for Regressions • High level tests simulate live use • Tests can be external to code • Easy to retrofit to existing codebase • Regression are the costliest bugs • All changes must “first do no harm”

  6. More Testing Points • Developers can be testers! • Commitment to quality • Make test development part of development process • Make reviews of the test code part of code review process • Automate testing • Automated Regression Testing Harness • Without automation, testing is tedious work • Automation increases productivity and efficiency • Permanently add hard-won insight to corporate memory • And replay it on demand • Essential for managing change in complex systems • Active testing catches problems early • Load testing often very important • Some bugs can only be "teased out" under load.

  7. Testing with JMeter • Multiple such test scripts are run by an automated regression test harness Load testing part of same test script Use TN database to help test document transforms

  8. Monitoring and Administration • Separate developers from day to day server administration • Better staff productivity, better server stability • Create monitor services specific to your needs • For eg: Can clients can access B2B resources? Is B2B thread count approaching dangerous levels? • Integrate monitor services with external monitoring tools (eg: Nagios, OpenView) • Quantify system availability • Unified system monitoring interface makes it easy to administer systems

  9. Change DeploymentProcess • A defined process is important • Implementation Plan • Reviews and approval signoffs… • Post Implementation Actions • Test Plan • Rollback Pan • Currently, some deployments require webMethods development skills

  10. CECM Deployment Verification Tool • CECM = CE Configuration Management • A B2B package used to collate and compare package configuration information from an arbitrary number of webMethods B2B servers. • Calculates md5 checksum of package files • Shows package level differences • Ability to drill down to file level differences • Essentially, a “Server-Diff” tool

  11. Choose servers to “Diff”

  12. Package level issues Drill down to file differences Hatched pattern means package missing

  13. Different colours mean file has different checksums Similar colours mean file has same checksum Hatched pattern means file missing

  14. CECM - Usage • Used in detecting and correcting incorrectly setup B2B environments • For e.g.: a change that failed to deploy on one node in a cluster • Used to assure correct deployment of B2B packages in a Develop/Test/Release cycle.

  15. CECM - Details • Option to exclude package manifests file • Manifest.v3 file contains package creation timestamp • No session data persistence – need to use Mozilla for file-level drill-down • Arbitrary limitation in IE 5.5: GET URLs clipped to 4096 bytes • Which files are included for package comparison? • Simple: All files documented as needing source control: • /manifest.v3 • /pub/ • /widls/ • /templates/ • /code/jars/ • /code/libs/ • /code/source/ • /ns/ • Excludes /data/, /config/, and other directories

  16. wM Deployer? • Deployer - a good idea • Still maturing… • Seems to lack rollback functionality(?) • Some bugs: • Package version number promotion bug • Problem with ACL assignments • Questions about TN promotion ability • Can it link profiles and document types to processing rule changes? (i.e. Can it remove need for TN Console in change deployment?).

  17. Some Feature Requests • Deployer is a good idea - improve and extend it’s functionality • Eg: Give it CECM’s ability to “diff servers” • Give it functionality to version a server state and rollback the entire server to a known state • Create functionality or build hooks for: • Source code management systems • Automated documentation generation (including TN rules) • Automated Testing

More Related