Using Stat in environment refreshes can save you a lot of time

When I talk to customers about their use and favorite benefits of Stat and often things come up with the help with the pains of doing environment refreshes. I see many ways that Stat can help.

1. Tracking that the refresh occurred. Using the ‘Env Refresh’ tab allows you to document that the refresh occurred, allows you to do ‘State’ and ‘Activity’ based reporting, and identify candidates for things that maybe need to be recovered into the refreshed environment.

2. The actual recovery of things that were ‘work in progress’ that had not been promoted to Production yet, objects that you are testing with, or personal configurations. As long as you save the objects in an archive set before the refresh occurs, pulling them back into the originating instance is as easy as promoting them to a new environment.

3. Using ‘Mass Migrations’ to group multiple developer’s work together and move back into the refreshed environment as a large bundle. Simply create a Release and tell your Developers that they can associate any objects they want recovered into that release and after the refresh has been documented in Stat, the release can be pulled in saving the developers individually pulling their code back in.

4. Stat can help if you have scripts that you like to run after a refresh to do things such as change passwords, clean data, etc. You can create a CSR and add those scripts to an archive set and after each refresh pull that archive set into the refreshed environment.

5. Reporting on refreshes. Stat has a few seeded reports around Environment Refreshes that can help show your refreshing history.

These are just some ways customers have shared with me that Stat helps them with refreshes and saves them time. By utilizing some of these may help you as well!

Anonymous