Change History Repository - Tracking and Auditing Deployments and Changes

Installing the Change History Repository

Combine enables users to maintain a Change History database that records all details and actions in response to the deployment of code packages (see the Overview section for detailed information regarding the Change History Repository). To install the repository database, please follow the instructions below:

1. Locate the SQL script that installs the repository. It is called "Create Change History Repository on SQL 2005 or later.sql" and can be found at the download section on JNetDirect' website and are also available under the Combine installation directory (for example, under the folder: C:\Program Files\JNetDirect\Combine\Repository\CombineChangeHistory\).

2. Create the repository database on a SQL Server: Locate the SQL Server that will hold the repository database (this SQL Server can reside anywhere on the network where it can be accessed by machines and users running Combine). Log on to the SQL server and to the Master database as an administrator (either as the sa user or as a domain administrator). Run the script "Create Change History Repository on SQL 2005 or later.sql".

The executed SQL script creates a database called CombineChangeHistory, the schema (i.e., tables and stored procedures) for the database, as well as four SQL roles: ChangeHistoryReadOnly, ChangeHistoryInsertOnly, ChangeHistoryManagers, and ChangeHistoryAdmins. Users that belong to the ChangeHistoryReadOnly user group will be able to read and search the repository content however will not be able to write and track deployment results. Users in the ChangeHistoryInsertOnly group are only permitted to populate the repository to record package execution details, yet are not allowed to read or search the repository. The other two roles, namely ChangeHistoryManagers and ChangeHistoryAdmins can populate the repository and view the recorded content. Additional information regarding these SQL roles is available in the Overview section.

Note: By default, the name of the Change History Repository database is CombineChangeHistory. You can change this name and use any other database by opening and editing the SQL script that installs the repository DB.

3. Define users for the Change History Repository - make sure that all users that will be using the Change History Repository have access to the repository database. At this point you should also set the permissions and access restriction to the repository: It is recommended that all users that deploy code packages will be added to the ChangeHistoryInsertOnly group and that users that need to search and view the deployment data will be members of the ChangeHistoryReadOnly group. Advanced users (e.g., production DBAs) should be added to the ChangeHistoryManagers role, and non-developers or DBA users that work with auditors should be added to the group called ChangeHistoryReadOnly. For your convenience, a SQL script called "Examples - Adding users to Repository roles.sql" contains examples of how to add users to the different SQL roles and is available on JNetDirect' website as well as under the Combine installation directory (e.g., C:\Program Files\JNetDirect\Combine\Repository\CombineChangeHistory\).

4. Instruct users to define the Change History Repository in the client user-interface in Combine. To do so, each user should go to Tools → Options → Packages → Change History, and provide the connection information for the SQL Server and database that hold the repository (see image below). If any of the settings are incorrect and Combine is configured to write to the Change History Repository to track deployments, then Combine will alert users of this fact.

In addition, the following configuration options are available to users working with a Change History repository:

- Store Extended Package Deployment Details: If this option is turned off then each time a user deploys a code package, only general package information (i.e., one row per package deployment) will be recorded in the Change History repository. However, when this option is checked, then Combine will store detailed DB change info (i.e., one row per each script and target DB pair) as well as the general package info in the repository. Additional information regarding general vs. detailed change info is available in the Repository Overview section.

- Test Connectivity to Change History Repository database: This option instructs Combine to test that a connection can be established to the Change History Repository database before the execution of a code package, when packages are deployed either from the user-interface or from the CpaExec command line utility. The authentication type and credentials used to connect to the database are those provided in the Options section shown in the image below.

Additional settings are also available under Tools → Options → Packages → Auto-Save Results and allow users to configure when and how Combine should write the deployment results to the Change History repository. For example, by setting the Auto-Save Package Results to Change History Repository, users can instruct Combine to always write to the repository, prompt and ask whether to track deployments, or never write to the change history database. When set to Prompt, each time users deploy packages from the user-interface they will be prompted to select whether to track execution results. For the CpaExec command line utility, users can activate the "ch" flag to write to the Change History repository.

Figure 102.0a1:  Defining the Change History Repository in the client application.

© 2001-2017 JNetDirect, Inc. All Rights Reserved.