The Round Table Methodology

1. The Round Table Methodology We at Gogamagog can improve your IT “eco-system” by leveraging our knowledge and experience with industry standard business practices high end VM and CRM tools similar, highly successful projects for our other clients techniques for enhancing standard systems and we can do this for less money with less of an impact on current operations using tools and techniques that your staff is already familiar with

2. Some of the Problems • High error rate for web code deployment • Problems can only be found through extensive manual testing • Problems are difficult to resolve • Frustrated support engineers can’t figure out what is where • Huge amount of work to create and maintain the growing number of environments • Resolved problems often reappear

3. The source of the problem • Your product is composed of a large number of interdependent components that are not clearly identifiable or traceable. • Those components are produced by diverse business organizations and processes which have become “fifedomes”, with poor coordination and communication between them. • These components are now being distributed to a growing number of environments. • There’s no clear, simple, cross-fifedome business process and supporting tool set in place for managing component change and maintaining component identity and relationships as they are deployed to each environment.

4. (1c-the-current-method.bmp)

5. The component setsdeployed with this process • network infrastructure • IIS container configuration • WebSphere container configuration • database accounts and schema • IIS application components • WebSphere application support library • j2ee packaged application components • database application components

6. Flaws of the current process • it is completely ad-hoc, with each business group defining their own processes independently and with limited to no visibility • there is no way to maintain the relationships of components as they are deployed • there is no way to provide assured integration among components • the majority of deployments are completely manual, or require complex manual steps • there are many possible sources of components, with no “official” source clearly defined • there is no way to audit a host and determine exactly what is installed on it • components are often extracted from other environments, which ( given the previous statement ) is extremely unreliable • there is no clearly defined set of subsystems that can be independently evolved on each environment

7. What about those tools ? Version Management tools: • RCS/CVS • PVCS • ClearCase • Subversion • Accurev Configuration Management tools: • Quest’s FogLight • mValent’s Integrity • HP’s OpenView

8. (2-the-tool-space.bmp)

9. What do they provide ? • a central, versioned repository for information, in which environment parameters, static components, and component templates are stored in a task oriented manner • a mechanism for generating environment specific components from component templates by applying the environment parameters • a mechanism for delivering components to the appropriate host • a mechanism for initiating the execution of delivered installation scripts or executable components • a mechanism for auditing hosts to determine their current state

10. What key tasks do they perform ? • information and component management • generation of components from templates • component delivery • triggering of installation scripts • host auditing

11. Why do they work ? • they put everything in one place • they provide a mechanism for managing relationships between components • they require you to assign ownership to every component • they require you to develop and deploy components using templates or installation scripts • they always install components directly from the repository

12. Drawbacks of these tools • cost • training • they don’t simplify the problem • become single point of failure during disaster recovery • limited scope

13. Things to understand • No matter how you do it, you still have to identify the parameters that uniquely define an environment, develop the templates and write the installation scripts. This is the bulk of the effort. • There can be huge differences in functionality that depend upon how an installation script is implemented. Knowing how to implement these scripts is a skill no tool can supply.

14. The Hard Facts • “If you don’t have an understanding of the process, you can’t effectively choose and utilize tools”

15. The First Steps • Learn how to share information. • Build processes around shared information. • Optimize and automate those processes.

16. The Round Tablesimple things we can do right now • We can leverage our existing source control system to implement a “Round Table” like central repository of information that is formal, versioned, comprehensive, entitled, and globally visible. • We can use simple, well known tools to develop templates that reference information on the “Round Table” to generate environment specific versions of components. • We can organize components into groups that can evolve independently from one another. • We can use simple, well known tools & techniques to package each group of components and then publish those packages. • We can always deploy those packages directly from the central repository. • We can use simple, well known tools & techniques to audit hosts.

17. Who are the Knights ? • Systems Operations • Development • Middleware and Database • Configuration Management

18. Setting up the Round Table a place where knights from different lands meet and exchange information • formal: start by building a single host that everyone knows about

19. Setting up the Round Table a place where knights from different lands meet and exchange information • formal • versioned: integrate with your existing source control system version control using existing PVCS

20. Setting up the Round Table a place where knights from different lands meet and exchange information • formal • versioned • comprehensive: divide it up into different areas for each group version control using existing PVCS DNS, TAM, adapters, IIS, ... db accounts, schema, jdbc, ... application requirements... environment descriptions...

