1 / 48

Configuration Management

Greg Coburn Senior Technical Account Manager. Configuration Management. Agenda. Distributed Development Model s Distributed Development Tools Architecture Application Change Management. Development Models. Three Broadly Defined Development Models

ignatius-eaton
Download Presentation

Configuration Management

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. Greg Coburn Senior Technical Account Manager Configuration Management

  2. Agenda • Distributed Development Models • Distributed Development Tools • Architecture • Application Change Management

  3. Development Models • Three Broadly Defined Development Models • Centralized Development: Uses one centrally managed repository • Centralized Distributed Development: Uses one core repository and several local repositories • Decentralized Distributed Development: Uses a few peer repositories • Criteria for Using a Particular Model Include: • Number of user groups requiring localization • Diversity and nature of local requirements • Relative importance of: • Object reuse/Leveraging Development Effort • Flexibility, concurrent development • Change management simplicity

  4. Development Models Centralized Development Characteristics • All development contained within a single repository and managed by a single development team • Separate Responsibilities are used to selectively expose objects that are unique to specific Divisions Core NL BE NO SE DK

  5. Development Models When to Use a Centralized Development Approach • Differences between localized implementations are non-existent or limited to language translation and a few distinct applets and views • A wide spectrum of data must be shared seamlessly among localized implementations • Limited development resources or experience with complex application change management Centralized Development maximizes object reuse and minimizes change management requirements

  6. Development Models Centralized Distributed Development Characteristics • Components explicitly intended to be shared by multiple repositories are stored in a centrally managed “Core” repository • Core developers periodically review satellite repositories to ensure compliance with Core standards and consider whether satellite-level modifications should be included in the core. • Core developers maintain detailed documentation on modified components • Patches or Application Upgrader used to issue updates from the Core to local repositories Core NL BE NO SE DK

  7. Development Models When to Use a Centralized Distributed Development Approach • Clear standards can be maintained for sharing data among local implementations/teams • Local implementations have considerable overlapping requirements • Client intends to share objects among more than 2-3 repositories or multiple development teams • Client is prepared to coordinate application change management effort among development teams Centralized Distributed Development balances object reuse with localized development flexibility

  8. Development Models Centralized Distributed Development Guidelines • Clear design specifications must be drafted that specify which object definitions will be controlled by the core repository • Core repository represents superset of all common functionality • Local design specifications and configurations should be reviewed by the Core development team in the course of the change management process • All local configuration must explicitly consider implications for sharing business data among applications

  9. Development Models Decentralized Distributed Development Characteristics • Local repositories configured and maintained independently by separate development teams • Detail documentation is maintained within the comments field of each object, and/or a source control application is used to maintain historical information about each object • Object definitions that can be used by more than one implementation are periodically shared using Import/Export tools NL BE NO SE DK

  10. Development Models When to Use a Decentralized Distributed Development Approach • Limited or no need to share data directly between localized implementations/applications • Client intends to share objects among no more than 2-3 repositories • Repositories have relatively diverse requirements • Time and effort required for centrally-coordinated application change management outweigh benefits Decentralized Distributed Development maximizes development concurrency and flexibility

  11. Distributed Development Tools • Siebel offers a wide range of different repository management tools -- each of which has a unique purpose and benefit • Export and Import • Exports and imports selected object definitions to and from an archive file • Patches • Allow changes made to one repository to be applied to another • Source Control Integration • Automatically saves archive files to a Source Control System during check-in and check-out • REPIMEXP.EXE • Exports and imports whole repositories to and from a binary file • Application Upgrader • Upgrades object definitions of whole repository while preserving configuration changes • Check In - Check Out • Allows many developers to update separate parts of a central repository at once

  12. Tools - Export and Import Features Export Objects or Projects to anArchive File Import from an Archive File into a Repository using Wizard Benefits Share Object Configurations between Repositories Facilitate Concurrent Development Enable Integration with External SourceControl Systems Netherlands Germany France File System Archive-A.sif Archive-B.sif Archive-C.sif

  13. Tools - Export and Import Developers can add object definitions to an archive using the drop down menu and: • Selecting one or more objects in the object list editor; or • Selecting a project that controls multiple objects

  14. Tools - Export and Import • Before importing from an archive file, the developer sees a preview of all the objects that it includes • He or she has three default conflict resolution options including: • Overwriting conflicting objects with archive file definitions • Merging the repository with the archive file -- archive file wins attribute conflicts; and • Not importing conflicting objects into the repository

  15. Tools - Export and Import • During the import process the developer can choose what changes are accepted from the file at an object and attribute level • This makes the Export and Import process particularly useful for sharing object definitions among peer repositories Core Spain Portugal Ireland

  16. Tools - Export and Import - Guidelines • Use the repimexp.exe utility to back up the repository before importing a large number of archive files • Where possible export and import entire projects to capture most interdependencies • Validate imported objects to determine whether there are any conflicts or missing dependent objects

  17. Tools - Export and Import - Guidelines • Import all archive files and apply all patches locally, to ensure changes can be tested thoroughly before being checked in to a server repository • Avoid modifying an archive file in anyway -- doing so will corrupt it and cause any subsequent usage to be unsupported • Inactivate rather than delete unused repository objects • Follow all recommended Siebel naming guidelines

  18. Tools - Patches Patches allow changes in one repository to be applied to another Original Core Modified Core Configuration Generation of Patch Application of Patch Configuration Modified Satellite After Patch Modified Satellite

  19. Tools - Patches • The patch is an archive file that includes definitions of objects that have changed in the core repository. • The developer can specify whether he or she wants Siebel to determine which objects have changed by: • Using the Changed Indicator Flag, or by • Comparing an original version of the repository to an archive file that includes configuration changes

  20. Tools - Patches • As with import archive function, the developer has an opportunity to preview the objects that will be imported when the patch is applied • The developer must lock affected projects before changes can be made. • Unlike the import archive function, the developer does not have the opportunity to conduct conflict resolution

  21. Tools - Patches • The patch application process uses the same win rules as the application upgrader • The absence of manual conflict resolution controls makes patches especially useful for distributing centralized changes from a core repository Core Poland Hungary Russia

  22. Tools – Patches - Guidelines Use of the “Changed Objects in Current Repository”option for building patches • Should only be used for “cumulative patches” i.e., patches that are inclusive of both recent changes and those included in previous patches • Changed Indicator Date should be set to the initial release date of the Core repository • Changed Indicator Date should be left unchanged as long as the repository is used for building patches

  23. Tools – Source Control Integration Siebel’s source control integration feature automatically: • Creates an archive file when a developer checks out one or more projects with a lock • Allows user to view the “diff” dialogue box during check in to preview what changes are being checked back to the server • Saves an up-to-date archive file to the source control system during check-in

  24. Tools – Source Control Integration The Tools Option dialogue box allows the user to select: • Whether he or she wants to use the Source Control integration feature; and • Which batch file will issue commands to the Source Control application

  25. Tools – Source Control Integration • Siebel Tools ships with batch file called “srcctrl.bat” that issues commands to MS Visual Source Safe • If developers wish to enable source control integration features with other applications, they must use “srcctrl.bat” as a template to create their own batch file

  26. Development Environment Siebel Enterprise Server Testing Environment Siebel Database Server Siebel Enterprise Server Siebel Database Server Production Environment Siebel Enterprise Server Siebel Database Server Architecture - Centralised

  27. Core Test Architecture – Centralised Deployment Local Local Test Test Global Production Database

  28. Architecture – Distributed Deployment Core Local Local Test Test Test Production Database Production Database

  29. Architecture – Centralised Distributed Core Local Local Test Test Test Global Production Database Production Database Production Database

  30. Application Change Management A Centralised Distributed Approach • Examining complexity • Define Ownership • Define Architecture • Define core application/environment • Define custom application/environment • Define release mechanisms • Major upgrades • Upgrades • Patches • Reports • Translations • Process • Siebel Anywhere • Database Extract

  31. Application Change Management Major Releases Patch Releases 14 14.1 14.2 14.n ….. 15 15.1 15.2 15.n ….. 16 16.1 16.2 16.n ….. 17 17.1 17.2 17.n ….. • Issues • Hides the true complexities

  32. 5% 95% 30% 70% 99% 1% Application Change Management The Reality – What makes up a Siebel Application 17 Country Specific User Interface Object Layer Data Layer Core

  33. Application Change Management • Issues • Number of Applications in a single repository • Data Layer differences within a single repository are not supported

  34. Application Change Management • Major components • Configuration (DB Repository) • Siebel specific version release/patch • Application Admin (in DB) • External VB Applications • Reports (ROD & ROX files) • Workflow manager configuration • EIM files (IFB & BAT files) • Server administration tools

  35. Supported versions • Reports • Language specific • Workflow manager config • EIM files • Appl. Admin\Translations • External VB apps • Server admin tools Examining the true complexity Supported Version Maintained Version

  36. Defining Ownership

  37. Core Application - Guidelines • Single Core Repository • Superset of all common requirements • MaximiseBus Comps common across all countries/regions • All business logic on Bus Comp layer – no VB on UI layer • Bus Comps’ in separate projects from UI components • Bus Comp divided into projects as per ownership • Core reports in separate project

  38. Development Environment Siebel Enterprise Server Test Environment Development Workstations Siebel Enterprise Server Siebel Database Server Siebel Database Server Automated Testing Workstation Note several development workstations but only one test unit Core Environment NT Archive

  39. Custom Application • Contains repository currently in production • Bus Comp/Data Layer as was loaded from core • UI modified to Country/Region requirement • Country/Region specific reporting requirements • Launch platform for all releases • Physical location of dev server irrelevant

  40. Development Workstation Enterprise Server Enterprise Server Database Server Database Server Custom/country specific environment DevelopmentServer Test Database NT Archive Enterprise Server Database Server Testing Workstations Production Note one development workstation but many testing units required

  41. Upgrade Procedure Design changes to core applications Define requirements Configure core application Test core application Generate Patch file with all BC’s & Data Definitions Apply Patch to custom development server * Note any changes that may have been made locally are overwritten Modify custom UI objects to expose new functionality Release Process System Testing *N.B. These procedures outline the requirements for a centralized distributed development only – they need to be integrated with client specific procedures in order to represent a complete change management strategy

  42. Patch Process Log bug (or ER) Reproduce in core Analyze and design fix Reproduce in custom envt NO YES Other UI Apply fix to core envt Design fix Language Will satellite upgrade? Siebel Patch Process Large change? YES * NO * Note a satellite may decide to upgrade but not expose new functionality Upgrade process NO YES Send documentation of analysis and fix Generate BC/Data Patch & UI Archive Manually apply change Test Apply Patch & resolve archive Release process

  43. Major Upgrade Process Upgrade the core New vanilla Siebel Old vanilla Siebel Corporate core New Corporate core

  44. Major Upgrade Process Upgrade each custom application to apply UI changes New vanilla Siebel Old vanilla Siebel Custom New custom

  45. Major Upgrade Process • Generate Patch file with all BCs & Data • Apply via normal upgrade procedure

  46. Reports • Separate project for core reports • To modify a core report, a country may inherit the report definition into their own custom version • Custom reports created in separate project on local development server and maintained locally

  47. Specific Events / Procedures • Changes to datalayer • Changes to core bus comps • Changes to satellite buscomps • Change w/o schema differences • Change with schema differences • Changes to UI components • Solution leverage

  48. Questions ?

More Related