One of the most important advantages to LeapFrogBI’s metadata driven data mart development platform is the ability to adjust quickly to requirement changes. It has been well established that many BI/DW projects fail due primarily to the speed at which requirements change. The traditional method of developing data marts is not flexible and often requires many hours of redevelopment when changes do occur. LeapFrogBI built data marts, on the other hand, can be modified and rebuilt without adversely impacting the many dependencies that are often related to the area of change.
It is important to have a systematic process for deploying changes to ensure that production systems are impacted as minimally as possible. Each organization should design a deployment process to meet their unique needs, but the following generic recommendations can be used as a starting point.
Environments
At least three environments are needed to reliably deploy changes.
1. Development – Modifications are deployed to the development environment.
2. Test – Changes are first tested in the test environment prior to deploying to production.
3. Production – End users and applications will access the production environment directly.
Initial Deployment
Deploying a project after initial development can be done very simply. The first step is to develop a data mart project and deploy to the development environment. Development will often require modifications which need to be redeployed until the desired results are achieved. Prior to each deployment to development it is typically most efficient to simply delete the currently deployed data mart and allow the new deployment version to recreate the data mart from scratch.
Once the development environment is yielding the desired results it is time to deploy to the test environment. This is accomplished by simply copying the same packages that were deployed to development and copying them to the test environment. Then, the test environment configuration is built in LeapFrogBI and deployed to test as well. With the deployment complete the quality assurance process can begin. If QA fails, then the process starts over at the development environment. If the QA process succeeds, then we move on to production.
The initial deployment to production is accomplished very much like the test deployment. Copy the component packages from test to production, built the production configuration in LeapFrogBI, and deploy the production configuration to the production environment. Once the components are executed, we can be confident that they will yield the same results as in test since the only changes made are related to the environment configuration.
Incremental Change Deployment
After deploying a data mart initially, subsequent changes need to be deployed in a manner that does not disrupt the production environment. Remember that production contains not only the objects (database, schema, tables, etc…) but also data which may not exist elsewhere. There are three categories of changes. One or more of these categories are involved with all incremental changes.
– Logic only (non-structural)
– Structural change
– Data impacting change
The key difference between the initial deployment and incremental deployments is the need to copy the production data mart to test prior to deploying configuration changes. The following steps describe incremental deployments.
The first step is to get the development environment in the desired state. Development assets can be deleted and recreated without further management.
When the data mart project is ready to be promoted to test we need to first prepare the test environment such that it is identical to the production environment. This is done by simply deleting the current test data mart, backing up the production data mart, and restoring the production data mart in the test environment.
If there are not structural changes to the new deployment, then we can now follow the same steps as the initial deployment. However, if there are structural or data changes, then we need to create scripts to manage these changes. This can be accomplished either manually or with the aid of a database project in Visual Studio. The database project can be used to compare the schema between development and test. The differences will be identified and alter scripts generated automatically.
After altering the test environment we can now copy the development components to test, build the test configuration in LeapFrogBI, and deploy the configuration to test. At this point quality assurance can begin. If QA passes, then we move on to the next step; deploy to production. If QA does not pass, then we start over at development.
To deploy to production (QA pass) we first run the alter scripts created on the test environment against the production environment. Then the test components are copied to production. Finally, the production configuration is built in LeapFrogBI and deployed to production. We can now be confident that the production deployment will behave in an identical manner as test.
Conclusion
The above deployment guidelines represent one of many possible deployment processes. Another common process is to create duplicate production deployments, modify one when doing incremental changes, and use aliases to switch users and applications to the desired version after changes are acceptable. The key to the chosen process is that changes are always fully tested prior to being deployed to live production environments. This includes any scripts required due to structural changes or data impacting changes. The good news for LeapFrogBI users is that all of the assets are built based on metadata. Making a change to a single component often impacts many dependents, but the LeapFrogBI build process takes care of these dependents without further developer involvement.
