When building and managing a data warehouse and associated ETL with Sequel Data Warehouse (powered by RODIN), you are building a software application that may be very extensive with hundreds if not thousands of objects. As such change control is imperative. Sequel Data Warehouse has built-in change control capabilities that allow you full control over the development and deployment lifecycle.
We are often asked if Sequel Data Warehouse integrates with change management software (Aldon and Turnover are two popular ones). We have investigated the options for integrating with these packages and unfortunately there are significant restrictions in the way these packages require your development environment to be set up, that do not allow tight integration. Instead we have developed our own change management functionality, and provided arms-length integration, that is explained below.
When setting up Sequel Data Warehouse (powered by RODIN) you will install multiple environments: usually Development, Test, and Production. Some of our larger customers also have an Integration environment too. Each of these environments can be on the same system/LPAR or on different systems/LPARs. Each environment has it's own metadata repository and data library (containing instances of the Data Warehouse and Data Mart tables developed in Sequel Data Warehouse. New definitions (tables, indexes, views, ETL definitions etc) are created in the Development Environment. Initial testing is performed here by the developer.
When ready to perform QA testing, the definitions are promoted to Test using an Export and Import process. This is 2-step process that provides for the environments being on different LPARs. This is where the arms-length integration with other change management software comes in. The import process can be triggered by a Sequel Data Warehouse command that can in turn be defined as a 'custom' promote step in most change management packages. This way, your standard change management software can be 'in control', while Sequel Data Warehouse itself does the work of performing the import (promotion).
After QA testing is complete, the same Export-Import process is used to move definitions to Production (or Integration). A full audit trail is produced of all import processes.
Handling changes to existing definitions is pretty much the same process, except that within the development environment, change management requires a definition to be checked out to a developer, and then after the changes have been made checked in before it can be promoted to Test. The Check-in/check out process performs logging, allowing you to record activity against a project, and also creates and maintains Versions of the definition. Tools allow you to compare versions or revert to a prior version etc.
Still have questions? We can help. Submit a case to Technical Support.