Introduction
This paper presents how an Agresso system may be managed in such a way as to minimise risk and provide assurance, traceability and accountability to an organisation, its managers and auditors.
The objectives of the ideas presented here are:
- To ensure that all configuration changes to a live system have been tested before deployment
- To ensure that testing is carried out on an system that is identical to but separate from the live system
- To ensure that all configuration changes deployed to a live system are identical to those which were tested
- To ensure that all configuration changes deployed to a live system are recorded and can be reproduced
By way of illustration, the sorts of actions that would run counter to the objectives and ideas presented here might include
- Making minor development changes directly to a live system (objective 1)
- Deploying configuration changes manually via the Agresso client (objectives 3 and 4)
- Testing software and configuration changes at the same time on the same system, but deploying to live separately (objectives 2 and 3)
The basic ideas are presented in the ‘Background and Definitions’ section and then applied using fictional scenarios which follow.
Background and Definitions
Requirements
A ‘requirement’ is considered to be the definition of a change to a system requested by an end user. It could describe a defect in existing functionality, a proposed enhancement or entirely new functionality.
Systems to store and manage requirements definitions typically provide the following capabilities:
- Track a requirement through a development/testing/deployment workflow
- Link a requirement to the technical solution which attempts to deliver it
- Expand, clarify and refine the definition in collaboration between end users and developers
Well known requirements management tools include:
Environments
An ‘environment’ is considered to be all the computing resources required to provide a given system. For an Agresso system, an environment consists of:
- A Database Management Server (DBMS) (e.g. Microsoft SQL Server)
- An Agresso database hosted on the DBMS
- An Agresso Business World (ABW) Server installation
- An Agresso Server Datasource and associated services running on the ABW Server
- A Web Server (e.g. Microsoft IIS)
- An Instance of Agresso Web Services running on the Web Server
- An installation of the Agresso Smart Client
It is perfectly feasible for multiple environments to share resources.
For example, a single DBMS can host multiple databases; a single IIS Server can host multiple instances of the Agresso Web Services and a single ABW installation can host multiple datasources and ABW services.
It is also possible for the DBMS, ABW Server and IIS Server to share the same physical hardware (or Virtual Machine) and still provide multiple environments.
Tiered Environments
Environments are considered to exist within ‘tiers.’ The tier to which a given environment belongs defines the function that it is intended to perform. A typical set of tiers is:
- Development - Allows an individual developer or a small team to work on a single development in isolation from other environments
- Integration - Allows multiple developments to be combined for joint regression testing
- Staging - Simulates the production environment to allow end user testing, training or QA testing of a release process
- Production - The live system
At any given time, there may be one, several or no environments within the first three tiers, depending on the nature of work in hand at that time.
For example, where a large training programme is under way at the same time as a minor piece of development work, it is likely that there would be two environments within the staging tier, one in development and no integration environment at all.
Releases and Cloning
A ‘release’ is a process by which a change is promoted between tiers (e.g. from Staging to Production or Development to Staging).
A release package consists of a set of instructions to affect a change from a given system state. It might consist of a scripts or executables to be run within an environment, files to be deployed with instructions on their intended locations and/or manual steps to be performed within the Agresso software. Ideally, a release process should be as automated as possible so as to ensure that the change is as intended.
‘Cloning’ is a process by which an environment is copied between tiers. Cloning is normally performed from the Production environment so as to ensure that testing and development starts from the same current production system state.
Releases and Cloning are both mechanisms for deployment of change across the tier boundaries. Neither should ever happen between environments within the same tier.
Actors and Roles
Anyone working on a given environment is considered to be an ‘actor’ performing a defined ‘role.’ A typical set of roles is:
- Owner – determines the policy and process by which anyone else is assigned any other role
- Architect – defines the hardware and software platforms on which the environment is created and how they are shared with other environments
- Gatekeeper – Controls the deployment of releases and clones to this environment
- Publisher – Controls the publication of releases and clones to environments in other tiers
- Tester – Tests the results of work done by developers
- Developer – Changes the system to meet defined requirements and produces the release to affect that change on environments in other tiers
It is perfectly possible that any individual might perform several roles within a given environment and also across different environments (e.g. the production gatekeeper is highly likely to be a tester on a staging environment; a developer may perform all six roles on a dedicated development environment).
Source Code and Version Control
‘Source Code’ is considered to be machine interpretable instructions to affect a change within the system or to provide the definition of some element within that system.
In the context of a tiered Agresso implementation, the following would all be considered as source code:
- SQL Script to define and create a balance table
- An XML file to define an Agresso Report Creator (ARC) report
- A spreadsheet file which defines an Excelerator report
- A script to drop and replace a database view and to place a new version of an Agresso Report Writer (ARW) file in the correct location as part of a release package
‘Version Control’ is a process to manage changes to source code. Typical version control systems allow developers to:
- Share their work for review and comment
- Retain the history of all changes and to revert to previous versions if required
- Link the changes they make to requirements definitions within a requirements management tool
Well known version control systems include:
Scenarios
In the following scenarios, we assume the existence of a production environment and one staging environment (stg1) on separate hardware.
The purpose of these scenarios is simply to demonstrate how the principles described above might be applied to real situations.
Scenario 1
A new requirement has been defined for additional management information. It will require some new balance tables, database views, Excelerator reports and Browser enquiries.
- The number of developers is likely to be small, so there is no need for an integration environment
- There is no change to any installed software, so it is reasonable to create a new development (dev1) environment on the same hardware as stg1
- The work is carried out in dev1, released to stg1 for testing and then released to production when complete
- At the completion of the work, dev1 is deleted and stg1 cloned from production
Scenario 2
Agresso have released a new service pack. There is also a problem on the production environment for which there are several potential solutions.
- A new development environment (dev1) is created to investigate the problems in production. It shares the hardware with stg1 since there is no change to installed software.
- The Agresso Service Pack upgrades the database, ABW Server, Agresso Web Services and ABW client software so a new staging environment (stg2) is created and upgraded on separate hardware
- Testing of the upgraded system is carried out on stg2
- Stg2 is deleted, cloned from production and upgraded to the new Service Pack regularly as part of the upgrade testing work
- If problems are found, a new development environment (dev2) is created to investigate and solve those problems. Work is released to stg2 for testing.
- Investigative work on dev1 is released to stg1 for testing and to production when complete
- On completion, dev1 is deleted and production cloned to stg1
- The next stg2 clone/upgrade process includes the changes released from dev1
- Once upgrade testing is complete, the upgrade is carried out on production (along with any releases from dev2)
- Production is then cloned to stg1 and stg2 is deleted
|
