Windocks increases the return on investment in storage area networks (SAN) by using them in devops.
During a devops build and deploy process, Windocks works with the SAN to deliver SQL Server containers with a fast clone of your production database(s). This allows testing to be done with production data in builds as well as test and staging deployments. This reduces the risk in the final deployment to production.
Customers are currently using Windocks with storage solutions from Cohesity, Pure Storage, Netapp and others. The reason for using Windocks with SANs in devops is the simplicity. Customers only need simple configuration to deliver SQL Server containers with production data from the SAN.
Simply add a step to the build pipeline in your devops orchestrator (Azure devops, Jenkins, Bamboo, etc) to run a docker build command with a dockerfile. Alternatively you may use the Windocks REST API in the build step. The dockerfile specifies your SAN configuration and the databases you need in the SQL Server container.
Next, add a post-build step to run a docker create command (or use the REST API) and Windocks takes care of the rest. Windocks creates the SQL Server container and the SAN clone of the source volume(s) and then delivers the cloned production data from the SAN's cloned volume(s) to the SQL Server container.
The orchestrator can now run tests against production data. The orchestrator uses the same means in deployment / releases to test and staging environments. These environments now run on the latest production data, reducing the risk to production deployment.
FInally, when the orchestrator performs clean up actions, add a step to docker delete (or use the delete REST API) to delete the SQL Server containers. When containers are deleted, Windocks automatically cleans up the SAN cloned volume(s).