Moving an application from development to production sounds straightforward—but in practice, it involves a series of carefully coordinated steps that can easily go wrong without a clear structure in place. Whether you’re working with Qlik Sense, Power BI, SAP BusinessObjects, or any other BI platform, understanding the software deployment process is the foundation for reliable, repeatable releases.
This article walks through the five stages of deployment, explains why each one matters, and answers the most common questions teams ask when building or improving their deployment pipeline. If your team is still relying on manual steps and hoping nothing breaks, this is a good place to start.
Why does a structured deployment process matter?
A structured deployment process matters because it reduces the risk of errors, ensures consistency across environments, and makes releases predictable. Without a defined process, deployments depend on individual knowledge, manual steps, and informal habits—all of which create single points of failure and make it nearly impossible to scale reliably.
When teams deploy without structure, small mistakes compound quickly. A missing dependency, an untested configuration, or a skipped approval step can result in business users losing access to the apps they rely on. In regulated industries such as healthcare or finance, an uncontrolled deployment can also lead to compliance violations with serious consequences.
A structured process brings three things that ad hoc deployments cannot: repeatability, accountability, and speed. Once the process is defined and documented, every team member follows the same path. That means fewer surprises in production, faster onboarding for new developers, and a clear audit trail of what changed, when, and why.
What are the five stages of deployment?
The five stages of deployment are: Development, Testing, Staging, Approval, and Production Release. These stages form the backbone of any reliable deployment pipeline, moving an application from initial code changes through controlled validation and into a live environment where business users can access it.
Stage 1: Development
This is where the work begins. Developers build new features, fix bugs, or make configuration changes in an isolated development environment. Version control plays a major role here—every change should be tracked so that nothing is lost and the full history of the application remains accessible. In BI platforms such as Qlik Sense or QlikView, this means checking out an app, making changes, and checking it back in with a clear record of what was modified.
Stage 2: Testing
Once a change is complete, it moves into a testing environment. Testers validate that the application behaves as expected, that data loads correctly, and that no existing functionality has broken. The ability to see exactly what changed between versions makes this stage significantly faster and more focused—testers can zero in on the modifications rather than retesting everything from scratch.
Stage 3: Staging
Staging is a near-identical replica of the production environment. It’s used to verify that the application works correctly under conditions that mirror what real users will experience. Dependencies—such as data connections, reload tasks, extensions, or QVDs—are validated here to confirm that everything required in production is present and working.
Stage 4: Approval
Before anything reaches production, it needs sign-off. The approval stage enforces a governance checkpoint where a designated reviewer confirms that the change has been tested, meets quality standards, and is ready for release. This stage is particularly important in regulated environments where documented approvals are part of compliance requirements.
Stage 5: Production Release
The final stage is the controlled deployment to the live production environment. Ideally, this happens automatically once approval is granted, with no manual file copying and no direct access to the production server required. A clean production release means business users experience no disruption, and the new version goes live exactly as tested.
How does testing fit into the deployment pipeline?
Testing fits into the deployment pipeline as the quality gate between development and production. It sits between the development stage and the staging environment, and its primary job is to catch issues before they reach users. Effective testing in a deployment pipeline is focused, fast, and tied directly to what has changed—not a full regression of the entire application every time.
One of the biggest challenges in BI testing is knowing what to test. When a developer modifies a data model, a script, or a visualization, the impact is not always obvious. Change tracking solves this problem by surfacing exactly what was modified between versions, allowing testers to focus their effort where it matters most rather than reviewing the entire app from scratch.
Testing also needs to account for dependencies. If a QVD file is updated, every app that uses that file could be affected. Understanding data lineage—knowing which apps consume which data sources—allows testers to identify the full scope of a change before it moves forward in the pipeline. Without that visibility, something that looks like a small update can silently break multiple reports downstream.
What’s the difference between continuous deployment and manual deployment?
Continuous deployment is an automated process in which changes that pass all pipeline stages are released to production automatically, without human intervention at the deployment step. Manual deployment requires a person to carry out the release steps themselves—copying files, configuring environments, and publishing apps by hand. The key differences are speed, consistency, and the risk of human error.
Manual deployment is the most common approach in BI environments that lack dedicated tooling. A developer or administrator logs into the production server, transfers the updated app, reconfigures tasks, and hopes nothing was missed. This approach is time-consuming, prone to error, and requires giving individuals direct access to production—which creates both a security risk and an accountability gap.
Continuous deployment, by contrast, automates those steps once the approval gate is cleared. The pipeline handles the promotion, updates dependencies, adjusts data connections for the target environment, and delivers the app to the right space or server. Business users see the update without any disruption, and no one needs standing access to the production environment to make it happen.
It’s worth noting that continuous deployment does not mean skipping validation. Automation handles the mechanics of the release—the testing and approval stages still happen. The difference is that once those gates are passed, the release executes consistently every time, regardless of who is on shift or how complex the deployment is.
How can deployment automation reduce errors and save time?
Deployment automation reduces errors by replacing manual, judgment-dependent steps with a defined, repeatable process that executes the same way every time. It saves time by eliminating the hours spent on manual file transfers, environment configuration, and post-deployment checks—time that teams can redirect toward development and analysis.
Manual deployments fail for predictable reasons: steps get skipped under pressure, dependencies get overlooked, and configurations differ between environments in ways that are easy to miss. Automation removes those variables. The deployment process is defined once, saved, and reused—so the tenth deployment of an app is just as reliable as the first.
The time savings are also significant in practice. Teams that deploy complex BI applications manually can spend hours on a single release—coordinating across team members, verifying dependencies, and troubleshooting environment mismatches. When that process is automated, the same deployment can happen in minutes, with full logging of what was deployed, when, and to which environment.
Automation also supports rollback. When something does go wrong in production, the ability to restore a previous version quickly is the difference between a minor incident and a prolonged outage. With automated version control and restore capabilities built into the pipeline, recovery becomes a deliberate action rather than a scramble.
What tools support the five stages of deployment?
Tools that support the five stages of deployment typically cover version control, environment management, testing support, approval workflows, and automated release execution. General-purpose DevOps tools such as Git-based platforms handle source control well for traditional software, but BI-specific deployment pipelines often require tools that support BI platform deployments natively.
For general software development, tools such as Jenkins, GitLab CI/CD, or Azure DevOps are commonly used to build and automate deployment pipelines. These tools work well when the artifacts being deployed are code files that can be diffed, merged, and versioned in standard ways.
BI environments introduce additional complexity. Apps in platforms such as Qlik Sense or SAP BusinessObjects are not plain-text files—they contain embedded data models, visualizations, reload tasks, extensions, and data connections that all need to be managed together. A tool that supports BI deployment needs to handle those components natively, understand dependencies between them, and manage the differences between development, staging, and production environments automatically.
Approval workflows and governance controls are another area where BI-specific tooling adds value. In regulated industries, the ability to enforce that only reviewed and approved apps can reach production—and to produce an audit trail of that process—is a deployment best practice that general DevOps tools do not always support out of the box.
How PlatformManager supports your deployment pipeline
PlatformManager is an Application Lifecycle Management solution built specifically for BI teams working with Qlik Sense, Qlik Cloud, QlikView, Power BI, and SAP BusinessObjects. It brings the full five stages of deployment into a single, controlled environment—so your team can move from development to production faster, with less risk and no manual intervention on production servers.
Here is what we deliver across the deployment pipeline:
- Integrated version control for apps, reload tasks, extensions, mashups, and data connections—so nothing is ever lost and every change is tracked
- Change tracking that enables focused testing by showing testers exactly what changed between versions
- Dependency management and data lineage so you always know which QVDs, extensions, and tasks your apps rely on before you deploy
- Enforced approval workflows that ensure only reviewed and signed-off apps can reach production
- Automated deployment with saved settings, so every subsequent release takes just two clicks—no direct access to production required
- Restore capabilities that let you roll back to a previous version in minutes if something goes wrong
- Hybrid and multi-tenant support for teams migrating from Qlik Sense on-premises to Qlik Cloud, or managing multiple environments simultaneously
Over 200 companies already rely on PlatformManager to keep their BI environments running reliably. The best way to see what it can do for your team is to try it yourself. Start a free three-day trial with full access to a cloud server and a demo collection of apps and data—no commitment required.