Test & Deploy (T&D) is a powerful feature available for Enterprise customers that lets you perform and test changes in one Pigment environment without impacting the others.
Once you’re happy with the testing, you can then deploy changes to your Prod Environment, where it will be visible by all users.
There are other resources dedicated to T&D, but if you need to remember one picture, use the one below:
However, tighter Model Control can also mean that in case of emergency, you lose some of the flexibility to “fix in Prod”, which can be critical if you have, let’s say, a Board meeting in 5 minutes and you absolutely need that formula calculating EBIT to be modified.
In this article, we will provide examples of how the “Local Deployments” feature can be leveraged to lift limitations inherent to T&D.
This is everybody’s nightmare. You’ve consolidated figures in Pigment, have checked that everything made sense, and used the PowerPoint add-in to lock your presentation to the Board for the monthly closing. The meeting starts in 5 minutes, and you realize that something is wrong.
You could make the change in your Dev Environment, but given the data is not up-to-date, there’s a small risk your fix won’t cover all cases. This is a perfect use case for Local Deployment in Production, which will allow you to:
- Create a copy of your Production Application with the latest available data, and group applications in a custom deployment group,
- Perform changes in the application copy and confirm that everything is fine,
- Deploy changes from the copy to the live application, using the custom deployment group set-up.
After a few seconds, carefully tested changes are deployed in the Live Applications, everything is perfect, and you go into the Board meeting with the correct figures. You’ve saved the day, and avoided presenting wrong figures while still keeping tight control on the changes.
Also, ensure that after the Board meeting when you have time to breathe, you also replicate the changes from the Copy Application to your Dev Application. Otherwise, at the next Application deployment from Dev to Prod, you have the risk that your changes will be reverted.
Let’s imagine it’s now been a couple of months or years since you have implemented T&D, you’ve created a few new applications (congrats!) and also added blocks in your existing applications.
However, it’s now becoming difficult to manage all applications, and you think a big spring cleaning would be useful. One of the first things you want to tackle is to ensure some obsolete applications are emptied and deleted. These obsolete applications contain dimensions and Transaction Lists used everywhere else… How would you approach it?
You could:
- Make the changes directly in Dev. After all, what’s the worst that could happen? Maybe it’ll crash and you’ll lose some data.. In that case you’ll request a full refresh of your Dev. It’s not ideal, but it’ll do the trick.
- Make a set of Recovered Applications in Dev or in Prod, but… you’ll need to remake all changes manually, and some actions are also not possible in Recovered Applications.
- Make a copy of your Dev Applications, create a deployment group, make changes in the copies and if everything goes well, make a Local Deployment to the main Dev app.
I’m sure from now you’ve understood option 3 is the best option, as it:
- Allows you to make all modifications freely in applications copy, without a risk of breaking anything,
- And if you’re happy with the changes, you can safely Locally Deploy them from Copy to Dev, and after testing, from Dev to Prod.
You’ve done a few hundred changes in Dev, have carefully tested it with the available data, and you push the changes to Production. However, one thing you didn’t take into account is that an Application in Production takes data from your managed app, and the changes you’ve deployed have unintended consequences.
You could let your colleague who owns the application fix it, but given you’re a nice person, you’re looking for a way to help. Until now, the option would have been to manually revert your changes in Dev, and push to Prod to previous configuration. Unfortunately that won’t work, because you’ve not only modified and added metrics, but also deleted some of them…
You can now use Local Deployments from Recovered Applications to your Live Applications. What does it mean? That you can make Recovered Applications from the exact point of time before the deployment was done, and deploy those changes to the live app, as if you were reverting all changes deployed to Production.
Things are now back to the original status for both you and your colleague, everything works and you’ve avoided possibly hours of rework for your organization. Well done !
As you’ve seen, there are multiple use cases for using the Local Deployment feature.
One key thing you keep in mind is that it does replace the regular Deployments or Recovered Applications, but completes those features to make it even safer and more convenient for you to make changes.
You have additional use cases for this feature and would like to share them with the other members? Feel free to comment on this thread.