This is the second blog in a two-part series on how to simplify the deployment and scalability of your embedded analytics. In the first part, we explored considerations related to environmental architecture, application design, and deployment. Now we’ll go over the final consideration: defining workflows for packaging and deployment.
Your embedded analytics solution should work seamlessly with your current application. When built as a web application, embedded analytics platforms fit well into modern code management and deployment situations. Deep integration means your development team can leverage their existing tools and processes.
A Phased Approach
A combination of code management and scripted deployment processes helps add value by extending the analytics features in your application. The best way to enhance features is with a phased approach:
- Start with developer-defined, managed dashboard content.
- Provide self-service features with limited sets of data.
- Monitor how users interact with data and compare with how it performs.
- Review database and application performance and fine-tune systems by improving reporting data models, adding database indexes, increasing application server resources, and so on.
- Expose additional datasets and more granular dashboards with interactive drilldowns based on user feedback from prior phase.
- Monitor for database and application performance.
- Iterate over prior phase.
- Review enhancements provided by the embedded analytics platform over newer versions.
- Add or remove features based on user feedback.
Code Versioning and Deployment Workflow
In the typical deployment workflow, development and/or DevOps configures the embedded analytics solution in a development environment, either using the integrated development environment (IDE) provided by the embedded analytics vendor or a web interface. Configuration definitions (and code) are committed to a source code management system. Once feature development is complete, the code is tagged for release. Finally, DevOps captures a tagged version of the software, packages it, and deploys to a web server environment.
Code Versioning and Packaging
Most development shops use a code versioning system to maintain their application source code. Common tools include GIT, (Microsoft) TFS, and SVN. Your embedded analytics platform should be able to leverage these tools to give developers a similar level of code management and code sharing capabilities.
An embedded analytics solution includes an engine and a developer-defined configuration which drives the engine to generate content for end users. Configuration definitions are typically maintained in XML or JSON files.
You have two options in versioning code:
- Commit configuration definitions in a source code management system, then package engine files separately and handle directly in the deployment step.
- Commit a complete solution, including configuration definitions and engine, to a source code management (SCM) system.
If you maintain configuration definitions separate from engine files, you’ll see a few benefits—including the ability to leverage partial deployments for smaller, incremental changes. However, since modern source code management systems are able to support larger file structures, maintaining a complete solution in the SCM is recommended.
Most software shops nowadays maintain some form of scripting to simplify the deployment of applications to server environments. Common tools include Jenkins, Chef, Ansible, Puppet, TFS, and Octopus.
These tools provide two main benefits:
- Script or automate compiling and/or packaging of software and prepare for deployment
- Script or automate setup of environment and deploy software to environment
Integrating embedded analytics software into your deployment workflow can be seamless. You can tie it with your existing application deployment cycle or set it up on a separate workflow. The level of integration depends on how tightly your current application’s features are coupled with your embedded analytics solution. Most application teams tend to maintain a decoupled solution, which allows for delivering enhancements to embedded dashboards and reports at a different pace from rest of your application suite.