21. Setting up the Round Table a place where knights from different lands meet and exchange information • formal • versioned • comprehensive • entitled: assign ownership and responsibilities to each area system operations version control using existing PVCS DNS, TAM, adapters, IIS, ... database & middleware db accounts, schema, jdbc, ... application requirements... development environment descriptions... configuration management

22. Setting up the Round Table a place where knights from different lands meet and exchange information • formal • versioned • comprehensive • entitled • globally visible: put a web site over everything management & others system operations version control using existing PVCS DNS, TAM, adapters, IIS, ... database & middleware db accounts, schema, jdbc, ... application requirements... development environment descriptions... configuration management

23. Setting up the Round Table a place where knights from different lands meet and exchange information • formal • versioned • comprehensive • entitled • globally visible • automated: add template and packaging support management & others system operations version control using existing PVCS DNS, TAM, adapters, IIS, ... database & middleware db accounts, schema, jdbc, ... template processing using standard macro engines application requirements... development environment descriptions... packaging and publishing using zip files and web site configuration management

24. Integrating with the SDLC

25. Setting up Deployment Schedules

26. Advantages of the simple approach • simple techniques for storing and sharing information require little to no training to use • using a simple package and publish technique rather than a specialized deployment tool eliminates dependency upon central server, removing single point of failure and supporting alternative deployment methods • localized validation tools also eliminates dependency upon central server • the scope is not limited to any area – we can apply this to configuration, product, and even infrastructure components at no additional cost • simple techniques which require no specialized software support the possibility of implementing elements of this approach as part of the build process • minimal initial expense, no ongoing expense

27. What does this look like ? • a single host • a set of privately owned read/write areas, each assigned to a business group • a simple website that can view all of the areas • rich support for template processing and build automation • support for standardized packaging and publishing techniques • a well documented, cross-organization business process around this system

28. (3-do-it-yourself.jpg)

29. What are the business processes involved ? • Configuration Management manages the specification of the formal requirements of each business group, and negotiating changes to this spec. • Operations is responsible for maintaining infrastructure information and invoking infrastructure related automation. • Database & Middleware is responsible for maintaining WebSphere templates and sql database deployment scripts. • Development is responsible for maintaining application and library related information, including information about library configuration and configuration file requirements, but excluding the files themselves. • Configuration Management is responsible for maintaining the configuration files that are expected by the application. • Each business group is responsible for maintaining, versioning, and building the packages they own.

30. (generate-and-package.bmp)

31. J2EE application IIS application WebSphere application libraries WebSphere container configuration IIS container configuration Database components How do we apply this technique ?

32. What we have already demonstrated • A simple technique for creating a repository, developing and using templates and scripts, and packaging and publishing components is extremely effective, specifically: • The level of effort for Websphere container configuration for the qmitp project, factoring in time spent testing and repairing problems introduced by the original manual process, has been reduced from 2 man weeks to 20 minutes, with 100% reproducability • An initial version of a script deploying network adapter and IIS container configuration using WMI has shown similar improvements and will be adopted once testing is complete.

33. What Gogamagog will provide • Set up the Round Table • Provide support for key tasks of information management, template processing, packaging and component delivery • Provide initial versions of templates and scripts • Oversee the development and documentation of cross-organization business processes • Help all business groups adopt new business processes for maintaining their globally visible information • Coordinate with owners of each environment as we integrate them into the process

34. For System Operations • create and deploy DNS server tables • create and deploy certs • generate reports

35. For Development • streamline application build and deploy process so that ear delivery is as fast and easy as jsp drops • add version and build identification to produced components • reliably integrate version and build identification with source control system • provide support for auditing the application components on each host • create formal area for publishing and archiving build products so that environment managers can access them as needed • specify and create a clearly defined interface between application and configuration, along with a migration path that ultimately moves all configuration into an independently verifiable container component set

36. For Quality Assurance • add version and build identification to produced components • reliably integrate version and build identification with source control system • provide required support to link components and packages to tracker SCR’s • provide support for auditing the application components on each host

37. For Management • provide a place where current status can always be found • provide formal, concise reporting of environment configurations

38. The Next Step • Once we learn how to share information, we can begin to introduce tools that will optimize this process. • all templates and scripts can easily be adapted to any tool on the market, allowing smooth transition to one of these tools should the need arise